Failing to block brute force ssh with iptables

Question

I'm trying to block (slow down) brute force attacks on my sshd server. I'm following this guide http://www.rackaid.com/resources/how-to-block-ssh-brute-force-attacks/ which basically says I need to just enter the 2 commands below.

sudo iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set sudo iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

My sshd port is 6622, so I changed the entries from "22" to "6622", and put those commands in. Then I attempted to simply test the new iptables. I went to another pc and purposefully put in the wrong login password several times. Unfortunately, the new rules don't seem to be stopping me from trying as much as I want. Listed below are my current rules. What am I doing wrong?

# iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination DROP tcp -- anywhere anywhere tcp dpt:6622 state NEW recent: UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source tcp -- anywhere anywhere tcp dpt:6622 state NEW recent: SET name: DEFAULT side: source Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain LOGDROP (0 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning DROP all -- anywhere anywhere

I recommend fail2ban to handle blocking IPs that are showing brute force attempts. It's easy to install and configure. I know it doesn't answer your question directly, but it might save you a few holes in the drywall. — Banjer
– Banjer, Commented Oct 15, 2013 at 1:17
Concur with @Banjer -- forget that rackaid link, set up fail2ban. — Shadur-don't-feed-the-AI
– Shadur-don't-feed-the-AI, Commented Oct 15, 2013 at 6:53
Any chance tweaking MaxStartups might help on the daemon side? — peterph
– peterph, Commented Oct 15, 2013 at 7:18
@peterph Only if you want to turn a brute force breakin attempt into a denial of service. — Shadur-don't-feed-the-AI
– Shadur-don't-feed-the-AI, Commented Oct 15, 2013 at 9:47
Why expose an ssh server to the Internet, and then try to minimize the consequences? Either at work or at home, I go in via ipsec VPNs, no ssh open to the Internet at all. — Rui F Ribeiro
– Rui F Ribeiro, Commented Feb 15, 2016 at 13:16

Shadur-don't-feed-the-AI · Accepted Answer · 2013-10-15 09:50:22Z

As @banjer pointed out in his comment, you're trying the wrong solution for your actual problem.

What you need to do is set up fail2ban. It uses iptables in the background to automatically block connection attempts from hosts that generate failed access attempts from various sources. It's incredibly versatile and lets you add and modify different tresholds, patterns to look for and banning methods; you'll have to tweak its default ssh jail slightly to account for the nonstandard port you're using but that shouldn't be hard.

slm · Accepted Answer · 2013-10-15 02:20:15Z

I use rules like this to slow things down:

iptables -A DDoS -m limit --limit 12/s --limit-burst 24 -j RETURN iptables -A DDoS -j LOG --log-prefix "[DDos Attack?] " iptables -A DDoS -j DROP

In other places I limit things like this:

LOGLIMIT="50/h" LOGLIMITBURST="10" iptables -A IANA -p tcp -m limit --limit $LOGLIMIT --limit-burst \ $LOGLIMITBURST -j DROP

perpetuity · Accepted Answer · 2013-10-15 07:06:43Z

Did you read man page?

man sshd_config:

 MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6. MaxSessions Specifies the maximum number of open sessions permitted per network connection. The default is 10. MaxStartups Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10:30:100. Alternatively, random early drop can be enabled by specifying the three colon separated values “start:rate:full” (e.g. "10:30:60"). sshd(8) will refuse connection attempts with a probability of “rate/100” (30%) if there are currently “start” (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches “full” (60).

Doesn't help. SSH bruteforce attacks tend to be used by distributed bot networks nowadays, so each connection would make only three or four attempts, but you'd have hundreds of connections from different hosts. — Shadur-don't-feed-the-AI
– Shadur-don't-feed-the-AI, Commented Oct 15, 2013 at 9:47

Raphael Ahrens · Accepted Answer · 2013-12-23 08:58:15Z

I just tried the two rules solution and I had the same issue when I checked it. Then, I remark that published rules have -i eth0 option ! I changed it to the good network interface and it finally started to work.

stark · Accepted Answer · 2016-02-15 12:22:13Z

Most tutorials use -A to append to end of ruleset. OP used -I to insert but without an index, so the rules ended up in the wrong order.

A valuable tool for debugging iptables rules is iptables -vL which lists the rules with counts of how many times each rule has been applied. When you get an unexpected count of 0 it can help you see what's wrong.

Stack Exchange Network

Failing to block brute force ssh with iptables

5 Answers 5

You must log in to answer this question.

Hot Network Questions

Failing to block brute force ssh with iptables

5 Answers 5

You must log in to answer this question.

Related

Hot Network Questions