Hi Brian, OK , in this moment it is: # Current version: 00.000 2017-06-08 15:30:05 UTC .... .... # END (xxx rows from db) very good! I'll test soon... Strange things happened last night here, see the rrdtool report at: http://44.134.32.240/pastday.png RIP spoofing? Real or false 44 user bombed my GW, too. 73, gus

Something odd is happening... try in this other way: http://i0ojj.mooo.com/pastday.png gus On 06/08/2017 06:34 PM, Brian Kantor 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

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: