Hi Brian,

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.

OK , in this moment it is:

# Current version: 00.000 2017-06-08 15:30:05 UTC .... ....

5. There is '# END (n rows from db)' at the end of the file

# END (xxx rows from db)

6. The file is now in sorted order by subnet
7. The file and routes are updated every 15 minutes

very good!

Even with these changes, the file should load into old software OK.

I'll test soon...

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.

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:

Sorry Gus, could not connect to that address from my home.

• Brian

On Thu, Jun 08, 2017 at 06:29:05PM +0200, Gustavo Ponza wrote:

...

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

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net