Menu
▾
▴
devil-linux-discuss
|
From: Vesselin K. <vk...@ex...> - 2007-03-04 11:39:41
|
Sorry to bother you again with this but libipt_recent.so is not there despite of the announced "addition of missing iptables modules". The problem was introduced in 1.2.12. To reproduce it execute: #/sbin/modprobe ipt_recent #iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH (the last command is just to illustrate the problem, it is not part of the normal firewall script) The error message is: iptables v1.3.7: Couldn't load match `recent':/usr/lib/iptables/libipt_recent.so: cannot open shared object file: No such file or directory Note that the actual kernel module ipt_recent is there: /lib/modules/2.4.34-grsec/kernel/net/ipv4/netfilter/ipt_recent.o The missing file seems to be a library that is needed by this module. Regards Vesselin |
|
From: Kari M. <kar...@tr...> - 2007-03-04 14:08:16
|
Vesselin Kostadinov wrote: > Sorry to bother you again with this but libipt_recent.so is not there despite > of the announced "addition of missing iptables modules". The problem was > introduced in 1.2.12. > > To reproduce it execute: > > #/sbin/modprobe ipt_recent > #iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH > > (the last command is just to illustrate the problem, it is not part of the > normal firewall script) I'm not commenting on the problem here, but a possible enhancement for the default firewall script of DL. See below: # Rate limit ssh connection attempts to 3 per 5 minutes per IP. iptables -A INPUT -p tcp --dport 22 -i eth0 -m state \ --state NEW -m recent --set iptables -A INPUT -p tcp --dport 22 -i eth0 -m state \ --state NEW -m recent --update --seconds 300 --hitcount 3 -j DROP This one does not create an additional queue like most other solutions for this common problem. I've found these 2 lines at the end of firewall script to be rather effective, yet problemless. No more brute-force-attack-trash in ssh log files. You might want to increase 300 seconds to 1800 for 30 minutes. ..and yes, the 2 lines above require a working ipt_recent. > The error message is: > > iptables v1.3.7: Couldn't load match > `recent':/usr/lib/iptables/libipt_recent.so: cannot open shared object file: > No such file or directory > > Note that the actual kernel module ipt_recent is there: > > /lib/modules/2.4.34-grsec/kernel/net/ipv4/netfilter/ipt_recent.o > > The missing file seems to be a library that is needed by this module. > > > Regards > > Vesselin |
|
From: Bruce S. <bw...@ar...> - 2007-03-04 16:54:26
|
> I'm not commenting on the problem here, but a possible enhancement for > the default firewall script of DL. See below: > > # Rate limit ssh connection attempts to 3 per 5 minutes per IP. > iptables -A INPUT -p tcp --dport 22 -i eth0 -m state \ > --state NEW -m recent --set > iptables -A INPUT -p tcp --dport 22 -i eth0 -m state \ > --state NEW -m recent --update --seconds 300 --hitcount 3 -j DROP > > This one does not create an additional queue like most other solutions > for this common problem. I've found these 2 lines at the end of > firewall script to be rather effective, yet problemless. > > No more brute-force-attack-trash in ssh log files. You might want to > increase 300 seconds to 1800 for 30 minutes. I've done similar things in some of my firewall scripts to combat the brute-force ssh attacks. The main problem occurs if you do a lot of scp's. Each scp initiates a new ssh connection, and you end up locking yourself out for the time period. The best way I've found to harden ssh against the brute-force attacks is to have ssh listen on a high/non-standard port number, and do not allow password authentication (ssh keys only). I've never had a brute force attacker find one of my non-standard ssh ports, and even if they did, they could never login because they are trying passwords (which I don't allow). A better solution (IMO) would be a modification to openssh so it shuts down an IP for a [configurable] period of time, after a [configurable] number of bad authentication attempts. I even suggested that to one of the openssh developers I once had a small email thread with. - BS |
|
From: Heiko Z. <he...@zu...> - 2007-03-04 18:15:46
|
OOPS sorry for that (small typo, big effect). I'm going to compile a new version and upload it into the testing directory on the ftp server tomorrow. Heiko On Sun, March 4, 2007 05:39, Vesselin Kostadinov wrote: > Sorry to bother you again with this but libipt_recent.so is not there > despite of the announced "addition of missing iptables modules". The > problem was introduced in 1.2.12. > > To reproduce it execute: > > > #/sbin/modprobe ipt_recent > #iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH > > > (the last command is just to illustrate the problem, it is not part of > the normal firewall script) > > The error message is: > > > iptables v1.3.7: Couldn't load match > `recent':/usr/lib/iptables/libipt_recent.so: cannot open shared object > file: > No such file or directory > > > Note that the actual kernel module ipt_recent is there: > > > /lib/modules/2.4.34-grsec/kernel/net/ipv4/netfilter/ipt_recent.o > > > The missing file seems to be a library that is needed by this module. > > > > Regards > > > Vesselin > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Devil-linux-discuss mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss > > -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Kari M. <kar...@tr...> - 2007-03-04 18:46:46
|
Bruce Smith wrote: >> I'm not commenting on the problem here, but a possible enhancement for >> the default firewall script of DL. See below: >> >> # Rate limit ssh connection attempts to 3 per 5 minutes per IP. >> iptables -A INPUT -p tcp --dport 22 -i eth0 -m state \ >> --state NEW -m recent --set >> iptables -A INPUT -p tcp --dport 22 -i eth0 -m state \ >> --state NEW -m recent --update --seconds 300 --hitcount 3 -j DROP >> >> This one does not create an additional queue like most other solutions >> for this common problem. I've found these 2 lines at the end of >> firewall script to be rather effective, yet problemless. >> >> No more brute-force-attack-trash in ssh log files. You might want to >> increase 300 seconds to 1800 for 30 minutes. > > I've done similar things in some of my firewall scripts to combat the > brute-force ssh attacks. > > The main problem occurs if you do a lot of scp's. Each scp initiates a > new ssh connection, and you end up locking yourself out for the time > period. Mmm.. So true. I haven't seen it happen, but that is a limitation. Architecture change would limit damages here: only push a semaphore to the remote servers containing a timestamp when they will begin a pull of files from a central sharepoint. It is more complicated, but the world is :-) On sharepoint you obviously don't have those two iptables lines in fw script. > The best way I've found to harden ssh against the brute-force attacks is > to have ssh listen on a high/non-standard port number, and do not allow > password authentication (ssh keys only). Agree. Nowadays I default to ssh-keys-only setup. > I've never had a brute force attacker find one of my non-standard ssh > ports, and even if they did, they could never login because they are > trying passwords (which I don't allow). > > A better solution (IMO) would be a modification to openssh so it shuts > down an IP for a [configurable] period of time, after a [configurable] > number of bad authentication attempts. I even suggested that to one of > the openssh developers I once had a small email thread with. You are not talking approximately about this: denyhosts.sourceforge.net I considered it, but I don't like any extra daemons lurking there (watching ssh log for bad login attempts). It can also act as an wrapper, so it will control openssh daemon. It restarts it if it has to block an IP, or something. iptables, even with the scp problem you discussed above, is independent, protocol neutral, wrapper/daemon-free solution. I like it that way, and I do understand it is a matter of taste. > - BS |
|
From: Bruce S. <bw...@ar...> - 2007-03-05 01:13:32
|
> > A better solution (IMO) would be a modification to openssh so it shuts > > down an IP for a [configurable] period of time, after a [configurable] > > number of bad authentication attempts. I even suggested that to one of > > the openssh developers I once had a small email thread with. > > You are not talking approximately about this: denyhosts.sourceforge.net > > I considered it, but I don't like any extra daemons lurking there > (watching ssh log for bad login attempts). > > It can also act as an wrapper, so it will control openssh daemon. It > restarts it if it has to block an IP, or something. > > iptables, even with the scp problem you discussed above, is independent, > protocol neutral, wrapper/daemon-free solution. I like it that way, and > I do understand it is a matter of taste. I agree. I've looked at ssh "wrappers", but I also don't like the extra daemons or cron jobs running. Especially since a non-standard port + ssh-keys works great for me. I really don't think we'll see ssh brute force bots looking at non-standard ports for a LONG time (not until everyone stops using 22). With 64K ports available, that's a LOT of extra scanning to do. - BS |
|
From: Martin G. <sou...@gl...> - 2007-03-04 18:50:58
|
On Sunday 04 March 2007 09:54, Bruce Smith wrote: > > I'm not commenting on the problem here, but a possible enhancement for > > the default firewall script of DL. See below: > > > > # Rate limit ssh connection attempts to 3 per 5 minutes per IP. > > iptables -A INPUT -p tcp --dport 22 -i eth0 -m state \ > > --state NEW -m recent --set > > iptables -A INPUT -p tcp --dport 22 -i eth0 -m state \ > > --state NEW -m recent --update --seconds 300 --hitcount 3 -j DROP > > > > This one does not create an additional queue like most other solutions > > for this common problem. I've found these 2 lines at the end of > > firewall script to be rather effective, yet problemless. > > > > No more brute-force-attack-trash in ssh log files. You might want to > > increase 300 seconds to 1800 for 30 minutes. > > I've done similar things in some of my firewall scripts to combat the > brute-force ssh attacks. > > The main problem occurs if you do a lot of scp's. Each scp initiates a > new ssh connection, and you end up locking yourself out for the time > period. > > The best way I've found to harden ssh against the brute-force attacks is > to have ssh listen on a high/non-standard port number, and do not allow > password authentication (ssh keys only). > > I've never had a brute force attacker find one of my non-standard ssh > ports, and even if they did, they could never login because they are > trying passwords (which I don't allow). > > A better solution (IMO) would be a modification to openssh so it shuts > down an IP for a [configurable] period of time, after a [configurable] > number of bad authentication attempts. I even suggested that to one of > the openssh developers I once had a small email thread with. > While we ae on the topic of blocking ssh attacks, I found this article which lists the pros and cons of various methods - http://www.la-samhna.de/library/brutessh.html I currently use sshblock on a number of my machines and it is configurable and works very well - the only issue is that ssh has to be built with tcp_wrappers support (not currently in Devil). Is there any way of getting tcp_wrappers into DL? Thx Martin |
|
From: Heiko Z. <he...@zu...> - 2007-03-05 16:58:30
|
On Sun, March 4, 2007 12:15, Heiko Zuerker wrote: > OOPS sorry for that (small typo, big effect). > I'm going to compile a new version and upload it into the testing > directory on the ftp server tomorrow. A newer version of DL is not on the FTP server in the testing directory. It should contain all the iptables modules. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Bruce S. <bw...@ar...> - 2007-03-05 17:55:54
|
> A newer version of DL is not on the FTP server in the testing directory. "not"? :-) - BS |
|
From: Heiko Z. <he...@zu...> - 2007-03-05 18:59:18
|
On Mon, March 5, 2007 11:55, Bruce Smith wrote: >> A newer version of DL is not on the FTP server in the testing >> directory. > > "not"? :-) crap.... A newer version of DL is NOW on the FTP server in the testing directory. -- Regards Heiko Zuerker http://www.devil-linux.org |
