Benji Weber wrote:

On 16/07/07, Richard Creighton 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

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

Patrick Shanahan wrote:

* Benji Weber [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

Patrick Shanahan wrote:

* Benji Weber [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

* Richard Creighton [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

* Sloan [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

* Sloan [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= to= 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= to= 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= to= 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= to= 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

* Sloan [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

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

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

-----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

-----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

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

* Ciro Iriarte [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

-----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

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

-----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

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

* Richard Creighton [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

On Jul 17, 2007, at 1:34 PM, Richard Creighton wrote:

Patrick Shanahan wrote:

...

* Richard Creighton [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

Patrick Shanahan wrote:

* Richard Creighton [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

On Tuesday 17 July 2007, Dale Schuster wrote:

Richard Creighton 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

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