Date: Tue, 23 Jun 2009 20:14:12 +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: <4A411B74.2010405@locolomo.org> In-Reply-To: <20090623132007.14d22270.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>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Moran wrote: > In response to Erik Norgaard <norgaard@locolomo.org>: >> You add an extra layer of inconvenience and complexity, more things that >> can fail and possibly result in an insecure server: > > I would agree with you, except ... > >> - dynamically updating firewall rules on the interface facing the >> Internet is not on my list of good practices. loading or flushing rules >> continuously is the recipe for service interruption or exposing your >> server to the net. > > What crappy firewall are you using that needs flushed or reloaded to > update rules? Has your packet filtering software been updated since > the 80s? Whether you flush or add rules to ipf or update tables in pf etc. you are modifying your firewall live. >> - nor is having a sniffer daemon putting the network interface in >> promiscuous mode, a daemon that listen on lots of ports! that really >> sounds attractive. (yup: that's the latest version on portknocking.org). > > Listening on multiple ports is not synonymous with promiscuous interfaces. > You should take some time to understand the difference between those two > techniques. 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. >> 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. > What _is_ accomplished by both using a nonstandard port and using knock > techniques, is that you don't have the annoyance of all those botnets > filling up your logs with attempts to log in as root (if you don't > monitor your access logs daily, then I don't want to hear any argument > about this). With a knock solution, or running on a nonstandard port, > then you know that any login attempts are serious attack attempts, and > not just some random, mindless bots. I must be in the safe end of the internet, I don't get that much logs. So your argument about port knocking boils down to getting rid of some log entries, while annoying your users? 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. > If you're doing proper security monitoring, then reducing that log load > is worthwhile. 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. There are other tricks that work well too, take a look at LoginGraceTime MaxAuthTries MaxSessions MaxStartups Also, very effective, identify address ranges where your users will never connect from and black list them in the first place. It's fairly easy to get rid of a huge chunk of these logs - and getting your system safer - by simply restricting access to address ranges where your users are likely to connect from. Let them know that if they go to some weird place, not on the official white list then a temporary exception can be made for the period of their travel. 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?4A411B74.2010405>