After reading this article:
http://www.theregister.co.uk/2005/08/31/blocking_chinese_ip_addresses/
I got to thinking that there is really no reason for *any* traffic to hit my servers that comes from anywhere outside North America. So I wrote the perl script at the end of this posting to extract selected IP ranges posted at iana.org and convert them into iptables rules blocking any traffic from those ranges.
I'd like comments on this. I know it's not perfect as there are both corporate and 'various registries' address ranges that aren't covered but it's a start. Since my company web site is hosted elsewhere but we are doing the DNS, I put in the exceptions for DNS.
In my ten or so years of administering Linux servers, following the usual security precautions has been sufficient: closing unused ports, keeping up to date on patches, limiting permissions and logins, etc. I've never had a system broken into.
But if I can lessen the bandwidth used up by brute-force password attacks and port scans at the cost of a few CPU cycles, that's a good thing. I've had the new rules up on one server for about half an hour and can see about 10 or so connection attempts from the addresses in question.
What do you think?
Kirk Bocek
#!/usr/bin/perl # # iana-makeiptables.pl # Convert IPv4 Address assignment document from iana.org into # a shell script that will insert iptables rules to block traffic # from selected regional registries. # # Copy the data from: # http://www.iana.org/assignments/ipv4-address-space # and save it to the file in $datafile (here -- iana-assignments.dat) # Then edit the 'my @block' line below to select the registries you want to block # # Sept 6, 2005 Kirk Bocek # use strict;
my $datafile='iana-assignments.dat'; my $outfile='iana-block.sh'; #Registries are ARIN APNIC RIPE LACNIC AfriNIC my @block=qw/APNIC RIPE LACNIC AfriNIC/;
die "Data File $datafile Not Found!" unless -f $datafile; die "Cannot open $outfile for writing!" unless open OUT, ">$outfile"; die "Cannot open $datafile for reading!" unless open DAT, "<$datafile";
print OUT "#!/bin/bash\n"; print OUT "# Blocking traffic from: @block\n"; print OUT "# Generated by iana-makeiptables.pl\n";
foreach (<DAT>) { next unless /^\d{3}/8/; BLOCK: foreach my $reg (@block) { if (/^(\d{3})/8.*$reg/) { my $x=$1; $x=substr($x,1) if substr($x,0,1) eq '0'; #Strip leading zero $x=substr($x,1) if substr($x,0,1) eq '0'; #Might be two of them print OUT 'iptables -I INPUT -s ',$x,".0.0.0/8 -j DROP\n"; last BLOCK; } } }
#Put any exceptions here #For example, I'm allowing DNS traffic print OUT "iptables -I INPUT -p tcp -m tcp --dport 53 -j ACCEPT\n"; print OUT "iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT\n";
close OUT; close DAT; # End of iana-makeiptables.pl
On Tue, 2005-09-06 at 13:19, Kirk Bocek wrote:
After reading this article:
http://www.theregister.co.uk/2005/08/31/blocking_chinese_ip_addresses/
I got to thinking that there is really no reason for *any* traffic to hit my servers that comes from anywhere outside North America. So I wrote the perl script at the end of this posting to extract selected IP ranges posted at iana.org and convert them into iptables rules blocking any traffic from those ranges.
In my ten or so years of administering Linux servers, following the usual security precautions has been sufficient: closing unused ports, keeping up to date on patches, limiting permissions and logins, etc. I've never had a system broken into.
But if I can lessen the bandwidth used up by brute-force password attacks and port scans at the cost of a few CPU cycles, that's a good thing. I've had the new rules up on one server for about half an hour and can see about 10 or so connection attempts from the addresses in question.
What do you think?
Actually this won't reduce any bandwidth to your server. The probes still hit that address, you are just blocking those packets in iptables from begin able to get any further.
If you could implement this further up the line then you could reduce traffic to your servers.
Putting a blanket deny on traffic from specific IP ranges is effective if attacks are coming from those ranges. The problem is that hackers will typically want to use an intermediate site to launch an actual attack from. This makes it harder to trace the actual source of the attack. At least good hackers do this. Script kiddies don't know to do this.
As such I am not convinced this provides that much protection in the long run. But if this is something you see in your log files and have no need to have users from those address blocks access your site then IMHO you have the right to block those addresses. Just don't expect it to reduce the traffic hitting your server unless you block it at a router further up the line.
Scot L. Harris wrote:
Actually this won't reduce any bandwidth to your server. The probes still hit that address, you are just blocking those packets in iptables from begin able to get any further.
Are you saying that the single connect-and-drop that this scheme introduces is going to use the same bandwidth as a brute-force password attack on hundreds of login names?
If you could implement this further up the line then you could reduce traffic to your servers.
Sure, that would be good. <SARCASM> Do you think I can get SBC to implement custom filtering for our DSL? </SARCASM> ;)
Putting a blanket deny on traffic from specific IP ranges is effective if attacks are coming from those ranges. The problem is that hackers will typically want to use an intermediate site to launch an actual attack from. This makes it harder to trace the actual source of the attack. At least good hackers do this. Script kiddies don't know to do this.
If you read the article, you'll see that the author suggests that the traffic is probably coming from zombied personal machines in the far east occurring as a result of a lack of security knowledge and awareness in those new to the net.
I don't expect this to be perfect, just an additional step to protect my servers.
Kirk Bocek
Kirk Bocek wrote:
Scot L. Harris wrote:
Actually this won't reduce any bandwidth to your server. The probes still hit that address, you are just blocking those packets in iptables from begin able to get any further.
Are you saying that the single connect-and-drop that this scheme introduces is going to use the same bandwidth as a brute-force password attack on hundreds of login names?
<snipped>
Question, because I am not sure. Wouldn't the script that is being run have to be intelligent enough to move to the next machine without exhausting its attempts at guessing passwords in order for your firewalling scheme to effectively reduce bandwidth?
What I mean is, the script attempts to connect and try a password. It doesn't get a response so it assumes that the machine simply returned a login denied and tries again. It may try this several times per username (depending on the script). If that's the case, as it's not actually bothering to keep track of success of connection you're getting the same amount of connects as previously. Is that not true?
Now granted the above scenario is assuming a truly brain dead script, but they aren't all that more sophisticated than that (some of them).
Curious,
Alex
Good question Alex. However, I've never studied the scripts that 'script kiddies' use and so have no answer.
Part of what has prompted this change is the recent surge of brute-force password attacks. From the timing of the password attempts, it's clear that these are script driven.
I found a perl script that watches for failed logins. After a configurable number, the script enters the IP address into /etc/hosts.deny. After a configurable number of days, the script then removes the IP address.
What I see in /var/log/secure is a whole series of 'Invalid user' messages followed by 'Failed password for invalid user' messages. These will then, because of the script, be terminated by a 'refused connect from' message when the address is entered into hosts.deny.
My point in all this is that I only ever see *one* 'refused connect' message. So at least for this script, it gives up when it can't connect anymore.
Kirk Bocek
Alex White wrote:
Kirk Bocek wrote:
Scot L. Harris wrote:
Actually this won't reduce any bandwidth to your server. The probes still hit that address, you are just blocking those packets in iptables from begin able to get any further.
Are you saying that the single connect-and-drop that this scheme introduces is going to use the same bandwidth as a brute-force password attack on hundreds of login names?
<snipped>
Question, because I am not sure. Wouldn't the script that is being run have to be intelligent enough to move to the next machine without exhausting its attempts at guessing passwords in order for your firewalling scheme to effectively reduce bandwidth?
What I mean is, the script attempts to connect and try a password. It doesn't get a response so it assumes that the machine simply returned a login denied and tries again. It may try this several times per username (depending on the script). If that's the case, as it's not actually bothering to keep track of success of connection you're getting the same amount of connects as previously. Is that not true?
Now granted the above scenario is assuming a truly brain dead script, but they aren't all that more sophisticated than that (some of them).
Curious,
Alex _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Kirk,
If you don't mind, could you let me know where that script is? I'm seeing the same thing -- kiddies trying to log in. I use something similar, but manual entry on my mail server that is in a co-lo site running FreeBSD. Here at home, I thought I'd be pretty well protected behind the router, but I have to have the ssh port open, and I'm seeing hundreds of attempts.
Thanks...
Sam
Kirk Bocek wrote:
Good question Alex. However, I've never studied the scripts that 'script kiddies' use and so have no answer.
Part of what has prompted this change is the recent surge of brute-force password attacks. From the timing of the password attempts, it's clear that these are script driven.
I found a perl script that watches for failed logins. After a configurable number, the script enters the IP address into /etc/hosts.deny. After a configurable number of days, the script then removes the IP address.
What I see in /var/log/secure is a whole series of 'Invalid user' messages followed by 'Failed password for invalid user' messages. These will then, because of the script, be terminated by a 'refused connect from' message when the address is entered into hosts.deny.
My point in all this is that I only ever see *one* 'refused connect' message. So at least for this script, it gives up when it can't connect anymore.
Kirk Bocek
Instead of keeping the ssh port open, use something like the following:
-A INPUT -p tcp --dport SECRETPORT# -m recent --set -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 43200 -j ACCEPT
and then before ssh'ing in from outside telnet the SECRETPORT# on the machine in order to open the ssh port for the next 12 hours. Gets rid of script kiddies.
Cheers, MaZe.
On Tue, 6 Sep 2005, Sam Drinkard wrote:
Kirk,
If you don't mind, could you let me know where that script is? I'm seeing the same thing -- kiddies trying to log in. I use something similar, but manual entry on my mail server that is in a co-lo site running FreeBSD. Here at home, I thought I'd be pretty well protected behind the router, but I have to have the ssh port open, and I'm seeing hundreds of attempts. Thanks...
Sam
Kirk Bocek wrote:
Good question Alex. However, I've never studied the scripts that 'script kiddies' use and so have no answer.
Part of what has prompted this change is the recent surge of brute-force password attacks. From the timing of the password attempts, it's clear that these are script driven.
I found a perl script that watches for failed logins. After a configurable number, the script enters the IP address into /etc/hosts.deny. After a configurable number of days, the script then removes the IP address.
What I see in /var/log/secure is a whole series of 'Invalid user' messages followed by 'Failed password for invalid user' messages. These will then, because of the script, be terminated by a 'refused connect from' message when the address is entered into hosts.deny.
My point in all this is that I only ever see *one* 'refused connect' message. So at least for this script, it gives up when it can't connect anymore.
Kirk Bocek
On Tue, 2005-09-06 at 20:16, Maciej Żenczykowski wrote:
Instead of keeping the ssh port open, use something like the following:
-A INPUT -p tcp --dport SECRETPORT# -m recent --set -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 43200 -j ACCEPT
and then before ssh'ing in from outside telnet the SECRETPORT# on the machine in order to open the ssh port for the next 12 hours. Gets rid of script kiddies.
Or just move the ssh port to another port number. I also got tired of all the log file activity. Moved ssh to another port and have not seen any of that traffic since then.
I'm familiar with 'port-knocking' and after mulling it over decided to simply use the 'PermitRootLogin without-password' option to sshd. I looked at the user names being testing in the scripts and decided that it was unlikely anyone would hit one of our users, especially with the security script I had installed. Forcing DSA keys for root access solved my last concern.
Kirk Bocek
Maciej Żenczykowski wrote:
Instead of keeping the ssh port open, use something like the following:
-A INPUT -p tcp --dport SECRETPORT# -m recent --set -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 43200 -j ACCEPT
and then before ssh'ing in from outside telnet the SECRETPORT# on the machine in order to open the ssh port for the next 12 hours. Gets rid of script kiddies.
Cheers, MaZe.
On Tue, 6 Sep 2005, Sam Drinkard wrote:
Kirk,
If you don't mind, could you let me know where that script is? I'm seeing the same thing -- kiddies trying to log in. I use something similar, but manual entry on my mail server that is in a co-lo site running FreeBSD. Here at home, I thought I'd be pretty well protected behind the router, but I have to have the ssh port open, and I'm seeing hundreds of attempts. Thanks...
Sam
Kirk Bocek wrote:
Good question Alex. However, I've never studied the scripts that 'script kiddies' use and so have no answer.
Part of what has prompted this change is the recent surge of brute-force password attacks. From the timing of the password attempts, it's clear that these are script driven.
I found a perl script that watches for failed logins. After a configurable number, the script enters the IP address into /etc/hosts.deny. After a configurable number of days, the script then removes the IP address.
What I see in /var/log/secure is a whole series of 'Invalid user' messages followed by 'Failed password for invalid user' messages. These will then, because of the script, be terminated by a 'refused connect from' message when the address is entered into hosts.deny.
My point in all this is that I only ever see *one* 'refused connect' message. So at least for this script, it gives up when it can't connect anymore.
Kirk Bocek
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
No! It's my secret! Bu-Wa-Ha-Ha! (or however that's spelled...)
Okay, you forced it out of me...
http://linuxmafia.com/pub/linux/security/ssh-dictionary-attack-blacklist
:)
Sam Drinkard wrote:
Kirk,
If you don't mind, could you let me know where that script is? I'm seeing the same thing -- kiddies trying to log in. I use something similar, but manual entry on my mail server that is in a co-lo site running FreeBSD. Here at home, I thought I'd be pretty well protected behind the router, but I have to have the ssh port open, and I'm seeing hundreds of attempts. Thanks...
Sam
Kirk Bocek wrote:
Good question Alex. However, I've never studied the scripts that 'script kiddies' use and so have no answer.
Part of what has prompted this change is the recent surge of brute-force password attacks. From the timing of the password attempts, it's clear that these are script driven.
I found a perl script that watches for failed logins. After a configurable number, the script enters the IP address into /etc/hosts.deny. After a configurable number of days, the script then removes the IP address.
What I see in /var/log/secure is a whole series of 'Invalid user' messages followed by 'Failed password for invalid user' messages. These will then, because of the script, be terminated by a 'refused connect from' message when the address is entered into hosts.deny.
My point in all this is that I only ever see *one* 'refused connect' message. So at least for this script, it gives up when it can't connect anymore.
Kirk Bocek
Kirk Bocek wrote:
No! It's my secret! Bu-Wa-Ha-Ha! (or however that's spelled...)
Okay, you forced it out of me...
http://linuxmafia.com/pub/linux/security/ssh-dictionary-attack-blacklist
:)
Sam Drinkard wrote:
Kirk,
If you don't mind, could you let me know where that script is? I'm seeing the same thing -- kiddies trying to log in. I use something similar, but manual entry on my mail server that is in a co-lo site running FreeBSD. Here at home, I thought I'd be pretty well protected behind the router, but I have to have the ssh port open, and I'm seeing hundreds of attempts. Thanks...
Sam
Kirk Bocek wrote:
Good question Alex. However, I've never studied the scripts that 'script kiddies' use and so have no answer.
Part of what has prompted this change is the recent surge of brute-force password attacks. From the timing of the password attempts, it's clear that these are script driven.
I found a perl script that watches for failed logins. After a configurable number, the script enters the IP address into /etc/hosts.deny. After a configurable number of days, the script then removes the IP address.
What I see in /var/log/secure is a whole series of 'Invalid user' messages followed by 'Failed password for invalid user' messages. These will then, because of the script, be terminated by a 'refused connect from' message when the address is entered into hosts.deny.
My point in all this is that I only ever see *one* 'refused connect' message. So at least for this script, it gives up when it can't connect anymore.
Kirk Bocek
Thanks for that linkage. And your previous explanation of what you were seeing. Sorry I've been ill so couldnt' check the list until today. Really appreciate it.
Sincerely,
Alex
centos-bounces@centos.org wrote:
Kirk Bocek wrote:
No! It's my secret! Bu-Wa-Ha-Ha! (or however that's spelled...)
Okay, you forced it out of me...
http://linuxmafia.com/pub/linux/security/ssh-dictionary-attack-blacklist
Howdy Folks. I've been attempting running this script on my system but I keep keeting the error:
bash: ./sshd-sentry: bad interpreter: Permission denied
The docs say the script is supposed to be called sshd-sentry but in the code it's sshd_sentry.
perl is in the correct place....
Anyone using this script that might have an idea? I am running it on my DNS server which is RH7.2.. could this be the problem?
..DOUG KD4MOJ
Make sure the line "#!/usr/bin/perl" is the very first line of the script. No empty lines before it and no spaces before the "#!"
Kirk
Doug Ferrell wrote:
centos-bounces@centos.org wrote:
Kirk Bocek wrote:
No! It's my secret! Bu-Wa-Ha-Ha! (or however that's spelled...)
Okay, you forced it out of me...
http://linuxmafia.com/pub/linux/security/ssh-dictionary-attack-blacklist
Howdy Folks. I've been attempting running this script on my system but I keep keeting the error:
bash: ./sshd-sentry: bad interpreter: Permission denied
The docs say the script is supposed to be called sshd-sentry but in the code it's sshd_sentry.
perl is in the correct place....
Anyone using this script that might have an idea? I am running it on my DNS server which is RH7.2.. could this be the problem?
..DOUG KD4MOJ
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Looking at that perl script gave me an idea, but yet a question. I notice there is a line that says something about "Max Retries". Is that something that is configurable somewhere, or can be turned on?
I know there have been long discussions about blocking the brute force attempts at breakins, but at the time I did not see much need for it. Not long after that, I started seeing somewhere between 100 and as high as 800 attempts to break in via the sshd. Not that I'm too worried about someone guessing a password, but in those numbers, it does take some bandwidth. I'd like to see something like Max Retries of 3, so if someone tries 3 times to guess the password, or different usernames, it would throw their IP/hostname into the /etc/hosts.deny file, permanently. BSD does things a bit different, in that the hosts.allow does both the allows and the denies, making hosts.deny pretty much moot. Given those thoughts, what kind of something is available to do just that -- the max retries thingy?
Thanks...
Sam
Kirk Bocek wrote:
Make sure the line "#!/usr/bin/perl" is the very first line of the script. No empty lines before it and no spaces before the "#!"
Kirk
Doug Ferrell wrote:
centos-bounces@centos.org wrote:
Kirk Bocek wrote:
No! It's my secret! Bu-Wa-Ha-Ha! (or however that's spelled...)
Okay, you forced it out of me...
http://linuxmafia.com/pub/linux/security/ssh-dictionary-attack-blacklist
Howdy Folks. I've been attempting running this script on my system but I keep keeting the error:
bash: ./sshd-sentry: bad interpreter: Permission denied
The docs say the script is supposed to be called sshd-sentry but in the code it's sshd_sentry.
perl is in the correct place....
Anyone using this script that might have an idea? I am running it on my DNS server which is RH7.2.. could this be the problem?
..DOUG KD4MOJ
On Sat, Oct 08, 2005 at 01:50:59PM -0400, Sam Drinkard enlightened us:
Looking at that perl script gave me an idea, but yet a question. I notice there is a line that says something about "Max Retries". Is that something that is configurable somewhere, or can be turned on?
I know there have been long discussions about blocking the brute force attempts at breakins, but at the time I did not see much need for it. Not long after that, I started seeing somewhere between 100 and as high as 800 attempts to break in via the sshd. Not that I'm too worried about someone guessing a password, but in those numbers, it does take some bandwidth. I'd like to see something like Max Retries of 3, so if someone tries 3 times to guess the password, or different usernames, it would throw their IP/hostname into the /etc/hosts.deny file, permanently. BSD does things a bit different, in that the hosts.allow does both the allows and the denies, making hosts.deny pretty much moot. Given those thoughts, what kind of something is available to do just that -- the max retries thingy?
Thanks...
http://denyhosts.sourceforge.net/
Matt
On Saturday 08 October 2005 02:41 pm, Matt Hyclak wrote:
On Sat, Oct 08, 2005 at 01:50:59PM -0400, Sam Drinkard enlightened us:
Looking at that perl script gave me an idea, but yet a question. I notice there is a line that says something about "Max Retries". Is that something that is configurable somewhere, or can be turned on?
I know there have been long discussions about blocking the brute force attempts at breakins, but at the time I did not see much need for it. Not long after that, I started seeing somewhere between 100 and as high as 800 attempts to break in via the sshd. Not that I'm too worried about someone guessing a password, but in those numbers, it does take some bandwidth. I'd like to see something like Max Retries of 3, so if someone tries 3 times to guess the password, or different usernames, it would throw their IP/hostname into the /etc/hosts.deny file, permanently. BSD does things a bit different, in that the hosts.allow does both the allows and the denies, making hosts.deny pretty much moot. Given those thoughts, what kind of something is available to do just that -- the max retries thingy?
Thanks...
Try using ALL: PARANOID in /etc/hosts.deny - this will drop a lot of the trojaned residential dsl/cable modems.
Thanks to all for responding. I've looked over the denyhosts files/faq/etc., and that looks like the tool I'll wind up using, both here and on my mailserver downtown. I know from the BSD machine downtown, many of the attempts are not so much dictionary types but random/casual types of attempts, yet it still is a bother to see all the failed attempts in the logs. My centos machine is down until I get yet another new mobo.. long story, but this makes 3, and this one was DOA. Anyhow, it will at least cut down on some of the wasted bandwidth here at home, which is in at times, short supply. I'd considered a non-std port for ssh, but I have some folks who would never remember to tell ssh to use a non-std port. Some have a hard enough time getting logged in using the normal stuff...
I guess I need to read a bit more on the ALL:PARANOID bit.. that also might work for here, but not downtown.
Sam
Ryan wrote:
On Saturday 08 October 2005 02:41 pm, Matt Hyclak wrote:
On Sat, Oct 08, 2005 at 01:50:59PM -0400, Sam Drinkard enlightened us:
Looking at that perl script gave me an idea, but yet a question. I notice there is a line that says something about "Max Retries". Is that something that is configurable somewhere, or can be turned on?
I know there have been long discussions about blocking the brute force attempts at breakins, but at the time I did not see much need for it. Not long after that, I started seeing somewhere between 100 and as high as 800 attempts to break in via the sshd. Not that I'm too worried about someone guessing a password, but in those numbers, it does take some bandwidth. I'd like to see something like Max Retries of 3, so if someone tries 3 times to guess the password, or different usernames, it would throw their IP/hostname into the /etc/hosts.deny file, permanently. BSD does things a bit different, in that the hosts.allow does both the allows and the denies, making hosts.deny pretty much moot. Given those thoughts, what kind of something is available to do just that -- the max retries thingy?
Thanks...
Try using ALL: PARANOID in /etc/hosts.deny - this will drop a lot of the trojaned residential dsl/cable modems. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Saturday 08 October 2005 07:56 pm, Sam Drinkard wrote:
I guess I need to read a bit more on the ALL:PARANOID bit.. that also might work for here, but not downtown.
Here is a nice manual page that is short and to the point: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-tcpwrappe...
I guess I need to read a bit more on the ALL:PARANOID bit.. that also might work for here, but not downtown.
In my experience paranoid is more of a nuissance then a help. I've often been blocked simply because I was on a temporary computer which had no reverse DNS -- it's annoying and not that uncommon.
Another solution would be to use the linux firewall 'recent' match type or 'limit' match types to limit connections to a certain number per hour or something.
Ie. something like this (all in filter table):
:newssh - [0:0] :whitelist - [0:0]
-A INPUT -p tcp --dport 12345 -m recent --set -A INPUT -p tcp --dport ssh -m state --state NEW -j newssh
-A newssh -m recent --update --seconds 43200 -j ACCEPT -A newssh -j whitelist
-A whitelist -s 127.0.0.0/8 -j ACCEPT -A whitelist -s 10.0.0.0/8 -j ACCEPT -A whitelist -s 172.16.0.0/12 -j ACCEPT -A whitelist -s 192.168.0.0/16 -j ACCEPT -A whitelist -s x.y.z.0/24 -j ACCEPT -A whitelist -s static_home_ip_number -j ACCEPT
The above accepts ssh connections from IP's which have tried telneting in to port 12345 (or been allowed to ssh) within the past 12 hours and from anybody in the WHITELIST chain (which basically accepts private/local networks, and my own computers, etc)
Or instead of the newssh chain above you could try:
-A newssh -j whitelist -A newssh -m limit --limit 1/hour --limit-burst 5 -j ACCEPT
Which would accept any whitelisted computer and a maximum of 5 attempts in a row from anywhere else (recharge rate of 1 per hour). Of course the above doesn't distinguish IP's.
So you could do something like this: -A newssh -j whitelist -A newssh -m recent --update --seconds 3600 --hitcount 10 -j REJECT --reject-with tcp-reset -A newssh -j ACCEPT
Which would accept any whitelisted computer, and up to 10 connections within an hour from any other IP.
I think the above (to be placed in /etc/sysconfig/iptables) are a lot easier solutions than some scripts - although these solutions do not distinguish between successful logins and failures. Still the level of complication is a lot easier and this approach will work for _ANY_ tcp/ip service.
Cheers, MaZe.
On Sunday 09 October 2005 05:10 am, Maciej Żenczykowski wrote:
In my experience paranoid is more of a nuissance then a help. I've often been blocked simply because I was on a temporary computer which had no reverse DNS -- it's annoying and not that uncommon.
That is the real downside. Although, luckily since most of the attacks come from residential ISPs (or at least mine seem to), ALL PARANOID will block 'em.
On Sat, 2005-10-08 at 13:50, Sam Drinkard wrote:
Looking at that perl script gave me an idea, but yet a question. I notice there is a line that says something about "Max Retries". Is that something that is configurable somewhere, or can be turned on?
I know there have been long discussions about blocking the brute force attempts at breakins, but at the time I did not see much need for it. Not long after that, I started seeing somewhere between 100 and as high as 800 attempts to break in via the sshd. Not that I'm too worried about someone guessing a password, but in those numbers, it does take some bandwidth. I'd like to see something like Max Retries of 3, so if someone tries 3 times to guess the password, or different usernames, it would throw their IP/hostname into the /etc/hosts.deny file, permanently. BSD does things a bit different, in that the hosts.allow does both the allows and the denies, making hosts.deny pretty much moot. Given those thoughts, what kind of something is available to do just that -- the max retries thingy?
Would you not get the same or better results by moving the sshd port to something other than the default? Would not have to spend any resources on tracking IP addresses.
For the paranoid firewalling, do both? ;) (adjusting ports to match)
On 10/8/05, Scot L. Harris webid@cfl.rr.com wrote:
On Sat, 2005-10-08 at 13:50, Sam Drinkard wrote:
Looking at that perl script gave me an idea, but yet a question. I notice there is a line that says something about "Max Retries". Is that something that is configurable somewhere, or can be turned on?
I know there have been long discussions about blocking the brute force attempts at breakins, but at the time I did not see much need for it. Not long after that, I started seeing somewhere between 100 and as high as 800 attempts to break in via the sshd. Not that I'm too worried about someone guessing a password, but in those numbers, it does take some bandwidth. I'd like to see something like Max Retries of 3, so if someone tries 3 times to guess the password, or different usernames, it would throw their IP/hostname into the /etc/hosts.deny file, permanently. BSD does things a bit different, in that the hosts.allow does both the allows and the denies, making hosts.deny pretty much moot. Given those thoughts, what kind of something is available to do just that -- the max retries thingy?
Would you not get the same or better results by moving the sshd port to something other than the default? Would not have to spend any resources on tracking IP addresses.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 2005-09-06 at 10:19 -0700, Kirk Bocek wrote:
After reading this article:
http://www.theregister.co.uk/2005/08/31/blocking_chinese_ip_addresses/
I got to thinking that there is really no reason for *any* traffic to hit my servers that comes from anywhere outside North America. So I wrote the perl script at the end of this posting to extract selected IP ranges posted at iana.org and convert them into iptables rules blocking any traffic from those ranges.
I'd like comments on this. I know it's not perfect as there are both corporate and 'various registries' address ranges that aren't covered but it's a start. Since my company web site is hosted elsewhere but we are doing the DNS, I put in the exceptions for DNS.
In my ten or so years of administering Linux servers, following the usual security precautions has been sufficient: closing unused ports, keeping up to date on patches, limiting permissions and logins, etc. I've never had a system broken into.
But if I can lessen the bandwidth used up by brute-force password attacks and port scans at the cost of a few CPU cycles, that's a good thing. I've had the new rules up on one server for about half an hour and can see about 10 or so connection attempts from the addresses in question.
What do you think?
Kirk Bocek
#!/usr/bin/perl # # iana-makeiptables.pl # Convert IPv4 Address assignment document from iana.org into # a shell script that will insert iptables rules to block traffic # from selected regional registries. # # Copy the data from: # http://www.iana.org/assignments/ipv4-address-space # and save it to the file in $datafile (here -- iana-assignments.dat) # Then edit the 'my @block' line below to select the registries you want to block # # Sept 6, 2005 Kirk Bocek # use strict;
my $datafile='iana-assignments.dat'; my $outfile='iana-block.sh'; #Registries are ARIN APNIC RIPE LACNIC AfriNIC my @block=qw/APNIC RIPE LACNIC AfriNIC/;
die "Data File $datafile Not Found!" unless -f $datafile; die "Cannot open $outfile for writing!" unless open OUT, ">$outfile"; die "Cannot open $datafile for reading!" unless open DAT, "<$datafile";
print OUT "#!/bin/bash\n"; print OUT "# Blocking traffic from: @block\n"; print OUT "# Generated by iana-makeiptables.pl\n";
foreach (<DAT>) { next unless /^\d{3}/8/; BLOCK: foreach my $reg (@block) { if (/^(\d{3})/8.*$reg/) { my $x=$1; $x=substr($x,1) if substr($x,0,1) eq '0'; #Strip leading zero $x=substr($x,1) if substr($x,0,1) eq '0'; #Might be two of them print OUT 'iptables -I INPUT -s ',$x,".0.0.0/8 -j DROP\n"; last BLOCK; } } }
#Put any exceptions here #For example, I'm allowing DNS traffic print OUT "iptables -I INPUT -p tcp -m tcp --dport 53 -j ACCEPT\n"; print OUT "iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT\n";
close OUT; close DAT; # End of iana-makeiptables.pl
Awesome, added to my todo list.
Regards, Ted
Kirk Bocek wrote:
After reading this article:
http://www.theregister.co.uk/2005/08/31/blocking_chinese_ip_addresses/
I got to thinking that there is really no reason for *any* traffic to hit my servers that comes from anywhere outside North America. So I wrote the perl script at the end of this posting to extract selected IP ranges posted at iana.org and convert them into iptables rules blocking any traffic from those ranges.
Sure! Greetings from Holland (The Netherlands) by the way.
As an entrepreneur my company is doing business all over the world. Simply blocking the "Rest of the world" is a foolish thing. That means that somebody from India (a lot of US and European countries are running their operations from that country). As far as I can read your script, even an e-mail from India or Europe would not get through (It blocks a lot of spam *grin* but also business opportunities.
My strategy is to block anything with a login-prompt except for hosts which are on my local network or connect via a VPN. So I've disabled telnet (port 23) and SSH (port 22) is only allowed from my local network or from users connected through the VPN. I run an FTP server on almost al my servers, but the only one reachable from the Internet is a CentOS mirror you can use anonymously. DNS, http(s) and smtp traffic is allowed by my firewall to the servers. The rest is blocked.
I'd like comments on this. I know it's not perfect as there are both corporate and 'various registries' address ranges that aren't covered but it's a start. Since my company web site is hosted elsewhere but we are doing the DNS, I put in the exceptions for DNS.
START with the DNS exeptions..... You are now also blocking DNS requests (and also the DNS requests to get your MX records) from the rest of the world. And what about SMTP traffic from the rest of the world?
In my ten or so years of administering Linux servers, following the usual security precautions has been sufficient: closing unused ports, keeping up to date on patches, limiting permissions and logins, etc. I've never had a system broken into.
But if I can lessen the bandwidth used up by brute-force password attacks and port scans at the cost of a few CPU cycles, that's a good thing. I've had the new rules up on one server for about half an hour and can see about 10 or so connection attempts from the addresses in question.
What do you think?
Kirk Bocek
(...)
Thom
-
Alex White -
Doug Ferrell -
Ian mu -
Kirk Bocek -
Maciej Żenczykowski -
Matt Hyclak -
Ryan -
Sam Drinkard -
Scot L. Harris -
Ted Kaczmarek -
Thom van der Boon