Block Brute Force Attacks With Iptables

The two iptables rules look identical to me. Shouldn\'t one be UDP?

Hi Bob,

There should a a scrollbar. If your scroll to the right you will see that the rules are not identical. The first one identifies SSH traffic and the second one drops the traffic under specific circumstances.

SSH is TCP only, so no need for dropping UDP traffic in this example.

Could it be that your browser is not showing the scrollbars correctly? I\'ve tested on ubuntu/firefox2 and windows/ie6+7

Two little improvments to make:
In the beginning of the script add:
if [ \"$METHOD\" = loopback ]; then
exit 0
fi
...to ensure that it isn\'t run on lo-interfaces.

furthermore you have the certain interfaces name in $IFACE
one could simply insert $IFACE instead of eth0. Works great if let\'s say, you travel a lot and change from wired to wireless networks all the time...

@ Lukas Meyer: Thank you, I\'ve updated the scripts!

Or just change your sshd port to something other than default

Another option is to use the DenyHosts script which will automatically put a host in the hosts.deny file after so many failed login attempts.

http://denyhosts.sourceforg...

Like Azmith said, change your SSH port to something non-default. For example, if you change your SSH port to 52004, you will most likely be safe from 0 day SSH worms. In order to propogate in a reasonable amount of time they will only try 22. In addition, you can add your IP table rules.

So clear and simple. Thanks!

if you can afford the \"trouble\", you can also configure your sshd to use keypairs only.

Hm, I use something similar, but not quite the same:

iptables -A INPUT --protocol tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 10 -j DROP
iptables -A INPUT --protocol tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT

iptables -A INPUT --protocol tcp --dport ssh -m limit --limit 3/minute --limit-burst 2 -j ACCEPT

I got this a while back (~2-3 yrs ago?) after searching for good iptables rules, and it seemed to do the trick, stopping brute force attacks.

fail2ban....works wonders for brute force attacks.

DenyHosts is best solution I\'ve seen for Brute Force SSH attacks.

How does this work if I port-forward to a different computer on the \"inside\"?

/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j DNAT --to $ssh_server:22
/sbin/iptables -t nat -A POSTROUTING -p tcp -s #ssh_server --sport 22 -j SNAT --to $externalIP:22

Thanks for all of your input. I\'m familiar with both fail2ban and denyhosts. They\'re both awesome solutions, and they may be even easier to set up.

But I wrote this article just to show people that there are different ways. And I felt iptables has a lot to offer that many of us don\'t know about.

Each way has it\'s own advantages and it\'s up to the end user to decide which one suits the situation best.

Are you saying that Linux isn\'t infallible? Now way! It\'s almost like it\'s written by amateurs!

@ OMFG: According to WIKI \"most commonly an amateur is understood to be someone who does something without pay\", so you\'re probably right ;)

All Operating Systems have their flaws, but I think it\'s like Churchill\'s famous dictum: \"Democracy is the worst form of government, except for all those other forms that have been tried from time to time.\" Maybe this goes for Linux too ;)

Nice! Thanks for this; quick and easy, and nothing more to install.

SnortSam - Flexible, per rule blocking specification, including rule dependent blocking time interval.

Is there any way to implement this in Shorewall?

I\'m also a big fan of DenyHosts. It\'s fast, efficient and can be configured to clear the denied hosts at certain intervals.

Or you can edit /etc/ssh/sshd_config

Some interesting things in this file:

Port 2222
PermitRootLogin no
MaxAuthTries 2
AllowUsers ::YOURUSER::

yep...

I\'ve changed the ports my ssh servers run on. It\'s incredible to see all the attempts on port 22. The one issue that I\'ve run into with this config is I ended up with some issues with Subversion. A little work with my .ssh/config and I was back in business.

Not bad at all! Another layer to add in!

If you\'d like to be preemptive and lock out known attackers even before they start on your box - try Denyhosts and use the shared database options.

http://denyhosts.sourceforg...

Think along the lines of a DNSRBL for ssh brute forcers. But one where the attackers pretty much have to prove themselves as attackers to get listed.

Does this rule make it possible to do a denial of service attack?

I mean, it is possible that a bruceforce attack will make it impossible for all IP adresses to login?

Hey! My vps has three entries in /etc/network/interfaces. venet0 and two others for the two ips, venet0:0 and venet0:1

What should I do? What rules does it need? :P

Thanks in advance and keep up the great work! :)

Moving sshd to a different port doesn\'t work as well as you might like. A few years ago I had an account on a machine that was not well maintained and there was an ssh problem that was not patched. The machine was broken into. It was on a non-standard port. It was still broken into.

I would recommend against a non-standard port. It will confuse good users, it won\'t stop the bad guys, and it might make you complacent about maintaining your machine *and* having good passwords that are not reused elsewhere on the net.

-kb

Great information I would love to post this for our readers over @ <a href=\"http://www.askTheAdmin.com\">AskTheAdmin.com</a>

Very interesting post.
I didn\'t know this module!

I prefer this iptables rule. Similar to yours, except it will only allow a maximum of 3 tries in 300 seconds. This effectively filters out about 98% of the scans and automatically turns back on, etc.

#! /bin/sh
# rate-limit connections to sshd
iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --rcheck --seconds 300 --hitcount 3 -j LOG --log-prefix \'SSH REJECT: \'
iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --rcheck --seconds 300 --hitcount 3 -j REJECT --reject-with tcp-reset

I like denyhosts, but on top of that I always keep a konsole open with an active view of what\'s going on with my system.log

tail -f /var/log/syslog/var/log/syslog

What\'s really fun is to do a whois on the ip that\'s doing the brute force attack, call their isp, and tell them one of their ips is doing a dictionary attack on your ssh server. Then if you hear a gulp ... you can tell THEY were the ones doing it. Classic.

Personally I like denyhosts because you can set it up to contact their database, and get even more protection against attackers. I like the thought of being able to access my computer from anywhere in the world.

it\'s even easier to do this with OpenBSD\'s PF, (available on other BSDs as well), integrated in yor reglar rule set. see eg http://home.nuug.no/~peter/...

Why not use asymmetric SSH2 key encryption? I have been using that for years and disable every other login option. You should just remind yourself of replacing your keys regularly.

A brute force attack on such a configuration might be possible but requires some really heavy-duty supercomputer. If you upgrade to newer OpenSSH versions and encryption strengths there is not much to be broken into.

I am using pam_abl for like 3 years on many servers. It can autoblacklist users and IP, is simple to configure and fun! And because its based on PAM, it is real system solution
http://www.hexten.net/wiki/...

ossec (http://www.ossec.net/) and denyhosts is similar, and maybe easier to setup for joe.

An alternative is to try ssh-faker (http://www.pkts.ca/ssh-fake.... It will still allow users who know the \"faker\" password through, but stops the brute force attacks at zero attempts instead of 8 per minute.

The trouble with 8 per minute is that there is still a very small chance that one of those 8 tries hits your userid/password combo. At which point the attacker has your machine, even with your iptables rules.

I Put the iptables in my /etc/init.d/boot.local under OpenSUSE 10.2, and added /usr/ before the path to iptables. Works great and makes my log file happy.

Thanks for all the tips you guys!

Is using -m recent better than using -m limit ?
I do this with -m limit. I haven\'t thought
about -m recent.

@ Geog: Correct me if I\'m wrong but I believe -m limit rate limits connections to a port globally, without caring about where the connections are coming from, whereas -m recent keeps track of individual IPs.

This was a really great article. I\'m glad i came across your blog (via digg) thanks!!

Hi Kevin,
Great article. Just one question.

The two rules are protecting us from \"out side\", but if the attack come from the internal network What do we need change in the rules ?

Bests

Hi Daniel, I think you could just remove the -i eth0 option. This way you do not specify a network interface so it should work for all your interfaces (LAN + WAN)

In your article at the part where it says \"Restore on boot\" and it describes where to put it for ubuntu, what do you do for fedora cause it doesnt have an ifup.d dorectory, only /etc/sysconfig/network-scripts
which is loaded with several scripts.
Not sure what to do.

if you have moderately good passwords (ie not guessable first try), but requires the attacker to try the whole character space available (some 96 odd chars) we\'re lookinga t 96^6 attempts for a 6 char password. at 100 tries per second (dos attack!) we\'re looking at 248 years. or 0.4% chance per year * account. Not per year per account, per year * account, meaning once they fail to break open \'apache\' user because there IS no password for apache, they have to spend another 248 years to exhaust the space for \'samba\' another account likely to not have a password (at least in debian).

Imagine if you used 8 char passwords instead! (now we\'re looking at 2.2 million years.)

This all assumes you arent noticing 100 attacks per second (!). Thats nearly a dos attack at that rate, and serious neglect of managing the huge log files that would result. (200 chars per attempt there. at 100 attempts/s * 200 chars we\'re looking at 20K/SECOND, or nearly 2 GIGS a day.

So.

I think its better to put your effort into securing things that are really hackable, like that php script you wrote that no one else on the planet is using (thus you arent benefitting from 10,000 eyes on your code). Not to mention just plain not using a windows box to login to your unix servers, ever, cuz then they have your root password.

This is great. After reading it I just had a casual look at my auth.log file, and was surprised to see some very concerted brute-force attacks. I made the appropriate entries into iptables (and also finally got around to disabling root login for ssh, something I\'d been meaning to do for a long time now...).

Thanks so much for laying that out. I\'m a long time PC geek but I\'m just trying to get back into linux after a long, long hiatus. I knew where my logs were, I knew I had a problem, and I knew iptables was the solution but figuring out how to use it hasn\'t been quite as easy as I would have hoped. This little article hit the nail right on the head. Well my problem was actually FTP, but a couple tiny modifications and voila, no more 10,000 entries per day on my FTP server logs. Thanks again!

Also, @math and others with the same snipe:
The issue isn\'t of whether they\'re going to break in really. It\'s the amount of bandwidth (1gb/day for me for the last 3 days here) and the size of the logs (about 1mb per day). Not only does that add up fast, it makes it nearly impossible to check the logs to see what legitimate users are doing. As amusing as it is to watch 8 synchronized bots chew through a dictionary of passwords each day on every common user name starting with \"Administrator\" I only need a couple entries to send off a nastygram to their ISPs :)

smooch! Thanks a ton. That helped.

To implement in shorewall, use the Rate Limit options in /etc/shorewall/rules

Nice article, but I would take issue with you saying that it\'s just a matter of time before a brute force login attack works. With a half decent password, the length of time it\'d take simply makes it unfeasible. Bear in mind that a brute force attack over the network is several orders of magnitude slower than a password cracker such as John (which can typically try tens of thousands of passwords per second).

Maybe I\'m just nit-picking though, because apart from that it\'s a really well-written and informative article

Thanks everyone for the useful comments. @ Pete: but what if your server is subject to a coordinated attack with multiple machines on Gigabit. I\'ve seen this happen in real life. And assuming that your password is probably not going to be cracked, does not provide solid security. As machines & connections are getting faster & faster, more combinations can be tried in less time. This is a movement that will not stop, making it more & more likely a brute force attack will succeed. Besides, it\'s a good way to stop the pollution in your ssh logfiles.

To have some fun, you can setup a honeypot on the standart port and do counter attacks >:) , since the attacking machine is probably a brute force victim, you can eventually get in (and do some fixing ... muahahaa ...)

So, what do you do when you\'re running a RH based distro? The /etc/network dir isn\'t on CentOS, Fedora, RHEL etc. I have no clue how to implement this on one of these servers..

And I see I\'m not the only one (there are some others asking the exact same thing in the comments, yet nobody responded..).

@ Carl: One thing that works on almost every distro is to put it into: /etc/rc.local

But I think more elegant that the rules become active when networking comes up, and clear when it goes down.

There must be a Red Hat equivalent for the /etc/network/if-up.d method, but I just don\'t know Red Hat (clones) that well. So maybe you\'d better ask them or their communities how to do it.

Excellent article, Kevin.

I tried to install a port 22 throttle into my Iptables once before but the example lines didn\'t work. Yours worked just fine. One change I did make, though was to change the DROP to a REJECT --reject-with tcp-reset

(Those folks who run those bots annoy me! <G>)

Thanks again!

P.S. Oh, and one thing I\'ve never been able to get to work on my FC system (for two distros now) is for my own Iptables to \"take\" on startup. I can get on the Net, but my intranet machines can\'t until I drop the firewall (flush all the chains, etc.) and the restart it. This, even though I have \"service iptables save\" as the last line in my script, so that the chains are saved into the file FC reads on startup.

Thanks again!

Hi Kevin,

Very useful, thanks!

Thanks Kevin!

So you say \"rate-limit all incoming SSH connections to 8 in a one minute window\". So is this 8 connections to eth0 from any IP, or 8 connections per IP per minute?

@ Simon: this is the maximum per IP.

i guess iptables-save and iptables-restore should be mentioned somewhere.. this is the easy buildin way of saving and restoring the tables.. (who could have thought that? ;) )

i think it is build in in ubuntu/debian

for further information tortoure you man pages

man iptables-save
man iptables-restore

@ makkksimal: Thanks for pointing that out. To keep the article compact I choose to use scripting and ignore the iptables-save & restore, since with iptables-restore you would still need scripting anyway. Scripting also offers greater flexibility in my humble opinion.

Maybe its a matter of preference. I use iptables-save and restore with my init scripts for years and find it very comfortable. But your right.. you need scripting anyway.

And as always there a many ways to get what you like and need :)

ok i\'ve read alot of posts here and now I have to chime in. First off, in red hat flavored distros like CENTOS for instance, /etc/sysconfig/iptables has all the config lines in it, just like you\'d type them, minus of course the \"iptables\" so you can just stick your entries in there. Every time you restart, which on a good running box is like what? Never? It will reinstate the same rules. I can\'t see any freaking point at all in removing the rules when you shut down the interface, wasting that time making a script, if, when the interface is shut down nobocdy will be SSH\'ing to it since it\'s not there

Also, like someone said early on, just change ports and that will block the millions of script kiddie, I think I\'m a hacker cuz I downloaded this program and can type in IP addresses people. Also think about what your server is used for people. If you resolve that dang log file, where do nearly ALL of the IPs fall? APNIC... ASIA... Just put IP blackholes for all of China and Korea and be done with it already. I used to have 800+ attacks on my box per day, then I woke up and was like, gee, this webserver is only meant to serve people on campus here in texas... why do I need to have it available to the world for? So I blackholed china and korea, most of it at least, about a dozen entries, 202.0.0.1/8 and so on... And the attacks miraculously, stopped.

If you\'re not feeling like typing install some IDS software or better yet have someone who understands networking install a freakin\' ASA or something on your network.

Bottom line, if you don\'t know what you\'re doing learn. Don\'t just cut and paste things off a website and expect to be secure.

ok I\'m done.

~R

@ rob: It\'s just good practice to remove the rules you added, when you\'re done using them.

Especially when automating things and when this is potentially used on so many servers. You cannot afford sloppiness (when other people start using your information).

Black holing Asia sounds like permanently staying indoors to avoid rain. Some people out there might actually need to allow connections from Asia. Some people might prefer an umbrella.

Changing the port could help a lot. There are many ways. I write about one I think hasn\'t been getting enough attention.

I\'ve edited your comment because I do not tolerate curse words on my site.

great post. thanks really needed this! :)

Super nice.

Thanxx in advance

Just a quick comment...I added these rules to my server and they didn\'t seem to work for some reason. So I spent a few minutes trying to figure out why, and it turns out if you use the -A option (add), and these rules are added AFTER an ACCEPT rule for the same port, iptables will ignore the new rules (because they appear after the ACCEPT rule).

To work around it, all you need to do is this:

Use \"iptables -I INPUT [rulenumber] ...\"

where [rulenumber] is the location in your iptables rules list where you want to insert the rule...a little trial and error is required to stick it in the right spot (just before/above the ACCEPT rule for the same port, I suggest), but once you get the right number, you should be fine.

Our community support is the strongest on the planet! Thanks everyone!

@ ThisGuy: Thanks for sharing.

While your block may work fine, I found that simply changing the SSHd port from 22 to an ephemeral port stopped all my SSH brute force attempts. It\'s not as robust but it worked and it\'s much simpler.

This is a good start and nice to see you are thinking about security. I would suggest you take a look into denyhosts (you\'ll find it\'s in Ubuntu\'s repos) as an alternative though.

With what you describe here, you open yourself up for a denial-of-service attack. Someone could lock you out of ssh on your own server by constantly establishing TCP connections on port 22. They don\'t even have to attempt a username/password against ssh - just establish the connection then drop it.

Your rate keeps getting maxed out, which prevents legit connections.

Denyhosts is specific to ssh, but it allows rules along the lines of:

IF x failed authentications on ssh per Y period of time, ban the attacker\'s IP for Z duration

I believe denyhosts uses iptables internally, but it\'s a great solution for what you\'re trying to do here.

@ Craig Fowler: fail2ban is a similar tool that I also refer to in the article. I also explain why I write about the iptables way. You are not correct by the way, this method only blocks the IP that is brute forcing you. Not the entire port.

@ kamikaze.cockroach: That would be security by obscurity and is not at all considered to be good protection, it may also break processes (rsyncs, whatever) that already have been configured to connect to port 22.

I do the throttling thing using iptables with a much higher responsiveness. I allow three attempts an hour or the originating IP address is banned till no attempts are made for 18 consecutive hours. This is based on the rate at which I expect to have to use my firewall. It also prevents a throttled brute force attack and reduced a guys trys to like three total if its automated. The trick is to assume evil and then except for good behavior. The trick it to use a sub-table and -j RETURN.

[CODE=\"bash\"]
########
# Throttle SSH connections by host
# to prevent brute force attacks
########
$IPTABLES --new-chain SSHTHROTTLE
$IPTABLES --flush SSHTHROTTLE
$IPTABLES --append SSHTHROTTLE --match recent --name ssh_throttle --seconds $((3600 * 18)) --update -j DROP
$IPTABLES --append SSHTHROTTLE --match limit --limit 3/hour -j RETURN
$IPTABLES --append SSHTHROTTLE --match recent --name ssh_throttle --set -j DROP
[/CODE]

Forgot a line...

The line below should be included in the bulk of your iptables rules. Of course you should make sure that this port 22 line is before any others relating to that port.

[CODE=\"bash\"]
$IPTABLES -A INPUT -i $EXTIF -p tcp --dport 22 --syn -j SSHTHROTTLE
[/CODE]

@ Robert White: Thanks for sharing. The limits I present are only an example though, everybody should feel free to adjust them to their needs.

@ Derek Johnson: Thanks for your comment. Yes there already are some references to fail2ban and denyhosts as well. Also the changing of ports have been extensively discussed below. Kind regards.

What about killing the sshd service? That\'s what we do. We turn it on when we need it, and once finished we turn it off. No ssh can be connected to if the service is off. We rarely need to login with ssh so it seems to work quite well. In IP tables we also have deny all and allow only our IP address for extra security when we do use it. Seems to be a simple way to secure it instead of going through all that above. Am I right or can it be started remotely? Would like to see that question answered if anyone knows.

Hmm, I think this can be good DDOS protection too.....

@ Doug: Well I work for a company where we remotely control ten of thousands of servers. Shutting down ssh on all of them would mean we have to take the bike and hook up a monitor every time we needed some work done ;) not an option.

Is a hit count of 8 low enough? Or should it be lower?

How can I block a particular IP address for all incoming connections to my server?

Hi:

I love your rules!!! I\'ve installed them on my SuSE to get rid of those nasty script kiddies and they worked great!!!

Moreover, I recently used them to prevent attacks to my website. I am testing the rules right now, but they seem to work fine!!

Keep up the good working.

@ mrwes: that\'s entirely up to you. 8 is just an example. Just the fact that you limit attempts to a small finite amount makes for the biggest protection.
@ Ankit: something like:
[CODE=\"BASH\"]
/sbin/iptables -A INPUT -s x.x.x.x -j DROP
[/CODE]
@ Raul Luna: Thx!

Very useful tutorial! I see what the \'recent\' module is doing now. \"cat /proc/net/ipt_recent/SSH\" shows you the source addresses that are being tracked. So doing that \'cat\' after some test ssh connections really demonstrates the utility of this simple, effective filter. Thanks!

@ Donn Lee: You\'re welcome!

@Kevin: I can see in my auth.log file that the most of the brute force attacks are using the username root. Will the iptables ban the root user?

Hi,

I have one script that depends on the conditions make some N amount of SSH connections to the server.

If I just use example that was brought earlier the script will be banned sometime.

Is it possible to use ssh-brute-force iptables rules but with user exception? That user \"John\" can make any amount of connections?

Thanks.

@ S2m: Well if you know John\'s static IP you could allow the traffic. Otherwise you\'re blocking on a level to low, cause iptables won\'t read the packets to see who\'s who.

Debian \'lenny\' doesn\'t like the \'-m state --state NEW\' option, error message:

iptables: No chain/target/match by that name

@ John G.: Can you show me your full command?

@ John G.

Make sure you got the \"recent\" module enabled in the kernel. (in the netfilter tree) I had the same problem.

@Kevin : Thnx for sharing... didn\'t know

@ Jerry: No thank You for sharing ; )

Hello,
Why not use the command \"service iptables save\" to save the config, instead of the if-up.d and if-down.d config files ?

Rami

Very nice! I prefer to stay closer to the metal and iptables will enable me to directly tighten things.

@ Ramito: That\'s redhat/centos/whitebox/unbreakable linux. I mostly base my posts on debian/ubuntu, and leave it up to the readers to make changes necessary for their own distro.

Brilliant! Worked perfectly. For ubuntu, just add the following two lines to /etc/iptables.up.rules

-A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

-A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

(i.e., same as your steps above just in config format rather than as commands)

Thanks again for this great tip!

Ok first, your solution is great. But, I think I like my fix better.

I simply deny all ips from access via SSH on my server, and I don\'t even allow FTP.

You can\'t hack what you can\'t touch.

Thanks a lot, it helped me making my server more secure AND fix a problem I had previously.

I talked about it more on:
http://www.linuxquestions.o...

@ daniel: I don\'t think that\'s default Ubuntu/Debian behavior, is it?. You would still have to call something like
[CODE=\"bash\"]
nano /etc/network/if-pre-up.d/iptables
[/CODE]

and add
[CODE=\"bash\"]
#!/bin/bash
/sbin/iptables-restore < /etc/iptables.up.rules
[/CODE]

@ Foam Roofing: That works great if your server is located in your basement, yes.

@ Steven: Cool!

it is very nice and can u plz help me to create new command in ubuntu using c

Thanks for sharing, Kevin.
I didn\'t know iptables can do that. LOL. Cool.

Excellent! Especially the scripts in if-up.d! You have visibly a good understanding of the OS.

@ aravind: What?

@ Fajar Priyanto: Yeah pretty nice eh? : )

@ Pascal: All credits go to iptables. Powerrr.

Nice idea, but with my Ubuntu 10.4 TLS this jammes the whole network connection. Even the router doesn\'t see the machine anymore. Luckily this server is on my living room so i managed to flush iptables by attaching keyboard and a monitor to the machine. I copy/pasted those two lines of code so no idea what went wrong, so many seems to have got it working..

I tested it again without all the other ssh rules i had before and same thing happened, so there\'s no conflict with other rules. I only had rules for allowing established connections to receive traffic, allowing incoming web traffic and final rule for dropping everything else which isn\'t accepted before that..

How can I see what IP\'s are currently blocked?

In absence of flushing the tables, how long do the bans last?

FYI, on RHEL/CentOS one can simply add the following lines before their ssh rule:

-A RH-Firewall-1-INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

-A RH-Firewall-1-INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

@ Reino: Strange I haven\'t had issues with Lucid yet. Always put iptables -F in your crontab when playing with new rules tho.

@ Rian Inso: It\'s not a real ban as in it allows you to only make a fixed number of requests per timeframe you specify. So after that you\'re good to go.

Well i tried again and now these rules work, thanks very much! No idea what was the problem first time. I also missed that crontab hint when first tried it, i\'ll be wiser next time 8) Linux is quite a new thing to me but it seems that now i\'ve got all the necessary security precautions to run ssh and web servers.

Is there anyone that you know of that can set this up for me via Logme in connection to do the work? I sort of understand it but too afraid to screw something up in the process.

Thanks

Whenever I try to run these rules, I just get an error message "Unknown error 4294967295" My server runs Plesk, so maybe that's the issue (ha!). Any ideas?

Thanks so much for all of your fantastic articles :)

@ Malcolm: Try your hosting company. If it won't help you, find a better one. Suggestion: true.nl (but I'm biased : )

@ Michael: Thanks for the kind words. Doesn't make any sense to me. I assume you've googled?
If you can't find errors (in console, dmesg, syslog, etc) you could try prepending your command with strace. It will show you the lowerlevel C commands being executed and may give you a better idea of where it breaks.

I really liked the way you organized this article.Setting up crontab to flush the entries was a good tip.
I use a lot of such methods not only to prevent brute force attacks but to load balance the servers/

Great article, easy to follow and implement. Now I feel a bit safer. Thanks!

Thank you.. rly interesting rule :-)

Hi,

good article. By the way, I would recommend fail2ban tool, which does the same thing automatically, and moreover not only for ssh, but also for apache, sendmail and others.

have a look: http://www.fail2ban.org/wik...

/Regards,
Alexander

ups, sorry, skipped a part of the article, and did see that you stated the fail2ban tool :)

I'm currently under a DOS attack where the attacker is sending tens of thousands of udp packets per second to a service running on a specific port. He's using spoofed source addresses for each packet. I need to allow up to 4000 connections per second, so I tried:

iptables -I INPUT -p udp --dport 27015:27017 -m state --state NEW -m recent --set
iptables -A INPUT -p udp --dport 27015:27017 -m state --state NEW -m recent --update --seconds 1 --hitcount 3000 -j REJECT

I get this error:
iptables: Unknown error 18446744073709551615

Any ideas?

A very good article. Thanks.

Kevin, great article.

I see that you wrote it back in 2007.

Today I found by the hardest way you can imagine :(( that the cron failsafe method does not work (anymore??) in CentOs and Fedora, either using "iptables -F" or "service iptables stop".

The way to do it in crontab seems to be /etc/init.d/iptables stop

Anyway, testing is the key.

great article
thanks so much
I sure hope it works
I miss being able to use the internet

Thanks, this was really useful :)

Thanks. I looked quite a while for a simpel solution! It work's fine!

[CODE="Javascript"]
window.location='http://www.fj-web.dk/fobber...
[/code]

Errr, I forgot my INPUT chain defaults to DROP, so flushing my rules immediately locked me out. Heh!

Might wanna append the example cron job :)
[code="text"]
*/10 * * * * /sbin/iptables -F; /sbin/iptables -P INPUT ACCEPT
[/code]

They can be a very secure World-wide-web best within individuals while concerning operating.

ohio i've a how does someone you can get awesome and as well unsmoked Poker No Deposit Bonus 2012 poker no deposit bonus 2012

I tried this tutorial on Debian 6, I setup 1 every 60 seconds, then I tried 3 wrong password and after that on fourth try I typed in the correct password and i was in, within 60 seconds.