Hello Mailinglist, in my logcheck I saw attacks like: Jan 16 06:44:22 micky sshd[21840]: Failed password for proxy from 38.97.212.172 port 52993 ssh2 Jan 16 06:58:50 micky sshd[5529]: Failed password for irc from 38.97.212.172 port 49597 ssh2 Jan 16 06:59:00 micky sshd[5541]: Failed password for nobody from 38.97.212.172 port 51432 ssh2 Jan 16 07:22:27 micky sshd[7240]: Failed password for daemon from 38.97.212.172 port 45159 ssh2 Jan 16 07:22:31 micky sshd[7244]: Failed password for games from 38.97.212.172 port 45834 ssh2 Jan 16 07:23:06 micky sshd[7276]: Failed password for sync from 38.97.212.172 port 51895 ssh2 Jan 16 07:38:30 micky sshd[8095]: Failed password for administrator from 38.97.212.172 port 36917 ssh2 Jan 16 07:38:54 micky sshd[8115]: Failed password for mail from 38.97.212.172 port 40891 ssh2 Jan 16 07:54:51 micky sshd[8941]: Failed password for sshd from 38.97.212.172 port 53351 ssh2 Jan 16 08:10:09 micky sshd[11391]: Failed password for root from 38.97.212.172 port 60942 ssh2 Jan 16 08:10:14 micky sshd[11395]: Failed password for root from 38.97.212.172 port 33514 ssh2 Therefore I want to protect my firewall with a Information of the Internet: WAN=ppp+ eth1 IPTABLES_BIN=/usr/sbin/iptables # diese beiden Variablen sind anzupassen for Interf in $WAN; do $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ -m recent --set --name SSH $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ -m recent --rcheck --seconds 60 --hitcount 4 --rttl --name SSH \ -j REJECT --reject-with tcp-reset $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ -j ACCEPT done How can I translate this in shorewall? Thank you! tony ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. p.sf.net/sfu/sf-spreadtheword
On Sat, Jan 17, 2009 at 09:06:30AM +0100, Gerhard Engler wrote:> > for Interf in $WAN; do > $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ > -m recent --set --name SSH > $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ > -m recent --rcheck --seconds 60 --hitcount 4 --rttl --name SSH \ > -j REJECT --reject-with tcp-reset > $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ > -j ACCEPT > done > > > How can I translate this in shorewall? >SSH/ACCEPT net $FW - - - - 4/min:4 Regards, -Roberto -- Roberto C. Sánchez people.connexer.com/~roberto connexer.com ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. p.sf.net/sfu/sf-spreadtheword
Roberto C. Sánchez wrote:> On Sat, Jan 17, 2009 at 09:06:30AM +0100, Gerhard Engler wrote: >> for Interf in $WAN; do >> $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ >> -m recent --set --name SSH >> $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ >> -m recent --rcheck --seconds 60 --hitcount 4 --rttl --name SSH \ >> -j REJECT --reject-with tcp-reset >> $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ >> -j ACCEPT >> done >> >> >> How can I translate this in shorewall? >> > SSH/ACCEPT net $FW - - - - 4/min:4That approach has the disadvantage that legitimate users are blocked out during an attack. The Limit builtin action (shorewall.net/PortKnocking.html#Limit) does what the OP is asking. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. p.sf.net/sfu/sf-spreadtheword
Shorewall Guy wrote:> Roberto C. Sánchez wrote: >> On Sat, Jan 17, 2009 at 09:06:30AM +0100, Gerhard Engler wrote: >>> for Interf in $WAN; do >>> $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ >>> -m recent --set --name SSH >>> $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ >>> -m recent --rcheck --seconds 60 --hitcount 4 --rttl --name SSH \ >>> -j REJECT --reject-with tcp-reset >>> $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \ >>> -j ACCEPT >>> done >>> >>> >>> How can I translate this in shorewall? >>> >> SSH/ACCEPT net $FW - - - - 4/min:4 > > That approach has the disadvantage that legitimate users are blocked out > during an attack. The Limit builtin action > (shorewall.net/PortKnocking.html#Limit) does what the OP is > asking.An even better solution (in MY opinion) is to install fail2ban. It watches the log files and bans the IP addresses that makes repeated failed login attempts. All parameters can be configured, such as number of attempts, ban time etc. BR /Martin ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. p.sf.net/sfu/sf-spreadtheword
On Sat, Jan 17, 2009 at 05:51:42PM +0100, Martin Leben wrote:> > An even better solution (in MY opinion) is to install fail2ban. It watches the > log files and bans the IP addresses that makes repeated failed login attempts. > All parameters can be configured, such as number of attempts, ban time etc. >Simply do this: - restrict login to key-based authentication - make use of AllowUsers/AllowGroups in sshd_config It makes things like fail2ban (and other port knocking schemes) basically unnecessary. Regards, -Roberto -- Roberto C. Sánchez people.connexer.com/~roberto connexer.com ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. p.sf.net/sfu/sf-spreadtheword
Roberto C. Sánchez wrote:> On Sat, Jan 17, 2009 at 05:51:42PM +0100, Martin Leben wrote: >> An even better solution (in MY opinion) is to install fail2ban. It watches the >> log files and bans the IP addresses that makes repeated failed login attempts. >> All parameters can be configured, such as number of attempts, ban time etc. >> > > Simply do this: > > - restrict login to key-based authentication > - make use of AllowUsers/AllowGroups in sshd_configCouldn''t agree more.> It makes things like fail2ban (and other port knocking schemes) > basically unnecessary.I agree. But the upside with having fail2ban is that the log files are cleaner. Much of the noise is gone. BR /Martin ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. p.sf.net/sfu/sf-spreadtheword
>>> ... $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 ... >>> ... How can I translate this in shorewall? ... >> ... That approach has the disadvantage that ... > ...An even better solution (in MY opinion) ...I''ll add my two cents to this: I''ve had excellent results simply by restricting the outside/source IP address to be in the ranges of the local ISPs. Everybody else from everywhere else in the country/continent/world that tries an SSH attack just gets the default DROP policy. In three years I haven''t had a single SSH attack (note I didn''t say "successful attack" - I said "_no_ attack". (This is certainly not adequate security by itself - it''s still susceptible to "zombies" ...if they can find you. But as just one of several parallel methods it significantly reduces the pressure. Some of the other things I do are: configure the daemon to not allow ''root'' no matter what [remote users can always `su` when necessary]; configure the daemon to only accept public/private keys but not passwords; change the port number to an obscure one far away, etc.) thanks! -Chuck Kollars ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. p.sf.net/sfu/sf-spreadtheword
On Sat, 2009-01-17 at 14:46 -0500, Roberto C. Sánchez wrote:> Simply do this: > > - restrict login to key-based authentication > - make use of AllowUsers/AllowGroups in sshd_config > > It makes things like fail2ban (and other port knocking schemes) > basically unnecessary.Uh huh... Tried that... Key based and average Windows user hosting websites brings lots of headaches trying to make that work.. I felt good getting them to move from ftp to ssh :P -- Homer Parker <hparker@homershut.net> Homer's Hut ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. p.sf.net/sfu/sf-spreadtheword _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net lists.sourceforge.net/lists/listinfo/shorewall-users