[opensuse-security] SuSefirewall - protect sshd
Hi, I'm a bit confused with Susefirewall. I have had a number of robot attacks against sshd so I set the following rule in SuSefirewall to limit the number of allowable sshd logins per 60 second period: FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh" which I assume will limit sshd logins to only 3 per 60 seconds however when I check my log I still get: Mar 10 01:32:54 sshd[19890]: Invalid user patrick from 222.156.220.25 Mar 10 01:32:56 sshd[19892]: Invalid user patrick from 222.156.220.25 Mar 10 01:33:09 sshd[19904]: Invalid user rolo from 222.156.220.25 Mar 10 01:33:11 sshd[19906]: Invalid user iceuser from 222.156.220.25 Mar 10 01:33:12 sshd[19908]: Invalid user horde from 222.156.220.25 Mar 10 01:33:14 sshd[19910]: Invalid user cyrus from 222.156.220.25 Mar 10 01:33:16 sshd[19912]: Invalid user www from 222.156.220.25 Did I forget something or do I need to set some other parameter as well? (yes I did restart the firewall and even re-booted the system for good measure!!) Thanks for any suggestions or help. Rgds. Otto Rodusek. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Monday 10 March 2008 11:37, Otto Rodusek (AP-SGP) wrote:
Hi,
I'm a bit confused with Susefirewall. I have had a number of robot attacks against sshd so I set the following rule in SuSefirewall to limit the number of allowable sshd logins per 60 second period:
Otto, I recommend looking at denyhosts for this function. Ron --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On 2008-03-10 10:53:08 -0500, Ron Joffe wrote:
I recommend looking at denyhosts for this function.
why having a script that parses a log file, which is written buffered, to do a job that iptables can do already. furthermore there is an even more trivial way to achieve the same: put your sshd on a port != 22. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Marcus Rueckert wrote:
On 2008-03-10 10:53:08 -0500, Ron Joffe wrote:
I recommend looking at denyhosts for this function.
why having a script that parses a log file, which is written buffered, to do a job that iptables can do already.
furthermore there is an even more trivial way to achieve the same: put your sshd on a port != 22.
darix
Hi Marcus, Thanks for the reply. I fully agree that iptables should do the job by itself and indeed I have tried to change the ssh port to something other than 22 - but robot crawlers are able to quickly determine this and then you get attacks on the other port. At this point, I am more interested in knowing why iptables doesn't behave the way it's supposed to though. From the Susefirewall script docs if you set as per below it is supposed to limit the number of sshd logins to only 3 per 60 seconds interval but from the log this obviously isn't so and I'm curious to know what needs to be done in order for iptables to behave as advertised. Again, thanks for the advice and help. Rgds. Otto. BTW: my os is OpenSuse 10.3 x86_64 (don't think this should make a diff tho)!! ## Type: string ## Default: 0/0,tcp,113 # # Services to allow. This is a more generic form of FW_SERVICES_{IP,UDP,TCP} # and more specific than FW_TRUSTED_NETS # # Format: space separated list of net,protocol[,dport][,sport] # Example: "0/0,tcp,22" # # Supported flags are # hitcount=NUMBER : ipt_recent --hitcount parameter # blockseconds=NUMBER : ipt_recent --seconds parameter # recentname=NAME : ipt_recent --name parameter # Example: # Allow max three ssh connects per minute from the same IP address: # "0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh" # # The special value _rpc_ is recognized as protocol and means that dport is # interpreted as rpc service name. See FW_SERVICES_EXT_RPC for # details. # FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
why having a script that parses a log file, which is written buffered, to do a job that iptables can do already.
As far as I am aware, iptables can not look logically at a set of data and determine that it is a break in attempt. For example, as Otto is trying to do, you can limit the number of attempts from a certain IP address range over a period of time. However, what happens if the attack script decides to attack each IP only once an hour. Then our iptables filter will not prevent a long term attack from succeeding.
furthermore there is an even more trivial way to achieve the same: put your sshd on a port != 22.
The scripts out there are getting more and more complex, and I have seen evidence of them looking in non-standard ports already. No method is foolproof. The problem that denyhosts now faces is that a distributed attack on a single IP from multiple IP isn't possible to detect with denyhosts. Ron --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Hi, --- Ron Joffe <rjoffe@yahoo.com> wrote: . . . I also have some x86_64 servers since SuSE 10.1. I always installed DenyHosts and the "spectrum" of attacks or, better said, the IP distribution is indeed showing something new. Attacks are "smarter" made from several machines and spaced in time. However I still think that DenyHosts or any script like that can easily surpass the IP distributed attacks because the attacker needs an overwhelming number of servers in order to be successful. And that is simply not viable from an attacker perspective. And of course this is only true if passwords are robust... Regards, Pedro
No method is foolproof. The problem that denyhosts now faces is that a distributed attack on a single IP from multiple IP isn't possible to detect with denyhosts.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Ron Joffe wrote:
On Monday 10 March 2008 11:37, Otto Rodusek (AP-SGP) wrote:
Hi,
I'm a bit confused with Susefirewall. I have had a number of robot attacks against sshd so I set the following rule in SuSefirewall to limit the number of allowable sshd logins per 60 second period:
Otto,
I recommend looking at denyhosts for this function.
Ron
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Hi Ron, Thanks for the reply. I'm very familiar with both denyhosts and fail2ban and and indeed use a variant of it. I am more interested in knowing why iptables doesn't behave the way it's supposed to though. From the Susefirewall script docs if you set as per below it is supposed to limit the number of sshd logins to only 3 per 60 seconds interval but from the log this obviously isn't so and I'm curious to know what needs to be done in order for iptables to behave as advertised. Again, thanks for the advice and help. Rgds. Otto. BTW: my os is OpenSuse 10.3 x86_64 (don't think this should make a diff tho)!! ## Type: string ## Default: 0/0,tcp,113 # # Services to allow. This is a more generic form of FW_SERVICES_{IP,UDP,TCP} # and more specific than FW_TRUSTED_NETS # # Format: space separated list of net,protocol[,dport][,sport] # Example: "0/0,tcp,22" # # Supported flags are # hitcount=NUMBER : ipt_recent --hitcount parameter # blockseconds=NUMBER : ipt_recent --seconds parameter # recentname=NAME : ipt_recent --name parameter # Example: # Allow max three ssh connects per minute from the same IP address: # "0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh" # # The special value _rpc_ is recognized as protocol and means that dport is # interpreted as rpc service name. See FW_SERVICES_EXT_RPC for # details. # FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Otto Rodusek (AP-SGP) wrote:
I'm a bit confused with Susefirewall. I have had a number of robot attacks against sshd so I set the following rule in SuSefirewall to limit the number of allowable sshd logins per 60 second period:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Provided that your network interface is in the external zone this should work fine. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Ludwig Nussel wrote:
Otto Rodusek (AP-SGP) wrote:
I'm a bit confused with Susefirewall. I have had a number of robot attacks against sshd so I set the following rule in SuSefirewall to limit the number of allowable sshd logins per 60 second period:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Provided that your network interface is in the external zone this should work fine.
cu Ludwig
Hi Ludwig, Yes my interface is indeed in the external zone. From my log files (as per below) I can see that it does not however work . I'm not sure what to try next to make it work!! Rgds. Otto. [hundreds of such lines] Mar 10 01:32:54 sshd[19890]: Invalid user patrick from 222.156.220.25 Mar 10 01:32:56 sshd[19892]: Invalid user patrick from 222.156.220.25 Mar 10 01:33:09 sshd[19904]: Invalid user rolo from 222.156.220.25 Mar 10 01:33:11 sshd[19906]: Invalid user iceuser from 222.156.220.25 Mar 10 01:33:12 sshd[19908]: Invalid user horde from 222.156.220.25 Mar 10 01:33:14 sshd[19910]: Invalid user cyrus from 222.156.220.25 Mar 10 01:33:16 sshd[19912]: Invalid user www from 222.156.220.25 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Otto Rodusek (AP-SGP) wrote:
Ludwig Nussel wrote:
Otto Rodusek (AP-SGP) wrote:
I'm a bit confused with Susefirewall. I have had a number of robot attacks against sshd so I set the following rule in SuSefirewall to limit the number of allowable sshd logins per 60 second period:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Provided that your network interface is in the external zone this should work fine.
cu Ludwig
Hi Ludwig,
Yes my interface is indeed in the external zone. From my log files (as per below) I can see that it does not however work . I'm not sure what to try next to make it work!! Rgds. Otto.
Check the output of SuSEfirewall2 status cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Ludwig Nussel wrote:
Otto Rodusek (AP-SGP) wrote:
Ludwig Nussel wrote:
Otto Rodusek (AP-SGP) wrote:
I'm a bit confused with Susefirewall. I have had a number of robot attacks against sshd so I set the following rule in SuSefirewall to limit the number of allowable sshd logins per 60 second period:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Provided that your network interface is in the external zone this should work fine.
cu Ludwig
Hi Ludwig,
Yes my interface is indeed in the external zone. From my log files (as per below) I can see that it does not however work . I'm not sure what to try next to make it work!! Rgds. Otto.
Check the output of
SuSEfirewall2 status
cu Ludwig
Hi Ludwig, I did as you requested and got LOTS of output (i've attached it here in gz format - hope I didn't break any netiquette) but I'm not sure what to look for!!?? Sorry, I'm not to expert in iptables!! Thanks and rgds. Otto.
Otto Rodusek (AP-SGP) wrote:
Ludwig Nussel wrote:
Otto Rodusek (AP-SGP) wrote:
Check the output of
SuSEfirewall2 status
I did as you requested and got LOTS of output (i've attached it here in gz format - hope I didn't break any netiquette) but I'm not sure what to look for!!?? Sorry, I'm not to expert in iptables!! Thanks and rgds. Otto.
There are lots and lots of drop rules for invididual IP addresses in the INPUT chain. Then a drop rule that unconditionally drops everything follows. So in theory you won't receive any traffic. Where do does that come from? Looks like some script running out of control. eth1 is your internal interface and eth0 the external one. Most traffic is on the internal one. You have FW_SERVICES_EXT_TCP=22 and FW_SERVICES_ACCEPT_EXT also set. Since rules for FW_SERVICES_EXT_TCP are installed first the latter rules never match. => Remove ports from FW_SERVICES_EXT_TCP that are also covered by FW_SERVICES_ACCEPT_EXT. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Ludwig Nussel wrote:
Otto Rodusek (AP-SGP) wrote:
Ludwig Nussel wrote:
Otto Rodusek (AP-SGP) wrote:
Check the output of
SuSEfirewall2 status
I did as you requested and got LOTS of output (i've attached it here in gz format - hope I didn't break any netiquette) but I'm not sure what to look for!!?? Sorry, I'm not to expert in iptables!! Thanks and rgds. Otto.
There are lots and lots of drop rules for invididual IP addresses in the INPUT chain. Then a drop rule that unconditionally drops everything follows. So in theory you won't receive any traffic. Where do does that come from? Looks like some script running out of control.
eth1 is your internal interface and eth0 the external one. Most traffic is on the internal one.
You have FW_SERVICES_EXT_TCP=22 and FW_SERVICES_ACCEPT_EXT also set. Since rules for FW_SERVICES_EXT_TCP are installed first the latter rules never match. => Remove ports from FW_SERVICES_EXT_TCP that are also covered by FW_SERVICES_ACCEPT_EXT.
cu Ludwig
Hi Ludwig, Thanks for your followup and explanation - I have removed port 22 on the line with FW_SERVICES_EXT_TCP=22 (which comes well before the next code and set up FW_SERVICES_ACCEPT_EXT as per the doc - so will monitor to see if I now get 3 sshd logins per 60 seconds from same ip. Yes, you are correct - eth0 is my external and eth1 is the internal. The numerous drops are a result of a perl script I run that (tails the log file) and sets an ip rule for "not allowed logins" after 3 chances - so that part is correct. I am in the process of changing that part of the perl code to instead write to hosts.deny to simplify the iptables. Again much thanks for your helpful hints. Best regards. Otto. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-03-10 at 17:21 +0100, Ludwig Nussel wrote:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Provided that your network interface is in the external zone this should work fine.
There is a problem. I tried to set that line on my system, and on firewall reload I get an error: nimrodel:~ # SuSEfirewall2 SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... SuSEfirewall2: Warning: no default firewall zone defined, assuming 'ext' SuSEfirewall2: Firewall customary rules loaded from /etc/sysconfig/scripts/SuSEfirewall2-custom SuSEfirewall2: batch committing... SuSEfirewall2: Firewall rules successfully set nimrodel:~ # jstar /etc/sysconfig/SuSEfirewall2 nimrodel:~ # SuSEfirewall2 SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... SuSEfirewall2: Warning: no default firewall zone defined, assuming 'ext' SuSEfirewall2: Firewall customary rules loaded from /etc/sysconfig/scripts/SuSEfirewall2-custom SuSEfirewall2: batch committing... ip6tables-batch v1.3.8: Couldn't load match `recent':/usr/lib/iptables/libip6t_recent.so: cannot open shared object file: No such file or directory Try `ip6tables-batch -h' or 'ip6tables-batch --help' for more information. SuSEfirewall2: Error: ip6tables-batch failed, re-running using ip6tables ip6tables v1.3.8: Couldn't load match `recent':/usr/lib/iptables/libip6t_recent.so: cannot open shared object file: No such file or directory Try `ip6tables -h' or 'ip6tables --help' for more information. ip6tables v1.3.8: Couldn't load match `recent':/usr/lib/iptables/libip6t_recent.so: cannot open shared object file: No such file or directory Try `ip6tables -h' or 'ip6tables --help' for more information. SuSEfirewall2: Firewall rules successfully set nimrodel:~ # locate libip6t_recent nimrodel:~ # uname -a Linux nimrodel 2.6.22.17-0.1-default #1 SMP 2008/02/10 20:01:04 UTC i686 i686 i386 GNU/Linux If "libip6t_recent.so" is missing from the kernel, it won't work, no? Or is that only for ip version 6? Anyway, running "SuSEfirewall2 status" here shows: 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: UPDATE seconds: 60 hit_count: 3 TTL-Match name: ssh side: source 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: ssh side: source 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 His output is not the same as mine: 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:22 state NEW recent: CHECK seconds: 60 hit_count: 3 name: ssh side: source LOG flags 6 level 4 prefix `SFW2-INext-DROPr ' 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: UPDATE seconds: 60 hit_count: 3 TTL-Match name: ssh side: source 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-INext-ACC ' 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: ssh side: source 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 Whatever it is, it doesn't work. I tried it login from another computer on my network (external interface), and I see the connections without the firewall clossing it. Mar 10 23:39:17 nimrodel sshd[26164]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:20 nimrodel sshd[26164]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:20 nimrodel sshd[26164]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:26 nimrodel sshd[26169]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:29 nimrodel syslog-ng[3792]: last message repeated 2 times Mar 10 23:39:29 nimrodel sshd[26174]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:33 nimrodel syslog-ng[3792]: last message repeated 2 times Mar 10 23:39:33 nimrodel sshd[26179]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:36 nimrodel syslog-ng[3792]: last message repeated 2 times Mar 10 23:39:36 nimrodel sshd[26184]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:39 nimrodel syslog-ng[3792]: last message repeated 2 times Mar 10 23:39:39 nimrodel sshd[26189]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:42 nimrodel syslog-ng[3792]: last message repeated 2 times Mar 10 23:39:42 nimrodel sshd[26194]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:45 nimrodel syslog-ng[3792]: last message repeated 2 times Mar 10 23:39:45 nimrodel sshd[26199]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:49 nimrodel syslog-ng[3792]: last message repeated 2 times Mar 10 23:39:49 nimrodel sshd[26204]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:39:52 nimrodel syslog-ng[3792]: last message repeated 2 times Mar 10 23:39:52 nimrodel sshd[26209]: error: PAM: User not known to the underlying authentication module for illegal user pepon from telperion.valinor Mar 10 23:40:18 nimrodel syslog-ng[3792]: last message repeated 2 times All in the same minute, and the firewall doesn't act. Looking at the output of iptables I see: nimrodel:~ # iptables --list --verbose | grep "recent\|\:22" 13 780 ACCEPT tcp -- any any telperion.valinor anywhere state NEW,RELATED,ESTABLISHED tcp dpt:22 0 0 ACCEPT tcp -- any any dyna1.valinor anywhere state NEW,RELATED,ESTABLISHED tcp dpt:22 0 0 DROP tcp -- any any anywhere anywhere tcp dpt:22 state NEW recent: UPDATE seconds: 60 hit_count: 3 TTL-Match name: ssh side: source 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:22 state NEW recent: SET name: ssh side: source 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:22 nimrodel:~ # - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH1bvctTMYHG2NR9URAi1FAJ4k2QYEIZA0fyQwXWqgECqyeTz+5ACdFmma ryzkfq8btbB4YnTNhLmgZOA= =hD/s -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Mon, 10 Mar 2008, Carlos E. R. wrote:
The Monday 2008-03-10 at 17:21 +0100, Ludwig Nussel wrote:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Provided that your network interface is in the external zone this should work fine.
I never could get the above to work properly. That is why I went to the rules in /etc/sysconfig/scripts/SuSEfirewall2-custom. They never failed me. Have you tried them? -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-03-10 at 20:23 -0600, Boyd Lynn Gerber wrote:
On Mon, 10 Mar 2008, Carlos E. R. wrote:
The Monday 2008-03-10 at 17:21 +0100, Ludwig Nussel wrote:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Provided that your network interface is in the external zone this should work fine.
I never could get the above to work properly. That is why I went to the rules in /etc/sysconfig/scripts/SuSEfirewall2-custom. They never failed me. Have you tried them?
That's what I used previously. But since installing 10.3 and seeing that cute syntax for FW_SERVICES_ACCEPT_EXT, I used that instead. So much more easy! So, yes, probably using the rule in ...custom still works fine. But the current problem is why that above "token" doesn't work as expected. Did it work and is now broken after some update? Did it never work? Are we using it wrong? If so, the doc is also wrong, I simply copypasted... Or perhaps it also does not work in ...custom (I haven't checked and I'm off to sleep now). Then iptables is broken and must be repaired. Mmmm...? Maybe the trick is to define "FW_SERVICES_ACCEPT_EXT" and undefine any other "accept" rule. That is not documented if so! - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH1fFHtTMYHG2NR9URAh4HAKCJYOpjHDgRG5KzprHcGCvOoln/ggCfYpdp WrNO48dXKuj/s2rbgZL3pz0= =IWN9 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Tue, 11 Mar 2008, Carlos E. R. wrote:
The Monday 2008-03-10 at 20:23 -0600, Boyd Lynn Gerber wrote:
On Mon, 10 Mar 2008, Carlos E. R. wrote:
The Monday 2008-03-10 at 17:21 +0100, Ludwig Nussel wrote:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Provided that your network interface is in the external zone this should work fine.
I never could get the above to work properly. That is why I went to the rules in /etc/sysconfig/scripts/SuSEfirewall2-custom. They never failed me. Have you tried them?
That's what I used previously. But since installing 10.3 and seeing that cute syntax for FW_SERVICES_ACCEPT_EXT, I used that instead. So much more easy!
But it never worked for me in any 10.3 version I tried. I did not bug report it as the custom worked. I also have a ftp rule as well. To avoid ftp attacks.
Or perhaps it also does not work in ...custom (I haven't checked and I'm off to sleep now). Then iptables is broken and must be repaired.
Same here, I am going to bed as well.
Maybe the trick is to define "FW_SERVICES_ACCEPT_EXT" and undefine any other "accept" rule. That is not documented if so!
I do not know. -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Carlos E. R. wrote:
Maybe the trick is to define "FW_SERVICES_ACCEPT_EXT" and undefine any other "accept" rule. That is not documented if so!
FW_SERVICES_EXT_TCP, FW_SERVICES_EXT_UDP etc are processed first. So if those install rules that accept packets that are also matched by FW_SERVICES_ACCEPT_EXT the latter rules will never be hit. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2008-03-11 at 08:52 +0100, Ludwig Nussel wrote:
Carlos E. R. wrote:
Maybe the trick is to define "FW_SERVICES_ACCEPT_EXT" and undefine any other "accept" rule. That is not documented if so!
FW_SERVICES_EXT_TCP, FW_SERVICES_EXT_UDP etc are processed first. So if those install rules that accept packets that are also matched by FW_SERVICES_ACCEPT_EXT the latter rules will never be hit.
I use FW_TRUSTED_NETS. Like this: FW_TRUSTED_NETS=" .... 192.168.1.11,tcp,ssh \ 192.168.1.33,tcp,ssh \ .... etc I think that you should document this in the comments of FW_SERVICES_ACCEPT_EXT in the /etc/sysconfig/SuSEfirewall2 file. There is no way we could know that, not being iptables experts. Specially as this is not the behaviour we got from using the custom rules file, which this new token replaces. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH1okktTMYHG2NR9URAv7vAJ4xiF0KINMTFwyB5IPSXfds6EAnwwCfVMwy BqKFEA95S9/s0xetQO7hHt0= =i9N4 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
I always add this to SuSEfirewall2-custom iptables -A INPUT -p tcp --syn --dport 22 -i eth0 -m recent --name sshattack --set iptables -A INPUT -m recent --name sshattack --rcheck --seconds 60 --hitcount 5 -j LOG --log-prefix 'SSH attack: ' iptables -A INPUT -m recent --name sshattack --rcheck --seconds 60 --hitcount 5 -j DROP iptables -A INPUT -p tcp --syn --dport 20:21 -i eth0 -m recent --name ftpattack --set -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Boyd Lynn Gerber wrote:
I always add this to SuSEfirewall2-custom
iptables -A INPUT -p tcp --syn --dport 22 -i eth0 -m recent --name sshattack --set iptables -A INPUT -m recent --name sshattack --rcheck --seconds 60 --hitcount 5 -j LOG --log-prefix 'SSH attack: ' iptables -A INPUT -m recent --name sshattack --rcheck --seconds 60 --hitcount 5 -j DROP iptables -A INPUT -p tcp --syn --dport 20:21 -i eth0 -m recent --name ftpattack --set
-- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Hi Boyd, Thanks for the tip. I'll try it and see if that works out. Rgds. Otto. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
participants (7)
-
Boyd Lynn Gerber -
Carlos E. R. -
Ludwig Nussel -
Marcus Rueckert -
Otto Rodusek (AP-SGP) -
pedrocsort-e＠yahoo.com -
Ron Joffe