It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it but it did not. Any recommendations to improve security here? I notice these attacks come from a variety of IP's so pursuing one individual is probably not worthwhile.
[root@corona ~]# tail /var/log/secure Dec 25 17:51:09 corona sshd[24704]: Failed password for invalid user turid from ::ffff:203.115.124.116 port 38370 ssh2 Dec 25 17:51:12 corona sshd[24707]: Invalid user turnage from ::ffff:203.115.124.116 Dec 25 17:51:14 corona sshd[24707]: Failed password for invalid user turnage from ::ffff:203.115.124.116 port 38886 ssh2 Dec 25 17:51:18 corona sshd[24710]: Invalid user turnbough from ::ffff:203.115.124.116 Dec 25 17:51:20 corona sshd[24710]: Failed password for invalid user turnbough from ::ffff:203.115.124.116 port 39397 ssh2 Dec 25 17:51:22 corona sshd[24713]: Invalid user turner from ::ffff:203.115.124.116 Dec 25 17:51:25 corona sshd[24713]: Failed password for invalid user turner from ::ffff:203.115.124.116 port 40228 ssh2 Dec 25 17:51:27 corona sshd[24716]: Invalid user tursun from ::ffff:203.115.124.116 Dec 25 17:51:30 corona sshd[24716]: Failed password for invalid user tursun from ::ffff:203.115.124.116 port 40714 ssh2 Dec 25 21:20:46 corona sshd[24897]: Accepted password for root from ::ffff:10.1.1.17 port 4500 ssh2 [root@corona ~]#
-- -Gerald
Gerald writes:
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it but it did not. Any recommendations to improve security here?
Nope. You've already improved it as much as it could possibly be improved.
On 12/25/05, Gerald gwichman@gmail.com wrote:
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it but it did not. Any recommendations to improve security here? I notice these attacks come from a variety of IP's so pursuing one individual is probably not worthwhile.
[root@corona ~]# tail /var/log/secure Dec 25 17:51:09 corona sshd[24704]: Failed password for invalid user turid from ::ffff:203.115.124.116 port 38370 ssh2 Dec 25 17:51:12 corona sshd[24707]: Invalid user turnage from ::ffff:203.115.124.116 Dec 25 17:51:14 corona sshd[24707]: Failed password for invalid user turnage from ::ffff:203.115.124.116 port 38886 ssh2 Dec 25 17:51:18 corona sshd[24710]: Invalid user turnbough from ::ffff:203.115.124.116 Dec 25 17:51:20 corona sshd[24710]: Failed password for invalid user turnbough from ::ffff:203.115.124.116 port 39397 ssh2 Dec 25 17:51:22 corona sshd[24713]: Invalid user turner from ::ffff:203.115.124.116 Dec 25 17:51:25 corona sshd[24713]: Failed password for invalid user turner from ::ffff:203.115.124.116 port 40228 ssh2 Dec 25 17:51:27 corona sshd[24716]: Invalid user tursun from ::ffff:203.115.124.116 Dec 25 17:51:30 corona sshd[24716]: Failed password for invalid user tursun from ::ffff:203.115.124.116 port 40714 ssh2 Dec 25 21:20:46 corona sshd[24897]: Accepted password for root from ::ffff:10.1.1.17 port 4500 ssh2 [root@corona ~]#
-- -Gerald
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Gerald,
You might want to look into changing your sshd so it accepts keyed access only. Just learning ssh myself so I'm sketchy on details.
John Purser
On Sun, 2005-12-25 at 21:24 -0800, Gerald wrote:
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it but it did not. Any recommendations to improve security here?
Since you ask for "any" recommendations...
If you don't need remote SSH access, configure the server not to listen to the outside world. Other options might be to limit what addresses it'll accept connections from, or which accounts can be remotely logged into.
Even longer passwords than you care for, to make it harder to brute force crack.
From: "Gerald" gwichman@gmail.com
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it but it did not. Any recommendations to improve security here? I notice these attacks come from a variety of IP's so pursuing one individual is probably not worthwhile.
[root@corona ~]# tail /var/log/secure Dec 25 17:51:09 corona sshd[24704]: Failed password for invalid user turid from ::ffff:203.115.124.116 port 38370 ssh2 Dec 25 17:51:12 corona sshd[24707]: Invalid user turnage from ::ffff:203.115.124.116 Dec 25 17:51:14 corona sshd[24707]: Failed password for invalid user turnage from ::ffff:203.115.124.116 port 38886 ssh2 Dec 25 17:51:18 corona sshd[24710]: Invalid user turnbough from ::ffff:203.115.124.116 Dec 25 17:51:20 corona sshd[24710]: Failed password for invalid user turnbough from ::ffff:203.115.124.116 port 39397 ssh2 Dec 25 17:51:22 corona sshd[24713]: Invalid user turner from ::ffff:203.115.124.116 Dec 25 17:51:25 corona sshd[24713]: Failed password for invalid user turner from ::ffff:203.115.124.116 port 40228 ssh2 Dec 25 17:51:27 corona sshd[24716]: Invalid user tursun from ::ffff:203.115.124.116 Dec 25 17:51:30 corona sshd[24716]: Failed password for invalid user tursun from ::ffff:203.115.124.116 port 40714 ssh2 Dec 25 21:20:46 corona sshd[24897]: Accepted password for root from ::ffff:10.1.1.17 port 4500 ssh2 [root@corona ~]#
Unless the last one was you, Gerald, your machine is no longer your machine. Disconnect it, save important data, reformat, and reload your software from KNOWN GOOD backups.
{^_^}
Gerald wrote:
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it but it did not. Any recommendations to improve security here? I notice
I'm very dubious that these attack scripts can find your new sshd listen port if it is not directly associated with ssh protocol. The first thing to check is that you actually moved it. Here's a box listening on 22:
# netstat -pln | grep sshd tcp 0 0 :::22 :::* LISTEN 3819/sshd
Note that you would have needed
service sshd restart
after changing
/etc/ssh/sshd_config
-Andy
On 12/26/05, jdow jdow@earthlink.net wrote:
From: "Gerald" gwichman@gmail.com
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it but it did not. Any recommendations to improve security here? I notice these attacks come from a variety of IP's so pursuing one individual is probably not worthwhile.
[root@corona ~]# tail /var/log/secure
[. . . snip snip snip . . . ]
tursun from ::ffff:203.115.124.116 port 40714 ssh2 Dec 25 21:20:46 corona sshd[24897]: Accepted password for root from ::ffff:10.1.1.17 port 4500 ssh2 [root@corona ~]#
Unless the last one was you, Gerald, your machine is no longer your machine. Disconnect it, save important data, reformat, and reload your software from KNOWN GOOD backups.
{^_^}
The last one is from an RFC1918 reserved address (10.0.0.0/8) and is from his internal network. All the others are from the public Internet. I'd assume that's him logging into his own machine. ;-)
-- Chris
"I trust the Democrats to take away my money, which I can afford. I trust the Republicans to take away my freedom, which I cannot."
On Mon, 2005-12-26 at 02:04, Tim wrote:
On Sun, 2005-12-25 at 21:24 -0800, Gerald wrote:
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it but it did not. Any recommendations to improve security here?
Since you ask for "any" recommendations...
If you don't need remote SSH access, configure the server not to listen to the outside world. Other options might be to limit what addresses it'll accept connections from, or which accounts can be remotely logged into.
Even longer passwords than you care for, to make it harder to brute force crack.
Good suggestions as well as the one to use keys if you need ssh access.
Since someone took the time to scan for and find your ssh port then they are targeting you specifically. If you can, identify the IP they are coming from and put them in your iptables list to block all access from that IP. If they are moving to different IP addresses check into things like portsentry or the other one (ipdeny?) that will examine log files for hack attempts and dynamically add those IP addresses to your iptables deny list.
On Monday 26 December 2005 00:24, Gerald wrote:
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it
You probably don't want to advertise the port you chose either as per your mail.
You may also wish to set:
PermitRootLogin no AllowUsers gerald other1 other2 etc
(i.e. limit to users you care about with known strong passwords or keys only as someone else suggested).
DUmb question - did you service sshd restart to make sure your changes were picked up?
\g/
Thanks Andy.. You are correct it was not moved over. I fixed this and it now works properly on port 50022
g
On 12/26/05, Andy Green andy@warmcat.com wrote:
Gerald wrote:
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it but it did not. Any recommendations to improve security here? I notice
I'm very dubious that these attack scripts can find your new sshd listen port if it is not directly associated with ssh protocol. The first thing to check is that you actually moved it. Here's a box listening on 22:
# netstat -pln | grep sshd tcp 0 0 :::22 :::* LISTEN 3819/sshd
Note that you would have needed
service sshd restart
after changing
/etc/ssh/sshd_config
-Andy
good suggestion.. I limited the users and restricted root.
does anyone know how to change the defualt "login as:" banner to something else?
Gerald
On 12/26/05, Mail List lists@sapience.com wrote:
On Monday 26 December 2005 00:24, Gerald wrote:
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it
You probably don't want to advertise the port you chose either as per your mail.
You may also wish to set:
PermitRootLogin no AllowUsers gerald other1 other2 etc(i.e. limit to users you care about with known strong passwords or keys only as someone else suggested).
DUmb question - did you service sshd restart to make sure your changes were picked up?
\g/
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
-- -Gerald
I wrote this script to thwart the brute force ssh hackers. It isn't the most efficient but it works. it blocks their ip using iptables. I run it every min via cron
#!/usr/bin/perl
###vars
$lines=5000; #lines to tail $pos=10; #count lines that are positive to kick ip $lp=$lines+1000;
$log=`tail -n $lp /var/log/secure | grep 'Failed password' | tail -n $lines`;
@nage = split (/\n/,$log); foreach $ip (@nage) { $ip=~ /(\d*.\d*.\d*.\d*)/; push @ips,$1; }
@ips_1=@ips; @ips_2=@ips;
#gets a unique ip list foreach $snip (@ips) { $n=0; $t=0; while (@ips_1[$n]) { if ($snip == $ips_1[$n]) { if ($t==0) { #print "$snip==$ips_1[$n]\n"; $move=0; foreach $cnip (@sips) { if ($snip==$cnip) { $move++; } } if ($move==0) { push @sips, $snip; } $t++; } } $n++; } }
#takes the unique list and counts against the full ip list $nn=0; foreach $nip (@sips) { $m=0; $n=0; while (@ips_2[$n]) { if ($nip==@ips_2[$n]) {$m++;} $n++; } if ($pos<$m) { if ($nn==0) { $cur=`/sbin/iptables -L -n`; } if ($cur!~/$nip/) {`/sbin/iptables -t filter -I INPUT -s $nip -j DROP`;} } }
Gerald wrote:
good suggestion.. I limited the users and restricted root.
does anyone know how to change the defualt "login as:" banner to something else?
Gerald
On 12/26/05, Mail List lists@sapience.com wrote:
On Monday 26 December 2005 00:24, Gerald wrote:
It looks like i'm getting a dictionary attack on my system. I moved ssh to another port instead of 22 in hopes that would put a halt to it
You probably don't want to advertise the port you chose either as per your mail.
You may also wish to set:
PermitRootLogin no AllowUsers gerald other1 other2 etc(i.e. limit to users you care about with known strong passwords or keys only as someone else suggested).
DUmb question - did you service sshd restart to make sure your changes were picked up?
\g/
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
-- -Gerald
From: "Christian Motta" chris@agweb.net
I wrote this script to thwart the brute force ssh hackers. It isn't the most efficient but it works. it blocks their ip using iptables. I run it every min via cron
#!/usr/bin/perl
Thanks for the nice script Chris. I may add that to deepen my defenses.
I have found, however, that a simple three line iptables addition seems to work like a champ, except for filling up the log.
===8<--- iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 120 --hitcount 3 -j LOG --log-prefix 'SSH REJECT: ' $iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 120 --hitcount 3 -j REJECT --reject-with tcp-reset ===8<---
I've been taking to looking at where large numbers of rejected connections come from and have been adding them to the firewall manually. Your script can probably be adapted.
(It is amusing how long idiots will keep trying. I had a twit from India trying nearly 10,000 times today before I finally blocked him. He got two chances in that entire set to actually try to guess a password. He made two runs. And right at the start of the two runs he tried and got the predictable password failure. After that for an hour or more at a stretch he simply pounded that reject rule never getting into the system at all. Poor baby. It did prompt me to simply add blanket blocks for much of the APNIC space that's allocated to Asian countries I never expect to visit. It makes life easier.)
{^_-}
Below are the iptables rules that I use to block connections from the same address in a 30 second period. I get a couple of hits a day to this but not the thousands of attempts like before. You can set the timeout to whatever you want. The only drawback to this method is if you accidently fail to log in then you can't for 30 seconds. I also restrict root login, use Allow Users and I disabled all password authentication. I did leave it on port 22 though.
# this rule logs -A RH-Firewall-1-INPUT -m state --state NEW -m recent --name ssh- limit --update --seconds 30 -m tcp -p tcp --dport 22 -j LOG --log- level WARNING --log-prefix "ssh-limit " # this rule drops the packet if connection is already in list -A RH-Firewall-1-INPUT -m state --state NEW -m recent --name ssh- limit --update --seconds 30 -m tcp -p tcp --dport 22 -j DROP # this rule sets the list -A RH-Firewall-1-INPUT -m state --state NEW -m recent --name ssh- limit --set -m tcp -p tcp --dport 22 -j ACCEPT
"jdow" jdow@earthlink.net writes:
I have found, however, that a simple three line iptables addition seems to work like a champ, except for filling up the log.
===8<--- iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 120 --hitcount 3 -j LOG --log-prefix 'SSH REJECT: ' $iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 120 --hitcount 3 -j REJECT --reject-with tcp-reset ===8<---
This is indeed a lovely approach, but has a drawback: it can't tell the difference between many legit SSH connections and many bogus ones.
For example, if you are getting at a Subversion repository with 'svn+ssh://host/repo-stuff', then whole bunches of ssh connections will be made in rapid succession. You can always up the hitcount, but that's just a method waiting to fail (e.g. what if SVN does something unexpected that needs _lots_ of ssh connections).
Just FYI.
Will
From: "Will Partain" will.partain@verilab.com
"jdow" jdow@earthlink.net writes:
I have found, however, that a simple three line iptables addition seems to work like a champ, except for filling up the log.
===8<--- iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 120 --hitcount 3 -j LOG --log-prefix 'SSH REJECT: ' $iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 120 --hitcount 3 -j REJECT --reject-with tcp-reset ===8<---
This is indeed a lovely approach, but has a drawback: it can't tell the difference between many legit SSH connections and many bogus ones.
For example, if you are getting at a Subversion repository with 'svn+ssh://host/repo-stuff', then whole bunches of ssh connections will be made in rapid succession. You can always up the hitcount, but that's just a method waiting to fail (e.g. what if SVN does something unexpected that needs _lots_ of ssh connections).
Of course you must assess your particular needs and determine if limiting connections this way is appropriate. I'm not sure at the moment whether the tracking and blocking is per IP or not. If it is per IP address then it's easy enough to drop the time out to something reasonable for a SVN transaction but longer than no time at all. It would at least slow people down until you can block their IP completely.
{^_^}
On Mon, 2005-12-26 at 17:56 -0800, jdow wrote:
From: "Christian Motta" chris@agweb.net
I wrote this script to thwart the brute force ssh hackers. It isn't the most efficient but it works. it blocks their ip using iptables. I run it every min via cron
#!/usr/bin/perl
Thanks for the nice script Chris. I may add that to deepen my defenses.
I have found, however, that a simple three line iptables addition seems to work like a champ, except for filling up the log.
A nice dynamic iptables tool to monitor sshd and block attacks is sshdfilter. 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. Most of the attacks on my systems don't even get 2 attempts before they are blocked. I don't have root enabled for remote access so there is no worry there.
To avoid an enormous long iptables rule list the blocked addresses are unblocked after 3 days.
===8<--- iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 120 --hitcount 3 -j LOG --log-prefix 'SSH REJECT: ' $iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 120 --hitcount 3 -j REJECT --reject-with tcp-reset ===8<---
I've been taking to looking at where large numbers of rejected connections come from and have been adding them to the firewall manually. Your script can probably be adapted.
(It is amusing how long idiots will keep trying. I had a twit from India trying nearly 10,000 times today before I finally blocked him. He got two chances in that entire set to actually try to guess a password. He made two runs. And right at the start of the two runs he tried and got the predictable password failure. After that for an hour or more at a stretch he simply pounded that reject rule never getting into the system at all. Poor baby. It did prompt me to simply add blanket blocks for much of the APNIC space that's allocated to Asian countries I never expect to visit. It makes life easier.)
{^_-}
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.
Hope this helps,
James.
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. :-/
Hope this helps,
James.
E-mail address: james | Say it with flowers, send a triffid. @westexe.demon.co.uk |
Mike
On Mon, 2005-12-26 at 17:56 -0800, jdow wrote:
(It is amusing how long idiots will keep trying. I had a twit from India trying nearly 10,000 times today before I finally blocked him.
Um, maybe it was just a cron job?
On Tue, 2006-01-03 at 11:26 -0500, Michael H. Warfield wrote:
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.
Fully agree.
Differences in the system's behavior, based on usernames, visible from outside, are a security issue.
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)
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)
I acknowledge the flaws, but it is better than leaving ssh open for repeated attempts by the script kiddies.
Hope this helps,
James.
E-mail address: james | Say it with flowers, send a triffid. @westexe.demon.co.uk |
Mike
fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
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
On Tue, 2006-01-03 at 18:47 -0600, Jeff Vian wrote:
I acknowledge the flaws, but it is better than leaving ssh open for repeated attempts by the script kiddies.
It is not the only solution to the brute force SSH attacks, it's a solution with major flaws, and there are other solutions without significant flaws.
Moving the SSH port number plus an iptables-based rate limiter should be just as effective without the drawback of revealing account names.
Seriously, it's a basic computer security law. The external behavior of the system should not depend in any way on the account name being probed.
... without the drawback of revealing account names.
I'm not sure there is much value in hiding account names. This seems to be one of these pieces of "security through obscurity" that been passed down from one generation of computer user to the next and nobody has re-examined it recently.
1) In this day and age there are many mailing list archives and search engines that will happily tell you tons of user names on the various machines.
2) Other servers on the same machine will often reveal account names if you ask them nicely (http, smtp, finger, ident).
3) Anyone that cares about real security can configure ssh to only allow RSA or DSA keys of 1k-bits length. Knowing the account name isn't going to make it any easier for the attacker. The brute-force work factor is going to go from a 10^280 times the life of the universe to 10^270. Thats 10 with 270 zeros after it. It just isn't a threat.
I think its time for software to stop pretending that account names are a state secret and deal with the issue of a too small search space of human-typed passwords by never allowing those short passwords on the wire. This is how the RSA and DSA method in ssh works now and it is very effective at preventing breakins from brute force attacks.
-wolfgang
-
Andy Green -
Christian Motta -
Christofer C. Bell -
Florin Andrei -
Genes MailLists -
Gerald -
James Wilkinson -
jdow -
Jeff Vian -
John Purser -
Knute Johnson -
Michael H. Warfield -
Sam Varshavchik -
Scot L. Harris -
Tim -
Will Partain -
Wolfgang S. Rupprecht