i'm trying to figure out were to put iptables rules to slow down ssh brute force attacks.

these are the rules which work on my server but i want to put them on the router:

iptables -A input_wan -p tcp -m tcp --dport 22 -m recent --name SSH --update --seconds 300 --hitcount 1  -j TARPIT
iptables -A input_wan -p tcp -m tcp --dport 22 -m recent --name SSH --set -m state --state NEW

unfortunately thy never fire, so i guess input_wan is not the chain. has anybody done it and would like to share how?

thanks.

please dont mix  UCI and non-UCI configuration!
Either do everything according to  http://wiki.openwrt.org/doc/uci/firewall OR according to http://wiki.openwrt.org/doc/howto/netfilter  !

Especially this example here:  http://wiki.openwrt.org/doc/howto/netfi … s.example1  is placed in /etc/firewall.user and deletes everything ever set by UCI. You have to do everything from scratch and this includes defining user chains. I do that, thus I dont know the UCI configuration at all.

Iptables gives out no problems? German: Fehlerausgabe.

A technique to catch misconfigurations is to log stuff:
$IPT -A INPUT_funk -j LOG       --log-prefix "IPT_funk-Rej "
$IPT -A INPUT -j REJECT    --reject-with icmp-host-prohibited

With "logread -f" you can look at the logs as they get sent.

Why not?

What's the point in flushing everything and rebuild the ruleset? Sticking custom rules into the existing ruleset is perfectly fine, one just has to choose the appropriate chains.

pharaoh:
In current versions, "input_wan" follows other uci rules, if you have e.g. an entry like

config rule
  option src wan
  option proto tcp
  option dport 22
  option target ACCEPT

... it will catch all port 22 traffic so packets never traverse the "input_wan" chain.
One possible solution is to stick your recent rules into the "zone_wan" chain like this:

iptables -I zone_wan -p tcp -m tcp --dport 22 -m recent --name SSH --update --seconds 300 --hitcount 1  -j TARPIT
iptables -I zone_wan -p tcp -m tcp --dport 22 -m recent --name SSH --set -m state --state NEW

Alternatively directly into the INPUT chain:

iptables -I INPUT -p tcp -m tcp --dport 22 -m recent --name SSH --update --seconds 300 --hitcount 1  -j TARPIT
iptables -I INPUT -p tcp -m tcp --dport 22 -m recent --name SSH --set -m state --state NEW

Technically it's fine doing so, I know, the downside it, that you (at least me) do not know, your configuration.

I dont know the custom chains created by the UCI firewall! (Yeah, iptables -L would show them, because they were not in the firewall-file)
Instead of looking for them, I simply created my own rule set, and
1. everything is in one file.
2. everything has the same layout => If you connect with WinSCP, you can use gvim + http://www.vim.org/scripts/script.php?script_id=1425 and things look much more colorful.

Sorry, but if you do not know about the uci firewall then do not comment on it.
If you're going to push the idea of custom rulesets here then at least provide somewhat secure examples - the one from the wiki is insecure, not portable and lacks IPv6 coverage. Especially in the context of the initial question its a joke, instead of locking down his SSH port, pharaoh would open everything, including HTTP, Telnet, DNS etc. when implementing the suggested wiki rules.

I don't know, what kind of firewall he uses! Probably UCI +  firewall.user. And I do think, I guessed the right cause for the problem!

It's meant as a clean sheet! Upon which to build an own rule set! Which then should render questions regarding customs chains obsolete. Obviously he knows about the usage of iptables, the only problem is the rule-set itself. Custom chains are being created, and the packets are put into them, and then...

For me, UCI firewall is completely "unübersichtlich". I stopped using it after 1 week. gvim with syntax highlighting is just the way to go. For me.

easy jungs, no need to argue

i like the idea to let UCI generate all the "boring" stuff and add some special cases in firewall.user. you can of course write your own set of firewall rules if you want, that's the advantage of an open system. for building your own set i recommend firewallbuilder.org, great tool and it knows openwrt vim is the other alternative

back to topic: i solved the problem, was my own stupid mistake. i put the rules in the wrong chain, i should've used FORWARD because the port will be forwarded to the internal lan.

this works:

iptables -N ssh_flood
iptables -A ssh_flood -p tcp -m recent --name SSH --update --seconds 300 --hitcount 1 -j TARPIT
iptables -A ssh_flood -p tcp -m recent --name SSH --set -m state --state NEW
iptables -I zone_wan_forward -p tcp -m tcp --dport 22 -j ssh_flood

one thing i dislike is the way Luci organizes the rules if you have dualstack. ipv6 for instance has icmp packet-too-big with no counter-part in ipv4.  i think two separate rule sections would be better, so that every section can provide specific options for ipv4 or ipv6. but that's just my personal taste.

thanks to both of you.

-p

(Last edited by pharaoh on 13 Aug 2011, 21:00)

Actually I don't push the idea. I merely presented a workaround. And I did that, because I didn't expect anybody else to answer promptly.