This is how I protect against brute force/DoS attacks... It might not be
the best but I use it because it's effective and is handled at the
kernel level. A lot of folks use fail-to-ban to block brute forcers but
I use iptables and ipset to rate-limit them.
I create an ipset that I call hackers and then I rate-limit attempts to
connect... too many attempts in the window (1 hour on my systems) and
they go in the blacklist.
To implement it you have to define an IP set and then tell netfilter
what to do with addresses matching the set... Here's how I set it up and
how I handle stuff on the blacklist for my SSH port:
ipset -N hackers iphash timeout 21600
iptables -A INPUT -i $RED -p tcp --dport 22 -m set --match-set hackers
src -j SET --add-set hackers src --exist
iptables -A INPUT -i $RED -p tcp -m set --match-set hackers src -j
REJECT --reject-with tcp-reset
iptables -A INPUT -i $RED -m set --match-set hackers src -j DROP
Note: each command is a single line. Email may break them into multiple
lines, I've put blank lines between the commands to make it easy to
delineate one command from the next...
The first command creates a set called hacker with a timeout of 6 hours.
Any ip added to the list come off in 6 hours. Works great because
only the very active attackers will stay on the list.
The second command matches ips already on the list. If they're already
on it it resets their timeout back to 21600 seconds (6 hours)
The third command resets TCP connections for ANY tcp attempt for IPs on
the list
Th 4th command drops connectionless traffic like UDP or icmp from IPs on
the list.
So how do they get on the list? Further down in my script where I have
the allow input traffic to the machine in the interface I have the
magic. The following is for my external internet facing interface for
inbound SSH traffic on my gateway called RED ($RED in the script) (5
iptables commands):
iptables -A INPUT -i $RED -p tcp --dport 22 -m state --state NEW -m
recent --set --name SSH --rsource
iptables -A INPUT -i $RED -p tcp --dport 22 -m recent --update --seconds
3600 --hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix
"AutoBlacklist: RED SSH Hackers"
iptables -A INPUT -i $RED -p tcp --dport 22 -m recent --update --seconds
3600 --hitcount 4 --rttl --name SSH --rsource -j SET --add-set hackers src
iptables -A INPUT -i $RED -p tcp --dport 22 -m recent --update --seconds
3600 --hitcount 4 --rttl --name --rsource -j REJECT --reject-with tcp-reset
iptables -A INPUT -i $RED -p tcp --dport 22 -j ACCEPT
If I get 4 connections from any IP they go in the blacklist. I send
them tcp resets to make them go away and so upstream routers like AMPR
GW don't have to keep track of the connection.
The first command starts up the recent module
The second command logs the connection attempt on the 4th attempt
The third command adds the offending ip to the hackers IPSET list on the
4th attempt
The fourth command sends a TCP-RESET on the 4th attempt
The fifth command accepts their connection if it hasn't been reset by
rule 4 (i.e the 1st, 2nd, or 3rd attempt)
The beauty of this over Fail-to-ban is there isn't a daemon monitoring
the log, it works on connection attempt at the netfilter/kernel level
and it's very effective. If you put this on your gateway (or any
server) protecting the particular port you're interested in protecting
it's very effective at preventing Brute Force/DoS attacks.
I hope someone finds this useful... I wrote a little about it in the
past... if you google "self blocking script kiddies" you'll find an
older iteration of this on my wordpress blog...
Tom Cardinal/N2XU/MSgt USAF (Ret)/BSCS/CASP, Security+ ce
On 6/8/2017 12:39, G1FEF via 44Net wrote:
The FTP server is back up again now, I had to shut it
down for a while as it was getting brute force attacked from several hundred different
IP’s.
Chris
On 8 Jun 2017, at 16:39, Brian Kantor
<Brian(a)UCSD.Edu> wrote:
Some sudden unexpected changes with the encap file:
Chris has had to shut down the FTP server on the portal.
I've built a program to now extract the data that
was in the encap file from the database itself.
I've had to reconstruct the format of the file. The differences are:
1) You now fetch the encap file from the private gateways area
of the
gw.ampr.org website (use wget)
2) The date format is now 'yyyy-mm-dd UTC' instead of yyyy/mm/dd
3) The version number in the header is now 00.000 and doesn't change
4) Subnet addresses are always presented as a full decimal quad.
(eg, '44.60.44.0/24' instead of '44.60.44/24'
5) There is '# END (n rows from db)' at the end of the file
6) The file is now in sorted order by subnet
7) The file and routes are updated every 15 minutes
Even with these changes, the file should load into old software OK.
By the way, in the process I discovered that the following 14 subnets
are routed but don't have their 'Tunnel' box checked in the portal.
- Brian
[109]: 44.46.64.0/24: 104.131.81.118
[117]: 44.48.8.0/22: 96.82.54.108
[194]: 44.94.0.0/16: 141.224.128.8
[267]: 44.131.156.0/30: 82.0.212.67
[392]: 44.136.72.0/22: 220.233.86.207
[396]: 44.136.92.0/24: 220.233.86.207
[437]: 44.142.0.0/16: 141.75.245.225
[454]: 44.151.17.10/32: 89.95.154.240
[453]: 44.151.6.9/32: 109.234.161.28
[486]: 44.152.0.0/16: 201.211.91.93
[532]: 44.163.144.0/20: 141.75.245.225
[568]: 44.168.254.80/29: 90.63.239.151
[614]: 44.188.128.0/20: 188.93.56.29
[617]: 44.208.0.0/16: 94.101.48.134
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net