Date: Wed, 24 Jun 2009 00:17:17 +0200 From: Erik Norgaard <norgaard@locolomo.org> To: Bill Moran <wmoran@potentialtech.com> Cc: Daniel Underwood <djuatdelta@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Best practices for securing SSH server Message-ID: <4A41546D.9050309@locolomo.org> In-Reply-To: <20090623172143.05d760dc.wmoran@potentialtech.com> References: <b6c05a470906221816l4001b92cu82270632440ee8a@mail.gmail.com> <4A406D81.3010803@locolomo.org> <b6c05a470906230653i6ce647c1p415e769b63d9e169@mail.gmail.com> <4A4109DE.3050000@locolomo.org> <20090623132007.14d22270.wmoran@potentialtech.com> <4A411B74.2010405@locolomo.org> <20090623172143.05d760dc.wmoran@potentialtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Moran wrote: > In response to Erik Norgaard <norgaard@locolomo.org>: > >> Bill Moran wrote: >>> In response to Erik Norgaard <norgaard@locolomo.org>: >> I do, you can put your interface in promiscuous mode and let the daemon >> grab packets before they are filtered by the firewall, or open in your >> firewall for a range of port your knock deamon will listen to. In either >> case you add an extra daemon, an extra point of failure, an extra piece >> of code that can undermine your security. > > In your earlier message you argued that promiscuous mode is a bad idea, and > when I show that it's not the case, you magically change your argument to > be about extra processes running. Please keep your argument consistent. My argument is consistent: I still think promiscuous mode is a bad idea as it allows to circumvent the firewall. I then argue that the alternative is also a bad idea since, while you may have got rid of the promiscuous mode problem which in itself is a bad idea, you still introduce a service that will need to listen on a number of ports. The alternative is to have a daemon parsing firewall log files, this is the old solution which has been abandoned if you check portknocking.org > >>>> And it can result in people being unable to access if the knocks are >>>> filtered at the source. >>> Which can happen anyway if you have an ISP who filters out ssh traffic >>> (which isn't unheard of). >> There's no point in adding this argument, in that case you have no >> connection with or without port knocking. Sticking to standard protocols >> on standard ports is the best way to ensure your ISP doesn't get in your >> way. > > Both false. Quite frequently I've moved services to a nonstandard port > because it was the _only_ way to get a service. Please read again. I here argue against port knocking not against running on a non-standard port. If you have a problem running your ssh on some port - standard or not - then you will likely also have trouble getting port-knocking working. If you don't have a problem running you ssh on the standard port, then you may still find problems deploying port-knocking. Your argument is logically inconsistent. > ... an the _best_ way to ensure your ISP doesn't pull that kind of crap > on you is to use an ISP that won't do that. Not everyone has that option, > though. The best way to get your ISP to allow connections is to use standard well documented protocols on standard ports as it is fairly easy to convince them that this is a standard service and should be enabled. And it's not only ISPs, it's also the other sites your users visit, businesses that may employ their policies. The more you divert from standards the more likely you are to have your connection blocked by a policy some where, and the more difficulty you'll have convincing that a change should be made. >> So your argument about port knocking boils down to getting rid of some >> log entries, while annoying your users? > > Nay. It boils down to making log entries _useful_. And if your users > are annoyed, you're not doing your job. Something like puTTY (for example) > allows you to set up a profile. Just set the port in the profile and > the user never need remember it again. Yes, changing to a non-standard port is not excessively annoying and I agree that this measure cannot compromise the security. But I think port-knocking is annoying, it may cause security problems and it does not add any real security. > And if catering to users who don't know how to switch ports is more important > than making your logs useful, then do that instead. I'm not arguing that > it's the correct solution for everyone, I'm simply arguing that it's not > totally useless, which seems to be your point. It is security by obscurity not adding any real security but potentially worsening it or causing denial of service - no in the sense of DOS attacks but in the sense that it doesn't allow ordinary users to login and get stuff done. >> Now, how about your logs of failed port knocking attempts? Because, you >> log that, right? If your idea gains traction, then attackers will start >> knocking ports randomly ... you'll just have those logs filling up instead. > > Once attackers start trying random keys instead of passwords, will you > abandon PKI as well? Bad example. The only valid point you have demonstrated thus far is that you get less log entries. I am not convinced that this compensates for the problems you face deploying it. And, then also I argue that your only valid point only remains valid as long as I am correct in my analysis > Security has been, and always will be, keeping one step ahead of your > attackers. Take the opinion that you can't stay ahead of them, and you've > already lost the war. Best way to stay ahead is to deploy solutions that add real security and not solutions that add complexity and obscurity. >> if this is your main concern, why don't you just filter out the failed >> attempts? after all they failed. If you do proper security monitoring, >> your tools can be tuned to look at the interesting part of the logs. > > Because a successful attack is already too late. I want to know who is > _attempting_ to break in and prevent them from having additional time > to keep trying. You can perfectly filter a lot of failed attempts. If you deny users other than those in the group users, then the failed login attempts for the user "games" are really not very interesting. Filtering your logs and keep the interesting part is a standard job. But it is a completely different problem. >> LoginGraceTime >> MaxAuthTries >> MaxSessions >> MaxStartups > > All of these are valid _parts_ of a comprehensive security approach to > SSH. Any one of them alone is not very strong, but combine them with > a strong password policy and other tools, and you'll have a site that's > very secure. I don't argue that they add much security, but they may reduce the log load that annoys you so much, and buy you time. >> Also, very effective, identify address ranges where your users will >> never connect from and black list them in the first place. > > If that's possible. It frequently is, but what if you have users who > travel worldwide? Heck, something as simple as nationwide quickly > makes it difficult to reliably block enough ranges to be effective. Certainly, if you have a large organization with lots of people travelling such that the yearly exception is not a working solution - hey you could have the secretary tell when tickets are purchased to do add exceptions without the fuzz. The typical solution is not to add complexity in services but to isolate the systems these people can access and restrict the services available such as to limit the impact of any successful attack. > My point in all this is not that your suggestions are bad. It's just > that your discounting of knock methods an moving ports is a bit > extreme. There are a number of cases where those techniques are very > useful in combination with other security practices. My point is that any theoretical security that may be gained with port-knocking does not compensate for the all real and potential problems you will likely run into. Now instead of being woken up by the salesman that can't access from some remote country, you'll be woken up by the same salesman that can't access because the knocking sequence is filtered. There are so many more efficient ways of improving security, I have yet to be convinced of the existence of a scenario where port-knocking will create a measurable increased effect that cannot be achieved with more easily with off-the-shelf solutions. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A41546D.9050309>