Bo Lynch wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
The simplest thing is to change the port. I know it's "security through obscurity", but it works well and can be used along with whatever other security enhancements you care to use.
Bowie Bailey wrote:
Bo Lynch wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
The simplest thing is to change the port. I know it's "security through obscurity", but it works well and can be used along with whatever other security enhancements you care to use.
By changing the ports on all our servers to a high (above 1024) port, we have eliminated SSH scans altogether - been running like that for a few years now without any problems.
I also add a small script in /etc/profile to email me when someone logs in via SSH, since only a few privileged ppl should use SSH altogether
On Tue, July 22, 2008 09:34, Rudi Ahlers wrote:
By changing the ports on all our servers to a high (above 1024) port, we have eliminated SSH scans altogether - been running like that for a few years now without any problems.
The next step up from that is some form of "port knocking" scheme -- where the outsider must first attempt to connect to some particular *other* port to trigger ssh to be ready to listen on the (non-standard) SSH port.
On the other hand, why are people so worried about SSH scans? I'm worried about who actually gets in, not who connects to the port. Strong password quality enforcement, or maybe requiring public-key authentication, seem like a more useful response. (I'm seeing a lot of failed ssh connects myself right now. Another system here has been blocking every /24 we get a failed connect from, with the result that they had to add a special rule to let my home systems log in! This could easily result in my being unable to get in from arbitrary locations in the field in an emergency, which seems not good.)
On Tue, Jul 22, 2008 at 8:16 AM, David Dyer-Bennet dd-b@dd-b.net wrote:
The next step up from that is some form of "port knocking" scheme -- where the outsider must first attempt to connect to some particular *other* port to trigger ssh to be ready to listen on the (non-standard) SSH port.
On the other hand, why are people so worried about SSH scans? I'm worried about who actually gets in, not who connects to the port. Strong password quality enforcement, or maybe requiring public-key authentication, seem like a more useful response. (I'm seeing a lot of failed ssh connects myself right now. Another system here has been blocking every /24 we get a failed connect from, with the result that they had to add a special rule to let my home systems log in! This could easily result in my being unable to get in from arbitrary locations in the field in an emergency, which seems not good.)
You have, perhaps, heard of denial-of-service attacks?
mhr
On Tue, July 22, 2008 11:57, MHR wrote:
On Tue, Jul 22, 2008 at 8:16 AM, David Dyer-Bennet dd-b@dd-b.net wrote:
The next step up from that is some form of "port knocking" scheme -- where the outsider must first attempt to connect to some particular *other* port to trigger ssh to be ready to listen on the (non-standard) SSH port.
On the other hand, why are people so worried about SSH scans? I'm worried about who actually gets in, not who connects to the port. Strong password quality enforcement, or maybe requiring public-key authentication, seem like a more useful response. (I'm seeing a lot of failed ssh connects myself right now. Another system here has been blocking every /24 we get a failed connect from, with the result that they had to add a special rule to let my home systems log in! This could easily result in my being unable to get in from arbitrary locations in the field in an emergency, which seems not good.)
You have, perhaps, heard of denial-of-service attacks?
Yes, but if there are *any* ports exposed, seems like those are equally possible. For that matter, if my ports were all closed, they could still be sending enough packets up my link that I was DOSed pretty much into oblivion.
On Tue, Jul 22, 2008 at 10:16:44AM -0500, David Dyer-Bennet wrote:
On Tue, July 22, 2008 09:34, Rudi Ahlers wrote:
By changing the ports on all our servers to a high (above 1024) port, we have eliminated SSH scans altogether - been running like that for a few years now without any problems.
.....
On the other hand, why are people so worried about SSH scans? I'm worried about who actually gets in, not who connects to the port. Strong password quality enforcement, or maybe requiring public-key authentication, seem like a more useful response.
For me it is signal to noise ratio. The longer the password file (valid users) the longer the list of connections and corresponding events (good and bad) that needs to be watched. Switching to another port with a large user community requires that the entire community be informed, configured and supported.
I like 'denyhosts' as a tool to limit these attacks, other good solutions also exist. Most distros now have 'denyhosts' as a prebuilt RPM which is a plus IMO (+). As others remarked disable root logins. Manage the 'su, sudo' list with care and populate the illegal user list agressivly based on the attack list observed in the logs. Users with su, sudo privledge should be limited to those that use sshkey login and understand what a strong pass word is.
Later, mitch
(+) a prebuilt RPM does present the issue that any flaw in the prebuilt can be widely exploited. As such updates should be watched for, tested and deployed promptly.
On Wed, July 23, 2008 12:25, Nifty Cluster Mitch wrote:
I like 'denyhosts' as a tool to limit these attacks, other good solutions also exist. Most distros now have 'denyhosts' as a prebuilt RPM which is a plus IMO (+). As others remarked disable root logins. Manage the 'su, sudo' list with care and populate the illegal user list agressivly based on the attack list observed in the logs. Users with su, sudo privledge should be limited to those that use sshkey login and understand what a strong pass word is.
Denyhosts has some interesting intelligence; I'm particularly pleased by the bit where it notifies me of dodgy logins (success after some failures). I also wonder what's being done to limit the denial-of-service possibilities of the "synchronization" mode. (*I* have added lines to /etc/hosts.allow to let key people in via SSH from their home and personal servers even if those addressed end up in hosts.deny.)
(And there's a denyhost rpm in, hmm, I think 'rf' is the rpmforge repository for Centos.)
I've been playing for years at a set of services to create firewall blocking commands based on attacks; delivery of email to spamtrap addresses, probes to closed ports, failed logins, etc. Studying the data, it looks like multiple copies of spam delivered to my host often come from different IPs, though (makes sense with botnets); that sort of information has lead me to be less aggressive about getting a system actually running. The SSH attacks I've seen currently *do* seem to come in series from the same IP, so blocking that has at least some benefit (mostly cleaning up my logs I suspect).
On Tue, 22 Jul 2008 16:34:54 +0200 Rudi Ahlers Rudi@SoftDux.com wrote:
Bowie Bailey wrote:
Bo Lynch wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
The simplest thing is to change the port. I know it's "security through obscurity", but it works well and can be used along with whatever other security enhancements you care to use.
By changing the ports on all our servers to a high (above 1024) port, we have eliminated SSH scans altogether - been running like that for a few years now without any problems.
I also add a small script in /etc/profile to email me when someone logs in via SSH, since only a few privileged ppl should use SSH altogether
Interesting idea with this script thing. Can you provide more details or the script?
lucian@lastdot.org wrote:
On Tue, 22 Jul 2008 16:34:54 +0200 Rudi Ahlers Rudi@SoftDux.com wrote:
Bowie Bailey wrote:
Bo Lynch wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
The simplest thing is to change the port. I know it's "security through obscurity", but it works well and can be used along with whatever other security enhancements you care to use.
By changing the ports on all our servers to a high (above 1024) port, we have eliminated SSH scans altogether - been running like that for a few years now without any problems.
I also add a small script in /etc/profile to email me when someone logs in via SSH, since only a few privileged ppl should use SSH altogether
Interesting idea with this script thing. Can you provide more details or the script? _______________________________________________
Yea, it's simple :)
echo 'SSH (localhost.localdomain) on:' `date` `who` | mail -s "Alert: Access from `who | cut -d"(" -f2 | cut -d")" -f1`" xxxxx@yyy.com
Rudi Ahlers wrote:
lucian@lastdot.org wrote:
On Tue, 22 Jul 2008 16:34:54 +0200 Rudi Ahlers Rudi@SoftDux.com wrote:
Bowie Bailey wrote:
Bo Lynch wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
The simplest thing is to change the port. I know it's "security through obscurity", but it works well and can be used along with whatever other security enhancements you care to use.
By changing the ports on all our servers to a high (above 1024) port, we have eliminated SSH scans altogether - been running like that for a few years now without any problems.
I also add a small script in /etc/profile to email me when someone logs in via SSH, since only a few privileged ppl should use SSH altogether
Interesting idea with this script thing. Can you provide more details or the script? _______________________________________________
Yea, it's simple :)
echo 'SSH (localhost.localdomain) on:' `date` `who` | mail -s "Alert: Access from `who | cut -d"(" -f2 | cut -d")" -f1`" xxxxx@yyy.com
OK. A chance to learn some more for me.
Is there a 'best' placement for this script in /etc/profile? Is localhost.localdomain a placeholder here for foo.bar.com?
Robert Moskowitz wrote:
Rudi Ahlers wrote:
lucian@lastdot.org wrote:
On Tue, 22 Jul 2008 16:34:54 +0200 Rudi Ahlers Rudi@SoftDux.com wrote:
Bowie Bailey wrote:
Bo Lynch wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
The simplest thing is to change the port. I know it's "security through obscurity", but it works well and can be used along with whatever other security enhancements you care to use.
By changing the ports on all our servers to a high (above 1024) port, we have eliminated SSH scans altogether - been running like that for a few years now without any problems.
I also add a small script in /etc/profile to email me when someone logs in via SSH, since only a few privileged ppl should use SSH altogether
Interesting idea with this script thing. Can you provide more details or the script? _______________________________________________
Yea, it's simple :)
echo 'SSH (localhost.localdomain) on:' `date` `who` | mail -s "Alert: Access from `who | cut -d"(" -f2 | cut -d")" -f1`" xxxxx@yyy.com
OK. A chance to learn some more for me.
Is there a 'best' placement for this script in /etc/profile? Is localhost.localdomain a placeholder here for foo.bar.com?
I put stuff like that right at the end, and localhost.localdomain is basically the server's name, from where I copied this script, so replace that with my.linux.server.com - or whatever
Bowie Bailey wrote:
I know it's "security through obscurity"
That's not necessarily a bad thing.
It is bad if it's the _only_ protection.
-
Bowie Bailey -
David Dyer-Bennet -
Florin Andrei -
lucianīŧ lastdot.org -
MHR -
Nifty Cluster Mitch -
Robert Moskowitz -
Rudi Ahlers