Re: Best practices for securing SSH server
2009/6/28 Polytropon : > On Sat, 27 Jun 2009 21:17:11 -0400, Daniel Underwood > wrote: >> Exactly. For example, the "server" in question is a desktop machine >> at work. I regularly see transfer rates of 13MB/s. It's at a major >> university, which is by itself another high-risk factor, precisely >> because there are so many (often weakly protected) high-speed >> connections. > > That's a valid point, and I'd like to add that there is some > consideration: Servers are usually protected with proper means. > This goes especially for UNIX servers. Desktops, on the other > hand, can more easily be taken over (especially non-UNIX machines), > so if an attacker got his foot inside a network, it's very > useful to him. There are even trading platforms where criminals > buy and sell whole networks of compromised PCs. Of course, > everything happening inside such networks should be seen as > what it is: a threat to security. Just imagine some "clever > guy" uses telnet inside such a network to configure the > server... > > You mean like the default alternative to SSH for "Windows" boxes? Gotta love their arrogance Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Sat, 27 Jun 2009 21:17:11 -0400, Daniel Underwood wrote: > Exactly. For example, the "server" in question is a desktop machine > at work. I regularly see transfer rates of 13MB/s. It's at a major > university, which is by itself another high-risk factor, precisely > because there are so many (often weakly protected) high-speed > connections. That's a valid point, and I'd like to add that there is some consideration: Servers are usually protected with proper means. This goes especially for UNIX servers. Desktops, on the other hand, can more easily be taken over (especially non-UNIX machines), so if an attacker got his foot inside a network, it's very useful to him. There are even trading platforms where criminals buy and sell whole networks of compromised PCs. Of course, everything happening inside such networks should be seen as what it is: a threat to security. Just imagine some "clever guy" uses telnet inside such a network to configure the server... -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
> As I believe has already been answered in this thread, the better connected > a server is to the Internet, the higher its value to several varieties of > miscreants. Given a choice between a server connected via a close to > saturated T1 somewhere in the back waters of the Internet and a server with > multiple 100mbps+ connections to key backbones, somebody interested in > staging DOS attacks or using the server as a base to "explore" other > networks or ... is likely to find the latter server of greater interest. > About the only advantage I can think of for the former is that it's > probably, other things being equal, less likely to be properly maintained > and monitored. Exactly. For example, the "server" in question is a desktop machine at work. I regularly see transfer rates of 13MB/s. It's at a major university, which is by itself another high-risk factor, precisely because there are so many (often weakly protected) high-speed connections. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
Jos Chrispijn wrote: Daniel Underwood wrote: laptop to connect to the server. Due to the speed and location of the connection, it's a relatively high-risk target. Can you tell me what you mean with that? I mean, imho a server must been consider always a risk target. Perhaps I don't understand. As I believe has already been answered in this thread, the better connected a server is to the Internet, the higher its value to several varieties of miscreants. Given a choice between a server connected via a close to saturated T1 somewhere in the back waters of the Internet and a server with multiple 100mbps+ connections to key backbones, somebody interested in staging DOS attacks or using the server as a base to "explore" other networks or ... is likely to find the latter server of greater interest. About the only advantage I can think of for the former is that it's probably, other things being equal, less likely to be properly maintained and monitored. -- --Jon Radel j...@radel.com smime.p7s Description: S/MIME Cryptographic Signature
Re: Best practices for securing SSH server
Daniel Underwood wrote: laptop to connect to the server. Due to the speed and location of the connection, it's a relatively high-risk target. Can you tell me what you mean with that? I mean, imho a server must been consider always a risk target. Perhaps I don't understand. Jos Chrispijn ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Wed, 24 Jun 2009 17:12:59 +0200 cpghost wrote: > It all boils down to this: do you login from a secure machine > or not? Each tool has its own set of uses. When I want to log in > from a public terminal, I prefer OPIE; OPIE is probably fine in almost all cases, but you may wish to read the following thread: http://comments.gmane.org/gmane.os.freebsd.security.general/9272 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Wed, Jun 24, 2009 at 04:50:01PM +0200, Erik Norgaard wrote: > cpghost wrote: > > On Wed, Jun 24, 2009 at 03:53:15PM +0200, Erik Norgaard wrote: > > But port knocking can be useful and provide more security *if* you > > modify the kocking sequence algorithmically and make it, e.g. a > > function of time, source IP/range (and other factors). This could > > prevent a whole class of replay-attacks. > > > > Of course, you can modify the keys/passwords algorithmically and > > make them a function of time, source IP etc. as well... ;-) > > I don't think it's worth wasting time trying to repair a conceptually > bad idea, in particular when there are so many alternatives. > > Whichever way you turn around this idea, it boils down to a shared > secret. The security of a shared secret is inversely proportional to the > people knowing it, while the trouble of changing it is proportional to > the number knowing it. > > You've already got individual passwords in place. If your knock > sequence/shared secret is randomly chosen of say 1 million (any number > will do for the example) won't you get better security increasing the > entropy of the individual passwords equivalently? Agreed. > > And while we're at it: how about real OPIE? Or combining SSH keys, > > OPIE, and port knocking? > > What is the easier solution: implement port knocking or doubling the > length of your ssh keys? It all boils down to this: do you login from a secure machine or not? Each tool has its own set of uses. When I want to log in from a public terminal, I prefer OPIE; when I log in from home, I prefer SSH keys. Port knocking is an interesting technique, but as you pointed out, its only useful on machines with very few accounts. > Each of the technologies you mention can be tuned for higher security > using longer passwords, checking entropy when people choose a new > password, more ports in the range of your combination, more knocks etc. > > I don't get why you wish to combine different technologies rather than > tune the well tested and tried already implemented out of the box > methods for higher security. I totally agree. > BR, Erik > > -- > Erik N?rgaard > Ph: +34.666334818/+34.915211157 http://www.locolomo.org -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
cpghost wrote: On Wed, Jun 24, 2009 at 03:53:15PM +0200, Erik Norgaard wrote: But port knocking can be useful and provide more security *if* you modify the kocking sequence algorithmically and make it, e.g. a function of time, source IP/range (and other factors). This could prevent a whole class of replay-attacks. Of course, you can modify the keys/passwords algorithmically and make them a function of time, source IP etc. as well... ;-) I don't think it's worth wasting time trying to repair a conceptually bad idea, in particular when there are so many alternatives. Whichever way you turn around this idea, it boils down to a shared secret. The security of a shared secret is inversely proportional to the people knowing it, while the trouble of changing it is proportional to the number knowing it. You've already got individual passwords in place. If your knock sequence/shared secret is randomly chosen of say 1 million (any number will do for the example) won't you get better security increasing the entropy of the individual passwords equivalently? And while we're at it: how about real OPIE? Or combining SSH keys, OPIE, and port knocking? What is the easier solution: implement port knocking or doubling the length of your ssh keys? Each of the technologies you mention can be tuned for higher security using longer passwords, checking entropy when people choose a new password, more ports in the range of your combination, more knocks etc. I don't get why you wish to combine different technologies rather than tune the well tested and tried already implemented out of the box methods for higher security. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
> Point remains: Adding port knocking does not solve any security problem, it > only adds > complexity, cost, points of failure, inconvenience etc while making your > problem appear > differently and leaving you with the illusion of being more secure. I think that's grossly overstated, if not just plain wrong. Ceteris paribus, a system with port knocking is almost certainly more secure than a system without port knocking. It's not a guarantee against penetration. But even if it's only a heightened "degreee" of security not an additional "kind" of security measure (as you argue), it's still heightened security. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Wed, Jun 24, 2009 at 03:53:15PM +0200, Erik Norgaard wrote: > RW wrote: > > On Tue, 23 Jun 2009 22:37:12 +0200 > > Erik Norgaard wrote: > > > >> You're right, as long as port-knocking as a first pass authentication > >> scheme is not in wide spread use, then any attackers will not waste > >> time port-knocking. If ever port-knocking becomes common, attackers > >> will adapt and start knocking. > > > > It would be fairly straightforward to prevent that by having a > > combination of knocking ports and secret guard ports. When a guard port > > gets hit the sequence is broken, and the source IP gets blocked for a > > while. > > Great: Wouldn't that be the same as monitoring failed login attempts and > temporarily blacklisting ips that repeatedly connect through standard > methods? Hmmm..., you're right on this point. But port knocking can be useful and provide more security *if* you modify the kocking sequence algorithmically and make it, e.g. a function of time, source IP/range (and other factors). This could prevent a whole class of replay-attacks. Of course, you can modify the keys/passwords algorithmically and make them a function of time, source IP etc. as well... ;-) And while we're at it: how about real OPIE? Or combining SSH keys, OPIE, and port knocking? > Erik N?rgaard > Ph: +34.666334818/+34.915211157 http://www.locolomo.org -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
RW wrote: On Tue, 23 Jun 2009 22:37:12 +0200 Erik Norgaard wrote: You're right, as long as port-knocking as a first pass authentication scheme is not in wide spread use, then any attackers will not waste time port-knocking. If ever port-knocking becomes common, attackers will adapt and start knocking. It would be fairly straightforward to prevent that by having a combination of knocking ports and secret guard ports. When a guard port gets hit the sequence is broken, and the source IP gets blocked for a while. Great: Wouldn't that be the same as monitoring failed login attempts and temporarily blacklisting ips that repeatedly connect through standard methods? Point remains: Adding port knocking does not solve any security problem, it only adds complexity, cost, points of failure, inconvenience etc while making your problem appear differently and leaving you with the illusion of being more secure. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Tue, 23 Jun 2009 22:37:12 +0200 Erik Norgaard wrote: > You're right, as long as port-knocking as a first pass authentication > scheme is not in wide spread use, then any attackers will not waste > time port-knocking. If ever port-knocking becomes common, attackers > will adapt and start knocking. It would be fairly straightforward to prevent that by having a combination of knocking ports and secret guard ports. When a guard port gets hit the sequence is broken, and the source IP gets blocked for a while. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
Bill Moran wrote: In response to Erik Norgaard : Bill Moran wrote: In response to Erik Norgaard : 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 a
Re: Best practices for securing SSH server
In response to Erik Norgaard : > Bill Moran wrote: > > In response to Erik Norgaard : > > > >> - 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. There's a _HUGE_ difference between reloading the entire ruleset and updating a table. Don't trivialize that difference. > >> - 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. 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. > >> 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. ... 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. > > 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. Must be. I get multiple attacks per day. > 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. 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. > 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? 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. > > 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. 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. > There are other tricks that work well too, take a look at > > 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 ve
Re: Best practices for securing SSH server
Daniel Underwood wrote: A port-knocking sequence is really nothing different than a shared password. Technically and conceptually, that's true. But "practically", I'm not sure you're right. If in addition to attempting to enumerate the space of possible passwords, an attacker also enumerates the space of possible port-knocking sequences, then, yes, you're right. But I am willing to bet that the vast majority of attackers DO NOT attempt this. For this reason, I think well-designed port-knocking DOES add significant strength to the server. You're right, as long as port-knocking as a first pass authentication scheme is not in wide spread use, then any attackers will not waste time port-knocking. If ever port-knocking becomes common, attackers will adapt and start knocking. Or: if you want to keep port-knocking useful then don't recommend it to anyone! I think it is a bad idea, a wrong route to go. I think that there are so many other options for improving security that are well tested, much easier to deploy, cause less user annoyance etc etc. Since, as said, the knocking sequence is a shared secret, the more users you have the more likely it will be disclosed, and the more difficult it is to distribute new knocking sequences as more users are affected. More complexity, more possible failures and errors means more resources spent on user support, and more resources spend on configuring the new "toy". Resources that could be well spent on improving actual security and monitoring actual threats. You may deploy port-knocking at home for your own curriousity, but it has no value on your curriculum. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
> A port-knocking sequence is really nothing different than a shared password. Technically and conceptually, that's true. But "practically", I'm not sure you're right. If in addition to attempting to enumerate the space of possible passwords, an attacker also enumerates the space of possible port-knocking sequences, then, yes, you're right. But I am willing to bet that the vast majority of attackers DO NOT attempt this. For this reason, I think well-designed port-knocking DOES add significant strength to the server. If I'm misunderstanding port-knocking, please jump in and correct me... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Mon, Jun 22, 2009 at 22:50, prad wrote: > On Mon, 22 Jun 2009 21:16:35 -0400 > Daniel Underwood wrote: > >> Due to the speed and location of the >> connection, it's a relatively high-risk target. >> > why does the speed of a connection make it a higher risk? > is it because bruteforce techniques can capitalize on the speed? I's suspect it's a higher risk because the target is higher value. A high speed connection means more ability to do, well, whatever. Just a guess on my part, though. Kurt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
Bill Moran wrote: In response to Erik Norgaard : 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
In response to Erik Norgaard : > Daniel Underwood wrote: > >> I do not believe that tricks like running ssh on a > >> non standard port or using port-knocking provide > >> much extra security. > > > > I can understand that varying the port is not a very strong defensive > > measure, but I don't understand your point about port-knocking. > > > > If you configure a complex and seemingly random sequence of knocks > > before allowing an IP access to your ssh port, have you not > > significantly strengthened your ssh server? > > A port-knocking sequence is really nothing different than a shared > password. Since there is no user dialog, the sequence has to be known by > all users accessing the system. > > Basically you ask your users to authenticate twice - don't you think you > could get the same security with a standard deployment insisting on good > passwords or better yet, using keys? > > 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? > - 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. > 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). 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. If you're doing proper security monitoring, then reducing that log load is worthwhile. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
Daniel Underwood wrote: I do not believe that tricks like running ssh on a non standard port or using port-knocking provide much extra security. I can understand that varying the port is not a very strong defensive measure, but I don't understand your point about port-knocking. If you configure a complex and seemingly random sequence of knocks before allowing an IP access to your ssh port, have you not significantly strengthened your ssh server? A port-knocking sequence is really nothing different than a shared password. Since there is no user dialog, the sequence has to be known by all users accessing the system. Basically you ask your users to authenticate twice - don't you think you could get the same security with a standard deployment insisting on good passwords or better yet, using keys? You add an extra layer of inconvenience and complexity, more things that can fail and possibly result in an insecure server: - 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. - 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). And it can result in people being unable to access if the knocks are filtered at the source. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
> I do not believe that tricks like running ssh on a > non standard port or using port-knocking provide > much extra security. I can understand that varying the port is not a very strong defensive measure, but I don't understand your point about port-knocking. If you configure a complex and seemingly random sequence of knocks before allowing an IP access to your ssh port, have you not significantly strengthened your ssh server? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
"why does the speed of a connection make it a higher risk?" Super-fast connections are ideal targets for people to install private fileservers (among other things). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
99% of crack attempts are done by "kevin mitnick" methods, not password cracking. Absolutely true. Mitnick was an early exponent of Social Engineering attacks, which are still the easiest and most effective methods for Mitnick just chose the best possible friend - human stupidity. It never fails. breaking computer security. Now, if we could just get rid of all the users, our lives as Sys Admins would be a whole lot easier... Just make sure that one user can't do mess to others, and to log every logins. Then it's no more your problem, as users can only hurt themselves. Don't care about their security if they don't care by themselves. Cheers, Matthew [*] It's amazing how many people, when you tell them to use a mix of upper and lower case letters, just capitalize the *first* letter of their password. because most people don't understand what are passwords for. They just treat them as a part of required ceremony. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
99% of crack attempts are done by "kevin mitnick" methods, not password cracking. You're right about the probability of password breaking, but personally I installed denyhosts just because I got sick of this: indeed, it's very useful but it's not a requirement at all to be secure :) The only requirements for security are: 1) use proper passwords, or keyfiles but with keyfiles stored on properly protected machine (geli, proper password for geli too) 2) it's not really wrong to use same (but well done - random) passwords in many places YOU administer, but never use the same password on any foreign places. 3) Store that password ONLY in brain. As herds of morons don't really understand what are passwords for, all points are usually not respected, point 3 being the most common :) You want to crack into company server - just look at monitors and notes glued to it. If you can't - ask a charwoman working there ;) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
2009/6/23 Wojciech Puchar : >> If for some reason you would prefer to use password authentication, I >> would recommend that you look into automatic brute force detection. >> There are a number of utilities in ports available for this purpose, >> including security/sshguard and security/denyhosts. > > good, but not really important with properly chosen password. > You can't do more than maybe 10 attempts/second this way, while cracking 10 > character password consisting of just small letters and digits needs > > 36^10=3656158440062976 possible passwords, and over 11 milion years to check > all possibilities, so say 10 years if someone is really lucky and will > get it after checking 1% possible password. > > Of course - you must not look at logs in 10 years and not see this 10 > attempts per second. > > > > I give this example against common paranoia that exist on that group - mix > of real "security paranoid" persons and pseudo-experts that like to repeat > "intelligent" phrases to show up themselves. > > Actually - there is no need for extra protection for ssh, but for humans. > > 99% of crack attempts are done by "kevin mitnick" methods, not password > cracking. You're right about the probability of password breaking, but personally I installed denyhosts just because I got sick of this: Aug 22 00:46:21 amnesiac sshd[63107]: error: PAM: authentication error for illegal user adrian from adsl-76-193-128-193.dsl.scrm01.sbcglobal.net Aug 22 00:46:21 amnesiac sshd[63107]: Failed keyboard-interactive/pam for invalid user adrian from 76.193.128.193 port 2901 ssh2 Aug 22 00:46:23 amnesiac sshd[63110]: error: PAM: authentication error for illegal user agfa from adsl-76-193-128-193.dsl.scrm01.sbcglobal.net Aug 22 00:46:23 amnesiac sshd[63110]: Failed keyboard-interactive/pam for invalid user agfa from 76.193.128.193 port 3165 ssh2 Aug 22 00:46:26 amnesiac sshd[63113]: error: PAM: authentication error for illegal user agneta from adsl-76-193-128-193.dsl.scrm01.sbcglobal.net Aug 22 00:46:26 amnesiac sshd[63113]: Failed keyboard-interactive/pam for invalid user agneta from 76.193.128.193 port 3338 ssh2 Aug 22 00:46:29 amnesiac sshd[63116]: error: PAM: authentication error for illegal user ahren from adsl-76-193-128-193.dsl.scrm01.sbcglobal.net Aug 22 00:46:29 amnesiac sshd[63116]: Failed keyboard-interactive/pam for invalid user ahren from 76.193.128.193 port 3499 ssh2 10,000 lines of this in _every_ security digest I get off my server. No I haven't changed any IP addresses, either. Now I get: Added the following hosts to /etc/hosts.evil: 89.232.63.160 87.117.236.15 Much easier to read... Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
You can't do more than maybe 10 attempts/second this way, while cracking 10 character password consisting of just small letters and digits needs 10 characters is a longer than usual password. Most people have been conditioned into using a 7 or 8 character password, which is at least a so that's the answer how to secure SSH server. use 10 letter random passwords. 36^10=3656158440062976 possible passwords, and over 11 milion years to check all possibilities, so say 10 years if someone is really lucky and will get it after checking 1% possible password. There is a very big flaw in your analysis here. You're assuming that the passwords people might use are randomly and evenly distributed over So you already confirmed what i say. It's human problem - for example not using random passwords. Talking about security within that context is a joke. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
Wojciech Puchar wrote: >> If for some reason you would prefer to use password authentication, I >> would recommend that you look into automatic brute force detection. >> There are a number of utilities in ports available for this purpose, >> including security/sshguard and security/denyhosts. > > good, but not really important with properly chosen password. > You can't do more than maybe 10 attempts/second this way, while cracking > 10 character password consisting of just small letters and digits needs 10 characters is a longer than usual password. Most people have been conditioned into using a 7 or 8 character password, which is at least a 1000 times easier to crack using your measure. (Still a pretty big possible space though). > 36^10=3656158440062976 possible passwords, and over 11 milion years to > check all possibilities, so say 10 years if someone is really lucky > and will get it after checking 1% possible password. There is a very big flaw in your analysis here. You're assuming that the passwords people might use are randomly and evenly distributed over the whole possible password space. That is simply untrue. A lot of people -- perhaps the majority -- will use a password consisting of an English word, possibly with StUdLy CaPs or 3lite SP3LL1NG and with some random extra characters!*99 tacked on[*]. That's a whole lot smaller search space -- and it must be possible to brute-force passwords or it wouldn't be worthwhile for the brute-force attackers to keep trying. Agreed however that if people can be educated to use good passwords then a brute force attack like this really is unfeasible. I like apg(1) for generating passwords where there is no alternative to using strong crypto. > Of course - you must not look at logs in 10 years and not see this > 10 attempts per second. Sure. My experience is that any machine on the internet with a port 22 listener will attract about 2 to 5 brute force attackers a day -- that is, a sequence of brute force attempts originating from 2 -- 5 independent IPs per day. In fact, given that you have taken reasonable measures like using ssh keys exclusively or enforcing strong passwords then the biggest problems caused by these sort of attacks are the drain on system resources and the excess verbiage in log files. Getting rid of that is why I like to implement connection-rate based SSH blocking via pf(4) -- not because it gives any extra security. > I give this example against common paranoia that exist on that group - > mix of real "security paranoid" persons and pseudo-experts that like to > repeat "intelligent" phrases to show up themselves. > > Actually - there is no need for extra protection for ssh, but for humans. > > 99% of crack attempts are done by "kevin mitnick" methods, not password > cracking. Absolutely true. Mitnick was an early exponent of Social Engineering attacks, which are still the easiest and most effective methods for breaking computer security. Now, if we could just get rid of all the users, our lives as Sys Admins would be a whole lot easier... Cheers, Matthew [*] It's amazing how many people, when you tell them to use a mix of upper and lower case letters, just capitalize the *first* letter of their password. -- Dr Matthew J Seaman MA, D.Phil. Flat 3 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW, UK signature.asc Description: OpenPGP digital signature
Re: Best practices for securing SSH server
If for some reason you would prefer to use password authentication, I would recommend that you look into automatic brute force detection. There are a number of utilities in ports available for this purpose, including security/sshguard and security/denyhosts. good, but not really important with properly chosen password. You can't do more than maybe 10 attempts/second this way, while cracking 10 character password consisting of just small letters and digits needs 36^10=3656158440062976 possible passwords, and over 11 milion years to check all possibilities, so say 10 years if someone is really lucky and will get it after checking 1% possible password. Of course - you must not look at logs in 10 years and not see this 10 attempts per second. I give this example against common paranoia that exist on that group - mix of real "security paranoid" persons and pseudo-experts that like to repeat "intelligent" phrases to show up themselves. Actually - there is no need for extra protection for ssh, but for humans. 99% of crack attempts are done by "kevin mitnick" methods, not password cracking. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
connection, it's a relatively high-risk target. What are some good practices for securing this SSH server. Is using a stored key safer than a password in this instance? I have no If your password is not trivial, then it is secure. using RSA/DSA keys is as good, if you are sure nobody will get it from your laptop. i use keyfiles on every place i have to use ssh regularly. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Mon,06/22/09 [21:16:35], Daniel Underwood wrote: > On a BSD box at work (at an extremely fast connection and static IP), > I run an SSH server. I am the only person who uses the server, but I > use it from some locations that are behind a dynamic IP (so I can't > set pf rules to filter by IP). I will always, however, use the same > laptop to connect to the server. Due to the speed and location of the > connection, it's a relatively high-risk target. > > What are some good practices for securing this SSH server. Is using a > stored key safer than a password in this instance? I have no > experience with port-knocking, but I'd appreciate some tips or > suggested beginning references... I welcome any and all advice. > > Note: I do require X11 forwarding (not sure whether that's relevant > information) > > TIA, > Daniel To block bruteforce probes on ssh I use pf with it's great function 'max-src-conn-rate'. man pf.conf provides some useful hints. -- Best regards, Jeff | "Nobody wants to say how this works. | | Maybe nobody knows ..." | | Xorg.conf(5)| ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
Daniel Underwood wrote: On a BSD box at work (at an extremely fast connection and static IP), I run an SSH server. I am the only person who uses the server, but I use it from some locations that are behind a dynamic IP (so I can't set pf rules to filter by IP). I will always, however, use the same laptop to connect to the server. Due to the speed and location of the connection, it's a relatively high-risk target. What are some good practices for securing this SSH server. Is using a stored key safer than a password in this instance? I have no experience with port-knocking, but I'd appreciate some tips or suggested beginning references... I welcome any and all advice. Note: I do require X11 forwarding (not sure whether that's relevant information) Hi: If you're the only one using this server then you definitely should allow key authentication only, there are lots of automatic brute force attacks with password authentication, even if they only try bad passwords. Second, you should allow login only for the relevant user(s)/group(s), using AllowUsers/AllowGroups, and ofcourse disable root login. Third, even if you connect from dynamic ips, you can filter a lot of undesired connections. From the regional registries you can download address delegation files and filter out ranges assigned to countries that you'll never plan visiting, or even enable/disable countries. I created a script for generating such lists, www.locolomo.org/pub/src/toolbox/inet.pl I do not believe that tricks like running ssh on a non standard port or using port-knocking provide much extra security. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Mon, 22 Jun 2009 21:16:35 -0400 Daniel Underwood wrote: > Due to the speed and location of the > connection, it's a relatively high-risk target. > why does the speed of a connection make it a higher risk? is it because bruteforce techniques can capitalize on the speed? -- In friendship, prad ... with you on your journey Towards Freedom http://www.towardsfreedom.com (website) Information, Inspiration, Imagination - truly a site for soaring I's ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On 6/22/09, Daniel Underwood wrote:
> On a BSD box at work (at an extremely fast connection and static IP),
> I run an SSH server. I am the only person who uses the server, but I
> use it from some locations that are behind a dynamic IP (so I can't
> set pf rules to filter by IP). I will always, however, use the same
> laptop to connect to the server. Due to the speed and location of the
> connection, it's a relatively high-risk target.
>
> What are some good practices for securing this SSH server. Is using a
> stored key safer than a password in this instance? I have no
> experience with port-knocking, but I'd appreciate some tips or
> suggested beginning references... I welcome any and all advice.
>
> Note: I do require X11 forwarding (not sure whether that's relevant
> information)
>
> TIA,
> Daniel
My remote ends are "dynamic" too, but since everywhere I go keeps the
routers online 24/7, the IP is almost static.
Here's my suggestion. I think it might work, by adding a small dns
hit every packet to port 22 goes to the box. My config is similar
table const { 1.2.3.0/25 10.20.30.0/24 }
<..standard rules..>
pass in on $ext_if from {http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Mon, Jun 22, 2009 at 9:16 PM, Daniel Underwood wrote: > On a BSD box at work (at an extremely fast connection and static IP), > I run an SSH server. I am the only person who uses the server, but I > use it from some locations that are behind a dynamic IP (so I can't > set pf rules to filter by IP). I will always, however, use the same > laptop to connect to the server. Due to the speed and location of the > connection, it's a relatively high-risk target. > > What are some good practices for securing this SSH server. Is using a > stored key safer than a password in this instance? I have no > experience with port-knocking, but I'd appreciate some tips or > suggested beginning references... I welcome any and all advice. > > Note: I do require X11 forwarding (not sure whether that's relevant > information) > > TIA, > Daniel > Even though your IP is dynamic, I'd imagine you could still set pf rules to only allow SSH from certain IP ranges, which is better than nothing. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Tue, Jun 23, 2009 at 9:43 AM, Benjamin Lee wrote: > On 06/22/2009 06:16 PM, Daniel Underwood wrote: >> On a BSD box at work (at an extremely fast connection and static IP), >> I run an SSH server. I am the only person who uses the server, but I >> use it from some locations that are behind a dynamic IP (so I can't >> set pf rules to filter by IP). I will always, however, use the same >> laptop to connect to the server. Due to the speed and location of the >> connection, it's a relatively high-risk target. >> >> What are some good practices for securing this SSH server. Is using a >> stored key safer than a password in this instance? I have no >> experience with port-knocking, but I'd appreciate some tips or >> suggested beginning references... I welcome any and all advice. >> >> Note: I do require X11 forwarding (not sure whether that's relevant >> information) > > I have password authentication disabled on my public SSH server. You > can accomplish this by setting: > > ChallengeResponseAuthentication no > > in /etc/ssh/sshd_config. See sshd_config(5) for more information. > > This allows you to enforce the use of stronger authentication methods > (e.g. public key). Keep in mind, however, that this setup will only be > secure if you keep your alternate credentials (e.g. private key) secure > as well. > > If for some reason you would prefer to use password authentication, I > would recommend that you look into automatic brute force detection. > There are a number of utilities in ports available for this purpose, > including security/sshguard and security/denyhosts. I'd recommend changing the listening port to something other than 22. This reduces brute-forcing attempts by script-kiddie tools. Public key authentication should be mandatory, in addition to having a passphrase to your private key. Make sure your laptop is secure. Stay on top of the security lists for openssh vulnerabilities. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On Mon, Jun 22, 2009 at 9:43 PM, Benjamin Lee wrote: > On 06/22/2009 06:16 PM, Daniel Underwood wrote: > > On a BSD box at work (at an extremely fast connection and static IP), > > I run an SSH server. I am the only person who uses the server, but I > > use it from some locations that are behind a dynamic IP (so I can't > > set pf rules to filter by IP). I will always, however, use the same > > laptop to connect to the server. Due to the speed and location of the > > connection, it's a relatively high-risk target. > > > > What are some good practices for securing this SSH server. Is using a > > stored key safer than a password in this instance? I have no > > experience with port-knocking, but I'd appreciate some tips or > > suggested beginning references... I welcome any and all advice. > > > > Note: I do require X11 forwarding (not sure whether that's relevant > information) > > I have password authentication disabled on my public SSH server. You > can accomplish this by setting: > > ChallengeResponseAuthentication no > > in /etc/ssh/sshd_config. See sshd_config(5) for more information. > > This allows you to enforce the use of stronger authentication methods > (e.g. public key). Keep in mind, however, that this setup will only be > secure if you keep your alternate credentials (e.g. private key) secure > as well. > > If for some reason you would prefer to use password authentication, I > would recommend that you look into automatic brute force detection. > There are a number of utilities in ports available for this purpose, > including security/sshguard and security/denyhosts. > > > -- > Benjamin Lee > http://www.b1c1l1.com/ > > prevent brute force scans : option a ( my favorite ) - change ssh port number option b ( works just as well, but with more junk in your logs ) - install brute force blocker ( its in the ports .. ) create explicit login group : add AllowGroups groupname to your sshd config add the group to your groups file and make sure you / anyone with access is member of that group. force ssh version 2 only - just for kicks :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Best practices for securing SSH server
On 06/22/2009 06:16 PM, Daniel Underwood wrote: > On a BSD box at work (at an extremely fast connection and static IP), > I run an SSH server. I am the only person who uses the server, but I > use it from some locations that are behind a dynamic IP (so I can't > set pf rules to filter by IP). I will always, however, use the same > laptop to connect to the server. Due to the speed and location of the > connection, it's a relatively high-risk target. > > What are some good practices for securing this SSH server. Is using a > stored key safer than a password in this instance? I have no > experience with port-knocking, but I'd appreciate some tips or > suggested beginning references... I welcome any and all advice. > > Note: I do require X11 forwarding (not sure whether that's relevant > information) I have password authentication disabled on my public SSH server. You can accomplish this by setting: ChallengeResponseAuthentication no in /etc/ssh/sshd_config. See sshd_config(5) for more information. This allows you to enforce the use of stronger authentication methods (e.g. public key). Keep in mind, however, that this setup will only be secure if you keep your alternate credentials (e.g. private key) secure as well. If for some reason you would prefer to use password authentication, I would recommend that you look into automatic brute force detection. There are a number of utilities in ports available for this purpose, including security/sshguard and security/denyhosts. -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
