[opensuse] dictionary attacks
Just about every day, often several times a day, my logs include hours of log entries that look like this: Jul 16 00:35:25 raid5 sshd[6966]: Invalid user admin from 83.18.244.42 Jul 16 00:35:30 raid5 sshd[6968]: Invalid user admin from 83.18.244.42 Jul 16 00:35:35 raid5 sshd[6972]: Invalid user admin from 83.18.244.42 Jul 16 00:35:40 raid5 sshd[6974]: Invalid user admin from 83.18.244.42 Jul 16 00:35:56 raid5 sshd[6981]: Invalid user test from 83.18.244.42 Jul 16 00:36:01 raid5 sshd[6983]: Invalid user test from 83.18.244.42 Jul 16 00:36:06 raid5 sshd[6985]: Invalid user webmaster from 83.18.244.42 Jul 16 00:36:11 raid5 sshd[6987]: Invalid user username from 83.18.244.42 Jul 16 00:36:16 raid5 sshd[6989]: Invalid user user from 83.18.244.42 Jul 16 00:36:26 raid5 sshd[6994]: Invalid user admin from 83.18.244.42 Jul 16 00:36:31 raid5 sshd[6996]: Invalid user test from 83.18.244.42 Jul 16 00:36:51 raid5 sshd[7017]: Invalid user danny from 83.18.244.42 Jul 16 00:36:56 raid5 sshd[7019]: Invalid user alex from 83.18.244.42 Jul 16 00:37:01 raid5 sshd[7022]: Invalid user brett from 83.18.244.42 Jul 16 00:37:06 raid5 sshd[7024]: Invalid user mike from 83.18.244.42 Jul 16 00:37:12 raid5 sshd[7027]: Invalid user alan from 83.18.244.42 Jul 16 00:37:18 raid5 sshd[7029]: Invalid user data from 83.18.244.42 Jul 16 00:37:22 raid5 sshd[7031]: Invalid user www-data from 83.18.244.42 Jul 16 00:37:28 raid5 sshd[7033]: Invalid user http from 83.18.244.42 Jul 16 00:37:33 raid5 sshd[7037]: Invalid user httpd from 83.18.244.42 Jul 16 00:37:38 raid5 sshd[7040]: Invalid user pop from 83.18.244.42 ..... and so on, ad nausium. Obviously, someone is trying to break in to my system via SSH. So far as I can tell from examining my logs and my systems (usually at least 4 other systems on my LAN are under simultaneous attacks from the same source(s), the daemon is successsfully withstanding the assault and the system is not compromised. My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space. Thanks in advance, Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 16/07/07, Richard Creighton <ricreig@gmail.com> wrote:
My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space.
set the following line FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh" in /etc/sysconfig/SuSEfirewall2 This will limit to a maximum of 3 attempts per 120s. Even more effective can be running sshd on an unusual port, or installing something like "fail2ban" _ Benjamin Weber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Benji Weber wrote:
On 16/07/07, Richard Creighton <ricreig@gmail.com> wrote:
My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space.
set the following line
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh"
in /etc/sysconfig/SuSEfirewall2 This will limit to a maximum of 3 attempts per 120s.
Even more effective can be running sshd on an unusual port, or installing something like "fail2ban"
Using keys instead of passwords is better. Also, if ssh is not used off site, simply block it at the firewall. -- Use OpenOffice.org <http://www.openoffice.org> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Benji Weber wrote:
On 16/07/07, Richard Creighton <ricreig@gmail.com> wrote:
My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space.
set the following line
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh"
in /etc/sysconfig/SuSEfirewall2 This will limit to a maximum of 3 attempts per 120s.
The log excerpt was despite a setting of: FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=5,blockseconds=300,recentname=ssh" which is similar to your suggestion. I will modify the hitcount and blockseconds but I am curious why it didn't block *all* subsequent attempts from that IP for the 'blockseconds' value. If you look at the log, it is obvious that if any blocking is occuring, it is only blocking more attempts of the same name but I can't tell for sure if it is trying new names almost instantly after being blocked or what, but it is obvious the IP isn't being blocked.
Even more effective can be running sshd on an unusual port, or installing something like "fail2ban"
I thought about an 'unusual port', but a port scanner would certainly find it as it found port 22. What is fail2ban? It looks like Google time :) Thanks for the heads-up. Richard
_ Benjamin Weber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-07-16 at 08:19 -0400, Richard Creighton wrote:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh"
in /etc/sysconfig/SuSEfirewall2 This will limit to a maximum of 3 attempts per 120s.
The log excerpt was despite a setting of:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=5,blockseconds=300,recentname=ssh"
which is similar to your suggestion. I will modify the hitcount and blockseconds but I am curious why it didn't block *all* subsequent attempts from that IP for the 'blockseconds' value. If you look at the log, it is obvious that if any blocking is occuring, it is only blocking more attempts of the same name but I can't tell for sure if it is trying new names almost instantly after being blocked or what, but it is obvious the IP isn't being blocked.
It doesn't even look at login name: it only looks at connections attempts to a certain port, no matter what that port is for. And I think that blocks should be logged. At least, a previous version of this idea did so.
Even more effective can be running sshd on an unusual port, or installing something like "fail2ban"
I thought about an 'unusual port', but a port scanner would certainly find it as it found port 22.
Interestingly, most of these scans are done by scripts that don't really scan every port. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGm2XgtTMYHG2NR9URArFnAJwPPbzOStxa7Bi4r022i28DzU+VsACdEZuG F4wQvq0n0CnixI24sjkf7dY= =g6lC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 16 July 2007, Richard Creighton wrote:
The log excerpt was despite a setting of:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=5,blockseconds=300,recentname= ssh"
I don't believe you had that in there correctly, because if you look a the times there were cases where there were 5 hits in the time period. In any case, your time period and counts are too high. 5 is too many. 3 is about right. 5 minutes is too long. 1 minute is about right. 3 bad attempts within a minute would then get them blocked for a minute and that will persist as long as they keep trying. Since I've done this on all my servers I see virtually no ssh attacks. -- _____________________________________ John Andersen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Benji Weber <b.weber@warwick.ac.uk> [07-16-07 05:04]:
set the following line
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh"
in /etc/sysconfig/SuSEfirewall2 This will limit to a maximum of 3 attempts per 120s.
This works *very* well, even better than fail2ban, imo. Is there a similar line that will effect the same on postifx attempts rather than using fail2ban? tks, -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Patrick Shanahan wrote:
* Benji Weber <b.weber@warwick.ac.uk> [07-16-07 05:04]:
set the following line
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh"
in /etc/sysconfig/SuSEfirewall2 This will limit to a maximum of 3 attempts per 120s.
This works *very* well, even better than fail2ban, imo. Is there a similar line that will effect the same on postifx attempts rather than using fail2ban?
Turns out that I have spent the morning trying to figure out why on my machine that didn't work at all. I perused the iptables -L and found the order of the rules produced by susefirewall2 is wrong IF you open the ssh port using the sysconfig editor OR the YAST2 firewall configururation Allowed Services advanced TCP ports external. It puts dpt:22 as ACCPT BEFORE the rule produced by the line shown above so that rule never gets executed. The solution is to go back into the sysconfig editor or YAST2 and remove the ssh port and then the above line and resultant rule becomes activated and works. It really isn't better than fail2ban in that it works at the same level, ie, at the firewall and the rule produced by fail2ban is the first rule examined and what I like, it is logged so I can easily produce a report to send a report to the offending site (that might not even know they have the worm) and suggest they clean house. As to your second question, I think if you were to examine the output of iptables -L and find the 2 (I believe) lines that make up the rules that make the above line function, you could change the dpt:22 to the port you need to monitor and add it manually. I've not seen anyplace in the GUI that has a place to do it. Assuming of course that you don't want to use fail2ban :) Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 29/07/07, Richard Creighton <ricreig@gmail.com> wrote:
Turns out that I have spent the morning trying to figure out why on my machine that didn't work at all. I perused the iptables -L and found the order of the rules produced by susefirewall2 is wrong IF you open the ssh port using the sysconfig editor OR the YAST2 firewall configururation Allowed Services advanced TCP ports external. It puts dpt:22 as ACCPT BEFORE the rule produced by the line shown above so that rule never gets executed. The solution is to go back into the sysconfig editor or YAST2 and remove the ssh port and then the above line and resultant rule becomes activated and works.
Yeah, you'll need to use either one or the other.
It really isn't better than fail2ban in that it works at the same level, ie, at the firewall and the rule produced by fail2ban is the first rule examined and what I like, it is logged so I can easily produce a report to send a report to the offending site (that might not even know they have the worm) and suggest they clean house.
IPTables can and is logged of course, see /var/log/firewall , you can adjust the verbosity of this etc, if you need the rule to be examined sooner you could put the rule the above generates into a /etc/sysconfig/scripts/SuSEfirewall2-custom , inserting the rule where you please. fail2ban might be less prone to DoS attack problems than the simple firewall rule though.
As to your second question, I think if you were to examine the output of iptables -L and find the 2 (I believe) lines that make up the rules that make the above line function, you could change the dpt:22 to the port you need to monitor and add it manually. I've not seen anyplace in the GUI that has a place to do it. Assuming of course that you don't want to use fail2ban :)
Yes, the rules are space separated, so FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh 0/0,tcp,25......" should work I believe. _ Benjamin Weber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Patrick Shanahan wrote:
* Benji Weber <b.weber@warwick.ac.uk> [07-16-07 05:04]:
set the following line
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh"
in /etc/sysconfig/SuSEfirewall2 This will limit to a maximum of 3 attempts per 120s.
This works *very* well, even better than fail2ban, imo. Is there a similar line that will effect the same on postifx attempts rather than using fail2ban?
Yikes - These are 2 different beasts. With ssh, users authenticate and gain access to your system. With smtp, users don't authenticate or gain access to your system, they simply send messages. What would you use as a measure of "bad" email senders? IMHO blocking off your smtp server would work out about as well as firewalling off the public web site which powers your business. If you want to limit the riffraff trying to send spam, the best tools are things like greylisting, RBLs etc. Look into those if you're serious about smtp. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
joe wrote:
Patrick Shanahan wrote:
* Benji Weber <b.weber@warwick.ac.uk> [07-16-07 05:04]:
set the following line
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh"
in /etc/sysconfig/SuSEfirewall2 This will limit to a maximum of 3 attempts per 120s. This works *very* well, even better than fail2ban, imo. Is there a similar line that will effect the same on postifx attempts rather than using fail2ban?
Yikes - These are 2 different beasts. With ssh, users authenticate and gain access to your system. With smtp, users don't authenticate or gain access to your system, they simply send messages. What would you use as a measure of "bad" email senders?
I don't think he wants to block off the public, just someone he has detected abusing. I have a friend that has a small newsletter she sends out to a growing list of people and recently she hit a limit from road-runner. She could receive mail just fine but when she hit the limit of the magic number of E-Mails, she couldn't connect to the SMTP server for 24 hours. I agree that counting packets like you do with SSHd is probably the wrong criteria, but detecting the IP of an incoming site that is attempting to post too many messages and then selectively turning off that IP at the firewall could be effective. I know the abuser could simply change IP numbers so the detector needs to watch at a higher level then notify the firewall about the new IP to block, but it could work....it does with RR...so, the measure of bad email senders could be any field in the SMTP header or even message content scanners like the one in many mail servers like Surgemail or reverse DNS checking or whatever is effective, coupled with turning off the current incoming IP. The server discards or rejects any bad messages it receives, but the firewall can prevent the messages from getting through in the first place once triggered. Spammers are likely to go somewhere easier, where are so many Windoze machines available :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Richard Creighton <ricreig@gmail.com> [07-29-07 15:46]:
I don't think he wants to block off the public, just someone he has detected abusing.
exactly and I am presently using fail2ban to block: [postfix-tcpwrapper] enabled = true filter = postfix action = hostsdeny[file=/etc/hosts.deny] mail[name=Postfix, dest=postmaster@localhost] logpath = /var/log/mail bantime = 300 which places 554 rejection ip into /etc/hosts.deny, but the firewall action denying rogue ssh attempts is cleaner, requires less resources and sees the ip sooner. is this correct: FW_SERVICES_ACCEPT_EXT="0/0,tcp,25,,hitcount=3,blockseconds=120 -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Patrick Shanahan wrote:
* Richard Creighton <ricreig@gmail.com> [07-29-07 15:46]:
I don't think he wants to block off the public, just someone he has detected abusing.
exactly and I am presently using fail2ban to block:
[postfix-tcpwrapper]
enabled = true filter = postfix action = hostsdeny[file=/etc/hosts.deny] mail[name=Postfix, dest=postmaster@localhost] logpath = /var/log/mail bantime = 300
which places 554 rejection ip into /etc/hosts.deny, but the firewall action denying rogue ssh attempts is cleaner, requires less resources and sees the ip sooner.
is this correct: FW_SERVICES_ACCEPT_EXT="0/0,tcp,25,,hitcount=3,blockseconds=120
So, any host that has a lot of messages to send to users on your system will be banned, correct? We frequently have occasion to send thousands of business-related messages to a single domain, and if they use some simple-minded smtp connection rate or traffic measurement, they would end up blocking us. Heads would soon roll for that sort of nonsense. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Sloan <joe@tmsusa.com> [07-30-07 13:10]:
So, any host that has a lot of messages to send to users on your system will be banned, correct?
We frequently have occasion to send thousands of business-related messages to a single domain, and if they use some simple-minded smtp connection rate or traffic measurement, they would end up blocking us.
Heads would soon roll for that sort of nonsense.
and certainly should were that the case, but the idea is to ban those sites that have repeated rejections and/or refusals in a short period of time. The purpose is to ban rogue sites that continually pound your system attempting access, to relay mail/spam and/or to deliver spam to you, not to stop or deter valid ligitimate connection attempts. Ligitimate sites will not spend this type of effort for access. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Patrick Shanahan wrote:
* Sloan <joe@tmsusa.com> [07-30-07 13:10]:
So, any host that has a lot of messages to send to users on your system will be banned, correct?
We frequently have occasion to send thousands of business-related messages to a single domain, and if they use some simple-minded smtp connection rate or traffic measurement, they would end up blocking us.
Heads would soon roll for that sort of nonsense.
and certainly should were that the case, but the idea is to ban those sites that have repeated rejections and/or refusals in a short period of time.
The purpose is to ban rogue sites that continually pound your system attempting access, to relay mail/spam and/or to deliver spam to you, not to stop or deter valid ligitimate connection attempts. Ligitimate sites will not spend this type of effort for access.
I'm curious about the mechanism by which fail2ban determines what is legitimate high volume mail, and what is spam... Unfortunately messages can bounce due to various causes on the receiving end, including users who have moved on but haven't let all their contacts know their new email address, or even hardware problems, network outages or configuration blunders. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Sloan <joe@tmsusa.com> [07-30-07 14:58]:
I'm curious about the mechanism by which fail2ban determines what is legitimate high volume mail, and what is spam... Unfortunately messages can bounce due to various causes on the receiving end, including users who have moved on but haven't let all their contacts know their new email address, or even hardware problems, network outages or configuration blunders.
a little quote trimming would be nice :^) from my logs: /var/log/mail: Jul 30 14:13:06 wahoo postfix/smtpd[488]: connect from edu194.internetdsl.tpnet.pl[83.14.202.194] Jul 30 14:13:18 wahoo postfix/smtpd[488]: NOQUEUE: reject: RCPT from edu194.internetdsl.tpnet.pl[83.14.202.194]: 554 5.7.1 Service unavailable; Client host [83.14.202.194] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?83.14.202.194; from=<sigbamboedyj@bamboe.nl> to=<paka@wahoo.no-ip.org> proto=ESMTP helo=<[83.14.202.194]> Jul 30 14:13:18 wahoo postfix/smtpd[488]: NOQUEUE: reject: RCPT from edu194.internetdsl.tpnet.pl[83.14.202.194]: 554 5.7.1 Service unavailable; Client host [83.14.202.194] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?83.14.202.194; from=<sigbamboedyj@bamboe.nl> to=<pat@wahoo.no-ip.org> proto=ESMTP helo=<[83.14.202.194]> Jul 30 14:13:27 wahoo postfix/smtpd[499]: connect from edu194.internetdsl.tpnet.pl[83.14.202.194] Jul 30 14:13:38 wahoo postfix/smtpd[488]: lost connection after DATA from edu194.internetdsl.tpnet.pl[83.14.202.194] Jul 30 14:13:38 wahoo postfix/smtpd[488]: disconnect from edu194.internetdsl.tpnet.pl[83.14.202.194] Jul 30 14:13:40 wahoo postfix/smtpd[499]: NOQUEUE: reject: RCPT from edu194.internetdsl.tpnet.pl[83.14.202.194]: 554 5.7.1 Service unavailable; Client host [83.14.202.194] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?83.14.202.194; from=<sigbangnaidyj@bangnai.com> to=<paka@wahoo.no-ip.org> proto=ESMTP helo=<[83.14.202.194]> Jul 30 14:13:40 wahoo postfix/smtpd[499]: NOQUEUE: reject: RCPT from edu194.internetdsl.tpnet.pl[83.14.202.194]: 554 5.7.1 Service unavailable; Client host [83.14.202.194] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?83.14.202.194; from=<sigbangnaidyj@bangnai.com> to=<pat@wahoo.no-ip.org> proto=ESMTP helo=<[83.14.202.194]> /var/log/fail2ban: 2007-07-30 14:13:40,725 fail2ban.actions: WARNING [postfix-iptables] Ban 83.14.202.194 2007-07-30 14:28:40,930 fail2ban.actions: WARNING [postfix-iptables] Unban 83.14.202.194 -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Patrick Shanahan wrote:
a little quote trimming would be nice :^)
from my logs:
/var/log/mail: Jul 30 14:13:06 wahoo postfix/smtpd[488]: connect from edu194.internetdsl.tpnet.pl[83.14.202.194] Jul 30 14:13:18 wahoo postfix/smtpd[488]: NOQUEUE: reject: RCPT from edu194.internetdsl.tpnet.pl[83.14.202.194]: 554 5.7.1 Service unavailable; Client host [83.14.202.194] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?83.14.202.194; from=<sigbamboedyj@bamboe.nl>
/var/log/fail2ban: 2007-07-30 14:13:40,725 fail2ban.actions: WARNING [postfix-iptables] Ban 83.14.202.194
Interesting - but with RBLs you sometimes have innocent senders tarred with the same brush as the spammers, so if it's problematic to ban based on the RBLs. Count on it, some law office in Brazil will send an urgent and business critical message, and be banned due to an unfortunate choice of ISP. Managers will be angry. In a number of environments we've removed RBLs as a front line sanity check because, like SPF, they sometimes block important and legitimate messages. In other words, we're decided to use SPF and RBLs as factors in spamassassin scoring, rather than a binary decision at the perimeter. The other sanity checks are already enough to block more than half the attempted messages from even getting to the spamassassin servers. For home use fail2ban is probably fine though - aunt myrtle won't complain if her message is delayed. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Sloan <joe@tmsusa.com> [07-30-07 15:27]:
Interesting - but with RBLs you sometimes have innocent senders tarred with the same brush as the spammers, so if it's problematic to ban based on the RBLs.
rbl blocked >1000 posts the 28th and >600 yesterday. I correspond with several people who have isp's listed and just add them to /etc/postfix/access and they have no problem with refusals :^)
Count on it, some law office in Brazil will send an urgent and business critical message, and be banned due to an unfortunate choice of ISP. Managers will be angry. In a number of environments we've removed RBLs as a front line sanity check because, like SPF, they sometimes block important and legitimate messages. In other words, we're decided to use SPF and RBLs as factors in spamassassin scoring, rather than a binary decision at the perimeter. The other sanity checks are already enough to block more than half the attempted messages from even getting to the spamassassin servers.
For home use fail2ban is probably fine though - aunt myrtle won't complain if her message is delayed.
guess you just need to use the abilities of postfix :^) -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 29 July 2007, Patrick Shanahan wrote:
* Richard Creighton <ricreig@gmail.com> [07-29-07 15:46]:
I don't think he wants to block off the public, just someone he has detected abusing.
exactly and I am presently using fail2ban to block:
[postfix-tcpwrapper]
enabled = true filter = postfix action = hostsdeny[file=/etc/hosts.deny] mail[name=Postfix, dest=postmaster@localhost] logpath = /var/log/mail bantime = 300
which places 554 rejection ip into /etc/hosts.deny, but the firewall action denying rogue ssh attempts is cleaner, requires less resources and sees the ip sooner.
is this correct: FW_SERVICES_ACCEPT_EXT="0/0,tcp,25,,hitcount=3,blockseconds=120
A better way to do this is with Postfix Anvil. Its already designed into postfix, so why re-invent the wheel? It does it in the proper way. -- _____________________________________ John Andersen
Richard Creighton wrote:
I don't think he wants to block off the public, just someone he has detected abusing. I have a friend that has a small newsletter she sends out to a growing list of people and recently she hit a limit from road-runner. She could receive mail just fine but when she hit the limit of the magic number of E-Mails, she couldn't connect to the SMTP server for 24 hours. I agree that counting packets like you do with SSHd is probably the wrong criteria, but detecting the IP of an incoming site that is attempting to post too many messages and then selectively turning off that IP at the firewall could be effective. I know the abuser could simply change IP numbers so the detector needs to watch at a higher level then notify the firewall about the new IP to block, but it could work....it does with RR...so, the measure of bad email senders could be any field in the SMTP header or even message content scanners like the one in many mail servers like Surgemail or reverse DNS checking or whatever is effective, coupled with turning off the current incoming IP. The server discards or rejects any bad messages it receives, but the firewall can prevent the messages from getting through in the first place once triggered.
I admin a mail server that deals with maybe 20 million messages a month, so I've had some experience here, and for my money, simple is safe. You try to get too fancy and you're going to piss off some important users when something goes haywire. What we've found effective is to put some basic sanity checks up front - greylisting, recipient verification, RBLs, smtp helo checks, tarpits for abusers etc. BTW policyd is an excellent companion to postfix as a means to implement smtp policies like greylisting etc.
Spammers are likely to go somewhere easier, where are so many Windoze machines available :)
Indeed, I've seen reports that about 80% of the common spam that we get is coming from swarms of zombie windoze peecees which have been commandeered for service in botnets. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Creighton wrote:
Just about every day, often several times a day, my logs include hours of log entries that look like this:
Jul 16 00:35:25 raid5 sshd[6966]: Invalid user admin from 83.18.244.42 Jul 16 00:35:30 raid5 sshd[6968]: Invalid user admin from 83.18.244.42 Jul 16 00:35:35 raid5 sshd[6972]: Invalid user admin from 83.18.244.42 Jul 16 00:35:40 raid5 sshd[6974]: Invalid user admin from 83.18.244.42 Jul 16 00:35:56 raid5 sshd[6981]: Invalid user test from 83.18.244.42 Jul 16 00:36:01 raid5 sshd[6983]: Invalid user test from 83.18.244.42 Jul 16 00:36:06 raid5 sshd[6985]: Invalid user webmaster from 83.18.244.42 Jul 16 00:36:11 raid5 sshd[6987]: Invalid user username from 83.18.244.42 Jul 16 00:36:16 raid5 sshd[6989]: Invalid user user from 83.18.244.42 Jul 16 00:36:26 raid5 sshd[6994]: Invalid user admin from 83.18.244.42 Jul 16 00:36:31 raid5 sshd[6996]: Invalid user test from 83.18.244.42 Jul 16 00:36:51 raid5 sshd[7017]: Invalid user danny from 83.18.244.42 Jul 16 00:36:56 raid5 sshd[7019]: Invalid user alex from 83.18.244.42 Jul 16 00:37:01 raid5 sshd[7022]: Invalid user brett from 83.18.244.42 Jul 16 00:37:06 raid5 sshd[7024]: Invalid user mike from 83.18.244.42 Jul 16 00:37:12 raid5 sshd[7027]: Invalid user alan from 83.18.244.42 Jul 16 00:37:18 raid5 sshd[7029]: Invalid user data from 83.18.244.42 Jul 16 00:37:22 raid5 sshd[7031]: Invalid user www-data from 83.18.244.42 Jul 16 00:37:28 raid5 sshd[7033]: Invalid user http from 83.18.244.42 Jul 16 00:37:33 raid5 sshd[7037]: Invalid user httpd from 83.18.244.42 Jul 16 00:37:38 raid5 sshd[7040]: Invalid user pop from 83.18.244.42
..... and so on, ad nausium. Obviously, someone is trying to break in to my system via SSH. So far as I can tell from examining my logs and my systems (usually at least 4 other systems on my LAN are under simultaneous attacks from the same source(s), the daemon is successsfully withstanding the assault and the system is not compromised.
My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space.
Thanks in advance, Richard
The first question is there any reason to have external ssh sessions. If external ssh are not required just block ssh at the external firewall. If there is a technical support reason for such access restrict external ssh access and login accounts to those accounts that require it (when they require it). If external ssh sessions are generally required consider setting up something like VPN and blocking non VPN access to ssh. The real problem starts when the attacker hits pay dirt, the entries I would worry about are the ones that are not in the log. The log sizes are a nuisance but with a bit of scripting and log management should be easy enough to keep under control. Also a knowledge of the account names the attack is being made upon could be an indicator of someone just fishing or something more dangerous. I looked briefly into this and tended to find that the purported addresses initiating the attacks tended not to repeat in the logs I examined. So address harvesting was not really an effective option. A difficulty here if external ssh is allowed, is distinguishing between an attack and someone genuinely getting a bit confused about their username. One may end up blocking legitimate addresses as a result. - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGmzQ+asN0sSnLmgIRAkRPAKCC3302p5UnV+NlhjYokcHDeD3/JACg9c/r VjEdndKZ5vZ0qHkOR2LPzXs= =Lzoy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 16 July 2007 10:02:54 G T Smith wrote:
Richard Creighton wrote:
Just about every day, often several times a day, my logs include hours of log entries that look like this:
Jul 16 00:35:25 raid5 sshd[6966]: Invalid user admin from 83.18.244.42 Jul 16 00:35:30 raid5 sshd[6968]: Invalid user admin from 83.18.244.42 Jul 16 00:35:35 raid5 sshd[6972]: Invalid user admin from 83.18.244.42 Jul 16 00:35:40 raid5 sshd[6974]: Invalid user admin from 83.18.244.42 Jul 16 00:35:56 raid5 sshd[6981]: Invalid user test from 83.18.244.42 Jul 16 00:36:01 raid5 sshd[6983]: Invalid user test from 83.18.244.42 Jul 16 00:36:06 raid5 sshd[6985]: Invalid user webmaster from 83.18.244.42 Jul 16 00:36:11 raid5 sshd[6987]: Invalid user username from 83.18.244.42 Jul 16 00:36:16 raid5 sshd[6989]: Invalid user user from 83.18.244.42 Jul 16 00:36:26 raid5 sshd[6994]: Invalid user admin from 83.18.244.42 Jul 16 00:36:31 raid5 sshd[6996]: Invalid user test from 83.18.244.42 Jul 16 00:36:51 raid5 sshd[7017]: Invalid user danny from 83.18.244.42 Jul 16 00:36:56 raid5 sshd[7019]: Invalid user alex from 83.18.244.42 Jul 16 00:37:01 raid5 sshd[7022]: Invalid user brett from 83.18.244.42 Jul 16 00:37:06 raid5 sshd[7024]: Invalid user mike from 83.18.244.42 Jul 16 00:37:12 raid5 sshd[7027]: Invalid user alan from 83.18.244.42 Jul 16 00:37:18 raid5 sshd[7029]: Invalid user data from 83.18.244.42 Jul 16 00:37:22 raid5 sshd[7031]: Invalid user www-data from 83.18.244.42 Jul 16 00:37:28 raid5 sshd[7033]: Invalid user http from 83.18.244.42 Jul 16 00:37:33 raid5 sshd[7037]: Invalid user httpd from 83.18.244.42 Jul 16 00:37:38 raid5 sshd[7040]: Invalid user pop from 83.18.244.42
..... and so on, ad nausium. Obviously, someone is trying to break in to my system via SSH. So far as I can tell from examining my logs and my systems (usually at least 4 other systems on my LAN are under simultaneous attacks from the same source(s), the daemon is successsfully withstanding the assault and the system is not compromised.
My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space.
Thanks in advance, Richard
After having a similar problem I was recommended DenyHosts, swear by it now, blocks all these lamers. http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts Cheers, Matthew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Matthew Stringer wrote:
After having a similar problem I was recommended DenyHosts, swear by it now, blocks all these lamers.
http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts
Cheers,
Matthew I'll vote for this too, although I would like to get something that uses iptables instead - taking the load off sshd. But denyhosts works pretty good. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-07-16 at 11:09 +0100, koffiejunkie wrote:
I'll vote for this too, although I would like to get something that uses iptables instead - taking the load off sshd.
SuSEfirewall2 does it that way - see Benji Weber answer. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGm2DmtTMYHG2NR9URAuGeAKCXKEyOmwPIhp1udRzb4j0eV/k3egCeM+/L nIzEsrjTL3IDEiTGKVsmg90= =ND7d -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 16 July 2007, G T Smith wrote:
The real problem starts when the attacker hits pay dirt, the entries I would worry about are the ones that are not in the log.
Paydirt? You mean like guessing BOTH the account name and password? The chances of this are vanishingly slim with reasonable password scheme. Limiting source IPs is also a pretty lame option in my opinion. The reason you have ssh is so you don't have to be somewhere special to perform routine maintenance. The best option is rate limiting connections. Shorewall does this easily but I suppose the suse firewall could do it as well. -- _____________________________________ John Andersen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Andersen wrote:
On Monday 16 July 2007, G T Smith wrote:
The real problem starts when the attacker hits pay dirt, the entries I would worry about are the ones that are not in the log.
Paydirt? You mean like guessing BOTH the account name and password? The chances of this are vanishingly slim with reasonable password scheme.
Exactly, a security breech by this route is either a case of serious bad luck or serious incompetence on a Linux system, and it is often difficult to distinguish between the two :-) This is normally more of a nuisance than anything else. However, it is probably worthwhile keeping a weather eye on the usernames being targeted. If an unusually accurate set of usernames are scanned, it is possibly an indicator that the attack is directed rather than random and possibly is (or will be) one of many different attack vectors. Unusual usernames could be indicators of another type of attack. - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGnIH5asN0sSnLmgIRAhDdAJ97DAvdbp1hXBkqAfPnZ/zo5Yz3NgCeIQGS GK/iuQ9krB9vGOqR/txBr+8= =BEl2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hello. In our network we have the user $HOMEs mounted via NFS. This has been working ok for many years (the servers have changed over time, of course). This year, when we upgraded our server from Suse 9.1 to 10.1 things got very slow, mostly the KDE login. (note: the hardware didn't change and the problem is solved if I boot with the old version.) I suspect something to do with locks, but I have been unable to confirm it. I wonder if someone else had the same or similar problem and what they did about it. My kernel is: Linux 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux The filesystems are ext3 and the disks are 4 SATA drives with RAID-1 /dev/md0 /home/xxx/disco1 ext3 rw,data=ordered,usrquota 0 0 /dev/md1 /home/xxx/disco2 ext3 rw,data=ordered,usrquota 0 0 Thanks in advance -- rps -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue July 17 2007 05:32, Rui Pedro Mendes Salgueiro wrote:
Hello.
Hi, Rui. I can't help you with your problem, but I know that your chances of getting help are bigger if you do not use the reply button to start a new message to the mailing-list. The way you did, your message gets buried under a lot of other messages about "dictionary attacks" and people will overlook it (for this and other hints, see here: http://en.opensuse.org/OpenSUSE_mailing_list_netiquette#Changing_the_subject... ). Good luck. -- Carlos FL Who is General Failure, and why is he reading my disk? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
2007/7/17, Carlos F Lange <carlos.lange@ualberta.ca>:
On Tue July 17 2007 05:32, Rui Pedro Mendes Salgueiro wrote:
Hello.
Hi, Rui. I can't help you with your problem, but I know that your chances of getting help are bigger if you do not use the reply button to start a new message to the mailing-list. The way you did, your message gets buried under a lot of other messages about "dictionary attacks" and people will overlook it (for this and other hints, see here: http://en.opensuse.org/OpenSUSE_mailing_list_netiquette#Changing_the_subject... ).
Good luck. -- Carlos FL
Who is General Failure, and why is he reading my disk? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Check the NFS protocol version used. Ciro -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Ciro Iriarte <cyruspy@gmail.com> [07-17-07 12:26]: [...]
Ciro
PLEASE, do *not* reply to *hi-jacked* threads. Replying to *hi-jacked* threads further deteriorates the quality of the archives and makes searching a specific topic a mess. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
2007/7/17, Patrick Shanahan <ptilopteri@gmail.com>:
* Ciro Iriarte <cyruspy@gmail.com> [07-17-07 12:26]: [...]
Ciro
PLEASE, do *not* reply to *hi-jacked* threads.
Replying to *hi-jacked* threads further deteriorates the quality of the archives and makes searching a specific topic a mess. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org
Sorry, i don't see it as part of another thread from GMail. Ciro -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-07-17 at 12:55 -0400, Ciro Iriarte wrote:
Sorry, i don't see it as part of another thread from GMail.
Then change your mail client. The gmail webmail is broken in this respect (and others). - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGnVY/tTMYHG2NR9URAoEGAJ0YmfQaQ8gf3v8MZHRzVYfDQxL+bQCdFbZd apZmMyNaBFncmlqM0iO4nh0= =yG6t -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sorry, i don't see it as part of another thread from GMail.
Then change your mail client. The gmail webmail is broken in this respect (and others).
Ummmm.. I use GMail and I see all the threads. They are called "Conversations" in GMail speak, but they are the same thing. The only thing that GMail does poorly is it doesn't handle mailing lists nicely... so you have to remember to "fix" the To: address whenever you reply to a message. C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
The Tuesday 2007-07-17 at 12:55 -0400, Ciro Iriarte wrote:
Sorry, i don't see it as part of another thread from GMail.
Then change your mail client. The gmail webmail is broken in this respect (and others).
- -- Cheers, Carlos E. R.
I won't, but thanks for the recommendation. Ciro -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Richard Creighton wrote:
Just about every day, often several times a day, my logs include hours of log entries that look like this:
Jul 16 00:35:25 raid5 sshd[6966]: Invalid user admin from 83.18.244.42 Jul 16 00:35:30 raid5 sshd[6968]: Invalid user admin from 83.18.244.42 Jul 16 00:35:35 raid5 sshd[6972]: Invalid user admin from 83.18.244.42 Jul 16 00:35:40 raid5 sshd[6974]: Invalid user admin from 83.18.244.42 Jul 16 00:35:56 raid5 sshd[6981]: Invalid user test from 83.18.244.42 Jul 16 00:36:01 raid5 sshd[6983]: Invalid user test from 83.18.244.42 Jul 16 00:36:06 raid5 sshd[6985]: Invalid user webmaster from 83.18.244.42 Jul 16 00:36:11 raid5 sshd[6987]: Invalid user username from 83.18.244.42 Jul 16 00:36:16 raid5 sshd[6989]: Invalid user user from 83.18.244.42 Jul 16 00:36:26 raid5 sshd[6994]: Invalid user admin from 83.18.244.42 Jul 16 00:36:31 raid5 sshd[6996]: Invalid user test from 83.18.244.42 Jul 16 00:36:51 raid5 sshd[7017]: Invalid user danny from 83.18.244.42 Jul 16 00:36:56 raid5 sshd[7019]: Invalid user alex from 83.18.244.42 Jul 16 00:37:01 raid5 sshd[7022]: Invalid user brett from 83.18.244.42 Jul 16 00:37:06 raid5 sshd[7024]: Invalid user mike from 83.18.244.42 Jul 16 00:37:12 raid5 sshd[7027]: Invalid user alan from 83.18.244.42 Jul 16 00:37:18 raid5 sshd[7029]: Invalid user data from 83.18.244.42 Jul 16 00:37:22 raid5 sshd[7031]: Invalid user www-data from 83.18.244.42 Jul 16 00:37:28 raid5 sshd[7033]: Invalid user http from 83.18.244.42 Jul 16 00:37:33 raid5 sshd[7037]: Invalid user httpd from 83.18.244.42 Jul 16 00:37:38 raid5 sshd[7040]: Invalid user pop from 83.18.244.42
..... and so on, ad nausium. Obviously, someone is trying to break in to my system via SSH. So far as I can tell from examining my logs and my systems (usually at least 4 other systems on my LAN are under simultaneous attacks from the same source(s), the daemon is successsfully withstanding the assault and the system is not compromised.
My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space.
It is possible to filter on IP address in your firewall. You can also deny addresses in various config files, such as hosts.deny etc. -- Use OpenOffice.org <http://www.openoffice.org> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Richard Creighton wrote:
Just about every day, often several times a day, my logs include hours of log entries that look like this:
Jul 16 00:35:25 raid5 sshd[6966]: Invalid user admin from 83.18.244.42
<snip>
My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space.
I prefer a more simple approach. Rather than adding more firewall rules, I set the sshd allowed_users parameter to the 2 accounts that actually have a reason to log in, and I also limit the IP addresses which will accept an ssh connection using tcp wrappers (hosts.allow, hosts.deny). Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
joe wrote:
Richard Creighton wrote:
Just about every day, often several times a day, my logs include hours of log entries that look like this:
Jul 16 00:35:25 raid5 sshd[6966]: Invalid user admin from 83.18.244.42
<snip>
My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space.
I prefer a more simple approach. Rather than adding more firewall rules, I set the sshd allowed_users parameter to the 2 accounts that actually have a reason to log in, and I also limit the IP addresses which will accept an ssh connection using tcp wrappers (hosts.allow, hosts.deny).
typo/thinko - I meant, limit the addresses *from* which it will accept an ssh connection using tcp wrappers. Also, as one poster mentioned, using keys instead of passwords is another handy ssh trick, along with reducing the max failed attempts and grace period for ssh logins. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 joe wrote:
joe wrote:
Richard Creighton wrote:
I prefer a more simple approach. Rather than adding more firewall rules, I set the sshd allowed_users parameter to the 2 accounts that actually have a reason to log in, and I also limit the IP addresses which will accept an ssh connection using tcp wrappers (hosts.allow, hosts.deny).
typo/thinko - I meant, limit the addresses *from* which it will accept an ssh connection using tcp wrappers. Also, as one poster mentioned, using keys instead of passwords is another handy ssh trick, along with reducing the max failed attempts and grace period for ssh logins.
Joe
A small point, for small setups the pam_access.so module is probably simpler to use than tcp wrappers. (but of course this depends on ones definition of simple :-) ). - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGm6jGasN0sSnLmgIRAlBNAJ4zzkdiKfhl1ebN6rTJYrcsqdElSwCeNoJl +Q8P2oajTRx6FwLykjtMcek= =aB/l -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Mandag 16 juli 2007 18:00 skrev joe:
Richard Creighton wrote:
Just about every day, often several times a day, my logs include hours of log entries that look like this:
Jul 16 00:35:25 raid5 sshd[6966]: Invalid user admin from 83.18.244.42
<snip>
My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space.
I prefer a more simple approach. Rather than adding more firewall rules, I set the sshd allowed_users parameter to the 2 accounts that actually have a reason to log in, and I also limit the IP addresses which will accept an ssh connection using tcp wrappers (hosts.allow, hosts.deny).
Joe
Hi Joe, quote: "sshd allowed_users parameter to the 2 accounts" in what file do you do that? Would that be an additional line in /etc/ssh/sshd_config, 'cause I can't seem to find an empty line like that in my system? -- ------------------------------------------------------------------------- Med venlig hilsen/Best regards Verner Kjærsgaard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Mon, 16 Jul 2007, by ricreig@gmail.com:
Just about every day, often several times a day, my logs include hours of log entries that look like this:
Jul 16 00:35:25 raid5 sshd[6966]: Invalid user admin from 83.18.244.42 Jul 16 00:35:30 raid5 sshd[6968]: Invalid user admin from 83.18.244.42 Jul 16 00:35:35 raid5 sshd[6972]: Invalid user admin from 83.18.244.42 [..] My question is what, if any firewall rule could I write that could detect such attacks and automatically shut down forwarding packets from the offending node or domain? That would give me an additional layer of defense as well as freeing up a significant amount of log file space.
Do you really need to have ssh open for the complete Internet? Maybe you can limit the amount of ranges that are allowed to connect to begin with? Also: using another port does help. Maybe not forever, but certainly for the bulk of the brainless scripts out there. For my self; I only need ssh access for me, so I have it listening only on IPv6, and another port of course, and firewalled all but a few hosts. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.20 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John, you have been a tremendous amount of help. I am posting my reply to the list as well as direct to you because your answer may be of benefit to the list members and the question I pose may also be of significance John Andersen wrote:
On Tuesday 17 July 2007, Richard Creighton wrote:
I am wondering if you know if that is even close to your recommendation....or should I try 60 instead of 120 or is that even an equivilent field. Or like me, is that so obtuse that you too do not know the answer and would be guessing as did I when I tried to set it up :) ??
If you look at the times Jul 17 00:38:27 raid5 sshd[625]: Invalid user staff from 83.18.244.42 Jul 17 00:38:32 raid5 sshd[628]: Invalid user sales from 83.18.244.42 Jul 17 00:38:37 raid5 sshd[630]: Invalid user recruit from 83.18.244.42 Jul 17 00:38:42 raid5 sshd[632]: Invalid user alias from 83.18.244.42 Jul 17 00:38:48 raid5 sshd[634]: Invalid user office from 83.18.244.42 Jul 17 00:38:53 raid5 sshd[636]: Invalid user samba from 83.18.244.42
You see that they are around 5 seconds beteeen each attempt.
Therefore your 3 in 120 should have started blocking after the 4th connection attempt.
But it didn't, that's why I think your firewall is not honoring this setting at all, which is what I mentioned in my first post.
It is possible that your version of the kernel does not have "recent match" support turned on.
This is a feature that not all kernels have. Explained here: http://snowman.net/projects/ipt_recent/
To see if this is in your kernel type this as root in a shell iptables -m recent --help
That should give a lot of help text which ends with " ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>"
If it says "Couldn't load match `recent' ..." then you don't have recent match installed.
This is what the last line says, once I found it in /usr/sbin as root: ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. http://snowman.net/projects/ipt_recent/ I also found this when I dumped the contents of my IPTABLES with sudo /usr/sbin/iptables -L > iptables.txt and extracted what I think pertains to the settings I *used* to have. For some reason (maybe I have to reboot ----nah, this is Linux but I must have to do something I forgot) the settings didn't take. I used to have settings of 5 and 300 instead of 3 and 120 but the numbers stood out. I don't know where the limit: avg 3/min burst setting comes in. LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ssh state NEW recent: CHECK seconds: 300 hit_count: 5 name: ssh side: source LOG level warning tcp-options ip-options prefix `SFW2-INext-DROPr ' DROP tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: UPDATE seconds: 300 hit_count: 5 TTL-Match name: ssh side: source
But in any event, I don't believe its being honored. What I'm wondering is if it *is* being honored as far as the hacker is concerned, ie, he is not getting past the 'DROP', but because of the LOG setting, I am still getting notice???? Does that seem plausible to you and if so, can you think of a way to test it?
Thanks again, Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 17 July 2007, Richard Creighton wrote:
But in any event, I don't believe its being honored.
Ok, its safe to say you have rate limit installed and available
What I'm wondering is if it *is* being honored as far as the hacker is concerned, ie, he is not getting past the 'DROP', but because of the LOG setting, I am still getting notice???? Does that seem plausible to you and if so, can you think of a way to test it?
You can test with any external ssh client (from the outside). But if the logging shows up prefixed with sshd as yours does: Jul 17 00:38:27 raid5 sshd Then you can be assured that the connection attempt DID get to the ssh daemon, and was NOT dropped. If it was dropped the sshd would never see these packets. I suspect you will have to restart iptables somehow, if not by reboot then by iptables commands. (Shorewall does this for me so I don't know the base level syntax). FWIW here is the pertinent part of the output from /usr/sbin/iptables -L > iptables.txt Chain %Limit (1 references) target prot opt source destination 0 -- anywhere anywhere recent: SET name: SSHA side: source %Limit% 0 -- anywhere anywhere recent: UPDATE seconds: 60 hit_count: 4 name: SSHA side: source ACCEPT 0 -- anywhere anywhere The only significant difference I see is my name: SSHA is unique, not any common name such as ssh. Your badssh should have worked. BTW, can you turn off html mail to the mailing list? It messes up the qouteing style and I am having a bit of a problem following the thread... I thought thuunderbird had this as a per-destination option, but I donno for sure. -- _____________________________________ John Andersen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
On Tuesday 17 July 2007, Richard Creighton wrote:
But if the logging shows up prefixed with sshd as yours does: Jul 17 00:38:27 raid5 sshd Then you can be assured that the connection attempt DID get to the ssh daemon, and was NOT dropped. If it was dropped the sshd would never see these packets.
I suspect you will have to restart iptables somehow, if not by reboot then by iptables commands. (Shorewall does this for me so I don't know the base level syntax).
I did and all hell broke loose....There were error messages during the system reboot that said that ....well, here is the pertinent line: Starting Firewall Initialization (phase 2 of 2) SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. SuSEfirewall2: Error: unknown parameter name=ssh in FW_SERVICES_ACCEPT_EXT -> 0/0,tcp,22,,hitcount=3,blockseconds=120,name=ssh <snip>
The only significant difference I see is my name: SSHA is unique, not any common name such as ssh. Your badssh should have worked.
Since then, I manually added the following to the IPTABLES bypassing SUSEFIREWALL2;
iptables -A FORWARD -p tcp -i eth0 --dport 22 -m recent --name badssh --set -j DROP iptables -A FORWARD -m recent --name badssh --update --hitcount 3 --seconds 60 -j DROP
Which gave an 'iptables -L' of;
Chain FORWARD (policy DROP) target prot opt source destination LOG 0 -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-FWD-ILL-ROUTING ' DROP tcp -- anywhere anywhere tcp dpt:ssh recent: SET name: badssh side: source DROP 0 -- anywhere anywhere recent: UPDATE seconds: 60 hit_count: 3 name: badssh side: source
which looks like it made i to the IPTABLES.... however, as I type this, my entire LAN is under attack, including this machine with a concerted sshd dictionary attack Jul 17 16:04:56 raid5 sshd[7401]: Invalid user admin from 61.145.119.180 Jul 17 16:05:02 raid5 sshd[7403]: Invalid user admin from 61.145.119.180 Jul 17 16:05:06 raid5 sshd[7405]: Invalid user admin from 61.145.119.180 Jul 17 16:05:08 raid5 sshd[7407]: Invalid user admin from 61.145.119.180 Jul 17 16:05:11 raid5 sshd[7409]: Invalid user admin from 61.145.119.180 Jul 17 16:05:14 raid5 sshd[7411]: Invalid user admin from 61.145.119.180 Jul 17 16:05:17 raid5 sshd[7413]: Invalid user admin from 61.145.119.180 Jul 17 16:05:20 raid5 sshd[7415]: Invalid user admin from 61.145.119.180 Jul 17 16:05:23 raid5 sshd[7418]: Invalid user admin from 61.145.119.180 Jul 17 16:05:26 raid5 sshd[7420]: Invalid user admin from 61.145.119.180 Jul 17 16:05:29 raid5 sshd[7422]: Invalid user admin from 61.145.119.180 Jul 17 16:05:31 raid5 sshd[7425]: Invalid user admin from 61.145.119.180 Jul 17 16:05:34 raid5 sshd[7428]: Invalid user admin from 61.145.119.180 Jul 17 16:05:37 raid5 sshd[7430]: Invalid user admin from 61.145.119.180 and going through zzzz. So, for some reason even though it would appear that IPTABLES is *supposed* to be dropping packets, I still don't have the magic incantation yet. Maybe I am putting it in the wrong place? Help!!!! Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Richard Creighton <ricreig@gmail.com> [07-17-07 16:09]:
Starting Firewall Initialization (phase 2 of 2) SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. SuSEfirewall2: Error: unknown parameter name=ssh in FW_SERVICES_ACCEPT_EXT -> 0/0,tcp,22,,hitcount=3,blockseconds=120,name=ssh
yes, the line is wrong :^( FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh" -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Patrick Shanahan wrote:
* Richard Creighton <ricreig@gmail.com> [07-17-07 16:09]:
Starting Firewall Initialization (phase 2 of 2) SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. SuSEfirewall2: Error: unknown parameter name=ssh in FW_SERVICES_ACCEPT_EXT -> 0/0,tcp,22,,hitcount=3,blockseconds=120,name=ssh
yes, the line is wrong :^(
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh"
I had that line in there originally and the error message stated that 'recentname' was wrong also so I changed it based upon 'man iptables', but apparently that also isn't right for susefirewall2 syntax. That said, I am going to plug that line in using cut and paste and reboot the machine and pray :) Thanks for your help.... Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Jul 17, 2007, at 1:34 PM, Richard Creighton wrote:
Patrick Shanahan wrote:
* Richard Creighton <ricreig@gmail.com> [07-17-07 16:09]:
Starting Firewall Initialization (phase 2 of 2) SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. SuSEfirewall2: Error: unknown parameter name=ssh in FW_SERVICES_ACCEPT_EXT -> 0/0,tcp, 22,,hitcount=3,blockseconds=120,name=ssh
yes, the line is wrong :^(
FW_SERVICES_ACCEPT_EXT="0/0,tcp, 22,,hitcount=3,blockseconds=120,recentname=ssh"
I had that line in there originally and the error message stated that 'recentname' was wrong also so I changed it based upon 'man iptables', but apparently that also isn't right for susefirewall2 syntax.
That said, I am going to plug that line in using cut and paste and reboot the machine and pray :) Thanks for your help....
Prayer is cool, but why a reboot? This isn't windoze, no need. Just tell the firewall to reload, takes a second. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Joe Sloan wrote:
On Jul 17, 2007, at 1:34 PM, Richard Creighton wrote:
Patrick Shanahan wrote:
Prayer is cool, but why a reboot? This isn't windoze, no need. Just tell the firewall to reload, takes a second.
Joe
Oh you don't know how much I know this isn't Windoze....Dammmm I even hate to *write* that word! However, I am desperate. I just posted a rather long update to the problem .... now Iran.... I've been doing this Linux stuff since it took 60+ floppy disks on a Slackware distro and my refrigerator cycling on and off would reset my old 286 :( BUT, *this* has me stumped and I was willing to try *anything* to see if it made a difference .... it didn't :( But thanks for your interest and if you have any ideas I haven't thought of, PLEASE give me a shout! Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Patrick Shanahan wrote:
* Richard Creighton <ricreig@gmail.com> [07-17-07 16:09]:
Starting Firewall Initialization (phase 2 of 2) SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. SuSEfirewall2: Error: unknown parameter name=ssh in FW_SERVICES_ACCEPT_EXT -> 0/0,tcp,22,,hitcount=3,blockseconds=120,name=ssh
yes, the line is wrong :^(
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=ssh"
Patrick, Thank you very much....Obviously despite everything, I must have fat-fingered something somewhere. After a cut and paste session PLUS a system reboot (something I very rarely do in Linux), I ended up with: LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ssh state NEW recent: CHECK seconds: 120 hit_count: 3 name: badssh side : source LOG level warning tcp-options ip-options prefix `SFW2-INext-DROPr ' DROP tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: UPDATE seconds: 120 hit_count: 3 TTL-Match name: badssh side: source LOG tcp -- anywhere anywhere tcp dpt:ssh state NEW limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-INe xt-ACC ' ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: badssh side: source ACCEPT tcp -- anywhere anywhere tcp dpt:ssh Which seems to be actually *in* the iptables -L. Now, if that SOB from China would just return and start his attack over again...he hit me from a to zzzzz a little while ago but only managed to fill my log on all my machines. If this works, my log files will lose a lot of weight I suspect. Oh...I inserted the word 'bad' in front of ssh to be better able to see it if it appeared in the iptables...which it did.... Richard PS Thanks to all that have endured this thread and to all that have contributed their ideas. BTW, I did install 'fail2ban' and it did execute but it never caught any attacks...so obviously I screwed up in configuration somehow even though I pointed the thing to the syslog-ng file as input, etc but it never reported either an error or an attack. I expect stupidity on my part is the biggest problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Richard Creighton <ricreig@gmail.com> wrote on 07/17/2007 02:02:51 PM:
Thanks to all that have endured this thread and to all that have contributed their ideas. BTW, I did install 'fail2ban' and it did execute but it never caught any attacks...so obviously I screwed up in configuration somehow even though I pointed the thing to the syslog-ng file as input, etc but it never reported either an error or an attack.
I've been watching this thread and have had fail2ban in the back of my mind. Is Fail2ban not necessary anymore with the "recent" addition to the kernel. Is this the "new" way of doing things? Should fail2ban be considered a workaround/hack/old technology? ~Dale -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 17 July 2007, Dale Schuster wrote:
Richard Creighton <ricreig@gmail.com> wrote on 07/17/2007 02:02:51 PM:
Thanks to all that have endured this thread and to all that have contributed their ideas. BTW, I did install 'fail2ban' and it did execute but it never caught any attacks...so obviously I screwed up in configuration somehow even though I pointed the thing to the syslog-ng file as input, etc but it never reported either an error or an attack.
I've been watching this thread and have had fail2ban in the back of my mind. Is Fail2ban not necessary anymore with the "recent" addition to the kernel. Is this the "new" way of doing things? Should fail2ban be considered a workaround/hack/old technology?
~Dale
I don't thing F2B is needed any more once you get a working "recent" installed. Doing this in iptables is so much more efficient than all the other hacks I've seen, and since installing "recent" I never get any of these dictionary attacks in my logs. (Well ok, I see three hits then the site is dropped and I never see them again. They soon just give up and never try my site again, its very effective). Tempest in a teapot if you ask me. Dictionary attacks are never going to be successful at my sites anyway due to password standards. On some sites we don't even allow password, and insist on public key. -- _____________________________________ John Andersen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Richard Creighton <ricreig@gmail.com> [07-17-07 17:05]:
Thank you very much....Obviously despite everything, I must have fat-fingered something somewhere. After a cut and paste session PLUS a system reboot (something I very rarely do in Linux), I ended up with: ...
A quick simple solution for one or two... addresses: enable SuSEfirewall-custom and add to /etc/sysconfig/scripts/SuSEfirewall-custom iptables -I INPUT 1 -s <address.as.dotted.quad> -j DROP I now use fail2ban to help keep my logs in tow :^) tail /var/log/fail2ban.log 2007-07-17 15:17:48,638 fail2ban.actions: WARNING [postfix-tcpwrapper] Unban 203.239.102.253 2007-07-17 16:16:59,593 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 88.233.59.219 2007-07-17 16:21:59,842 fail2ban.actions: WARNING [postfix-tcpwrapper] Unban 88.233.59.219 2007-07-17 17:16:40,567 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 74.212.33.47 2007-07-17 17:20:11,928 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 196.12.206.93 2007-07-17 17:21:41,075 fail2ban.actions: WARNING [postfix-tcpwrapper] Unban 74.212.33.47 2007-07-17 17:23:26,242 fail2ban.actions: WARNING [postfix-tcpwrapper] 196.12.206.93 already banned 2007-07-17 17:25:12,589 fail2ban.actions: WARNING [postfix-tcpwrapper] Unban 196.12.206.93 2007-07-17 17:26:43,823 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 75.73.74.254 2007-07-17 17:31:43,980 fail2ban.actions: WARNING [postfix-tcpwrapper] Unban 75.73.74.254 just added ssh and http filters and stopped denyhosts. Testing phase. I like the basics of fail2ban, and I sense that it will get better. It is packaged by Rauch Christian <info@........de> type = rpm-md name = suser-crauch baseurl = ftp://ftp.gwdg.de/pub/linux/misc/suser-crauch/.... -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 17 July 2007, Richard Creighton wrote:
John Andersen wrote:
On Tuesday 17 July 2007, Richard Creighton wrote:
But if the logging shows up prefixed with sshd as yours does: Jul 17 00:38:27 raid5 sshd Then you can be assured that the connection attempt DID get to the ssh daemon, and was NOT dropped. If it was dropped the sshd would never see these packets.
I suspect you will have to restart iptables somehow, if not by reboot then by iptables commands. (Shorewall does this for me so I don't know the base level syntax).
I did and all hell broke loose....There were error messages during the system reboot that said that ....well, here is the pertinent line:
Starting Firewall Initialization (phase 2 of 2) SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. SuSEfirewall2: Error: unknown parameter name=ssh in FW_SERVICES_ACCEPT_EXT -> 0/0,tcp,22,,hitcount=3,blockseconds=120,name=ssh
<snip>
The only significant difference I see is my name: SSHA is unique, not any common name such as ssh. Your badssh should have worked.
Since then, I manually added the following to the IPTABLES bypassing SUSEFIREWALL2;
iptables -A FORWARD -p tcp -i eth0 --dport 22 -m recent --name badssh --set -j DROP iptables -A FORWARD -m recent --name badssh --update --hitcount 3 --seconds 60 -j DROP
Which gave an 'iptables -L' of;
Chain FORWARD (policy DROP) target prot opt source destination LOG 0 -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-FWD-ILL-ROUTING ' DROP tcp -- anywhere anywhere tcp dpt:ssh recent: SET name: badssh side: source DROP 0 -- anywhere anywhere recent: UPDATE seconds: 60 hit_count: 3 name: badssh side: source
Does it make sense to put this in the forward chain? Thats way too late, they have already been seen by the daemon running in THIS machine. If you are going to drop these you want it in the input chain. In my setup (configured by shorewall) The INPUT chain references an eth0-In chain The ETH0-In chain references a chain named net2fw and Net2fw references a chain named %Limit which defines the rate limit. So effectively rate limit is done on the INPUT chain. -- _____________________________________ John Andersen
participants (19)
-
Benji Weber -
Carlos E. R. -
Carlos F Lange -
Ciro Iriarte -
Clayton -
Dale Schuster -
G T Smith -
James Knott -
joe -
Joe Sloan
-
John Andersen -
koffiejunkie -
Matthew Stringer -
Patrick Shanahan -
Richard Creighton -
Rui Pedro Mendes Salgueiro -
Sloan
-
Theo v. Werkhoven -
Verner Kjærsgaard