On Tue, 2006-01-03 at 18:47 -0600, Jeff Vian wrote: > On Tue, 2006-01-03 at 11:26 -0500, Michael H. Warfield wrote: > > On Tue, 2006-01-03 at 13:44 +0000, James Wilkinson wrote: > > > Jeff Vian wrote: > > > > http://www.csc.liv.ac.uk/~greg/sshdfilter/ > > > > > > > > I use it on several servers and it works really well to detect and block > > > > attacks. > > > > With it an attempt to login with an unknown account gets instantly > > > > blocked, and with a known account (root or some other user) they only > > > > get 6 attempts before it is blocked. > > > > > That sounds worthwhile for a computer that only has SSH open to the > > > network. > > > > > However, do be aware that this can confirm to attackers that an account > > > is "valid", which could be useful knowledge in other attacks. > > > > Agreed! That, in an of itself, is a security hole! It can reveal, to > > unauthenticated connections, what are valid accounts and what are not. > > I've published security advisories on just those sorts of "information > > disclosure" vulnerabilities. It's considered axiomatic that security > > systems should NEVER disclose that level of information, even to the > > point of not giving a different error (message or code) for invalid > > password vs invalid account. Even timing (responding too quickly if the > > account doesn't exist compared to wrong password) is considered a > > SERIOUS no-no. I would have to consider that sshdfilter a security > > vulnerability, not a security tool. Where this something in common > > distribution, it would probably end up being a featured subject on > > BugTraq or FullDisclosure. :-/ > > > If this system had many user accounts I would worry about that. > However, the only valid accounts that are ever hit are the standard > system accounts (and over 99.9% are root, which does not get ssh access > anyway) Wrong thinking... You've still revealed to them what you have and what you don't have (meaning what not to try)... Do they need to know that information? Do you want them to have that information? You are disclosing information to them. To what advantage and to who? > Besides, a script kiddie (or even a determined attacker) will give up > quickly if the passwords are strong and they only get 6 tries in every 3 > days (or longer) You're thinking is about least 5 years out of date. You're still thinking in the "snot nosed hippy hacker" model and what we have now is the "Automated, Russian Mafia, Organized Crime" model. It's all automated and computers don't "give up". There's no PFY (Pimply Face Youngster) sitting at a keyboard thinking "what password do I try next..." Even they've used automated scripts for years now, IAC... There are even some bots and apps that attack you from different IP addresses if you use IP based defenses, or can result in a denial of service attack by locking accounts if you use account lockouts. > I acknowledge the flaws, but it is better than leaving ssh open for > repeated attempts by the script kiddies. No, actually, it's not. You haven't enumerated a single advantage to this system, short of some minor bandwidth issues and, maybe, some minor noise in your logs. You haven't enhanced your ssh security at all. I can't see any advantage here at all. If there is no account there, then having them hammer on sshd does no harm (and even slows them down in the attempts). Hell, I could care LESS if they are hammering on "demo" (one of the popular ones, for some reason, ATM...) if there is no "demo" on the system. All you get is log noise telling you someone is knocking on the door. Shrug... Yawn... "grep -v"... If there is an account there, it still makes no difference. You've still got the same authentication limits as before from sshd. You don't need a script for that. The "unauthenticated" holes in ssh/sshd have been far and few between (and, YES, as the Senior Researcher and Fellow on the X-Force at Internet Security Systems, I WAS involved in the issues that resulted in OpenBSD changing their page from "no remote holes in xxx years" to "only one remote hole in default install in xxx years" over ssh, so you could say I know a little bit about this sort of thing with ssh). You want some real security, you might try "port knocking" (which I am NOT advocating) or IPv6 (which I use on all my servers). The average, run-of-the-mill, brute force attacks on ssh I've been tracking over the last several years are nothing more than amusing automated noise. So... No advantage if the account isn't present and no advantage if the account is present... Not a lot left for a domain of applicability here. What you HAVE done is indicated what accounts are present on your system and what accounts are not. You've given them information (which CAN be automatically logged, if recognized) which they DO NOT NEED TO KNOW. Even if it's only "gee, he only has some system accounts", it's still telling them something (like what not to try). In fact, the only thing you've done is tell them something you don't want them to know (what accounts you do or do not have on the system) AND you've made it more efficient for them (fast rejects and no retries). At this point, your only saving grace is that none of the automated bots and mass-autorooters will take any notice at all of your filtering. It actually WOULD take some snot-nosed liveware looking at the results from hitting your system and thinking "That's weird. It shouldn't act like that... Maybe I should look at these clowns closer... They don't seem very smart." Fortunately, those, now-a-days, are VERY few and far between. You say it's better than... Ok... Describe your threat model where the attacker stands a better chance of breaking into your system without that filter. I would argue that he stands a better chance of breaking into your system WITH that filter because it reduces the effort he has to go to in order to determine the accounts which he may be able to attack on the system. You've reduced his search space and reduced his work effort. I see no threat model which this filter addresses and improves your security. > > > Hope this helps, > > > > > James. > > > -- > > > E-mail address: james | Say it with flowers, send a triffid. > > > @westexe.demon.co.uk | > > > > Mike Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw@xxxxxxxxxxxx /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Attachment:
signature.asc
Description: This is a digitally signed message part
