Yes, it's subsided quite a bit. The amprgw machine is only spending less than 15% of its processor time filtering packets, vs over 25% earlier and on the weekend. Perhaps posting my filter script/program was another fine example of closing the barn door after the horse has bolted.
Well it may come back anytime of course... The strange thing is that I see no peak at all in the traffic graphs made over the past days and weeks, and there have been much higher peaks in the past. But maybe you just were not looking at that time... (a couple of weeks we also experienced a DDoS attack that had several orders of magnitude more traffic)
I have done some tracing in the past to identify the most obvious problems and I can understand that you become more and more worried when studying the problem. As you well know, it consists of both attempts to hack the systems and of backscatter from attempts to attack others using spoofed source addresses.
Just now, it took 287 seconds to gather 100 million packets, comprising 7100 different source addresses. This is rather more than usual. The blocking table now contains 18,000 entries.
I have a static blocking table that has the addresses of shodan.io and other miscreants of this world, and the "research institutes" that consider it research to scan other people's networks to map out vulnerabilities etc. That includes 169.228.66.91 and 169.228.66.138 but there are lots of others so no need to get worried. I do not bother to block the scattered Chinese addresses that do only telnet scanning, for that purpose I have put a rate limiter in the firewall that limits the number of unanswered SYN requests per source address using the "recent" matching module of iptables.
Rob
On Wed, May 10, 2017 at 11:42:27PM +0200, Rob Janssen wrote:
I have a static blocking table that has the addresses of shodan.io and other miscreants of this world, and the "research institutes" that consider it research to scan other people's networks to map out vulnerabilities etc. That includes 169.228.66.91 and 169.228.66.138 but there are lots of others so no need to get worried.
Well, yes, I find the first of those two machines you list to be professionally somewhat embarrasing, as I'm the sysadmin for it. I'm informed that the research they're doing was approved by the relevant review groups, and that upon request they'll block probes to your addresses, but I'm still not very happy about it. The second one runs a wall display in the department, it shouldn't be probing anything. It's a reassigned machine, so perhaps a previous user of that machine was doing some research scanning too. Sorry about that. - Brian
Rob et all,
I'll work on making my traffic available to you if anyone's interested. As I mentioned and as we chatted, I stopped blocking individual addresses long ago. I use port scanning iptables rules, etc. I mainly have rules for open ports.
I'm more concerned about my inability to block traffic on the WAN-facing side of my tunl0 at this time.
I'm working on an experiment to see if my firewall rules are working, as it's not blocking traffic whatsoever (from what I can determine). The firewall rule/script on the Wiki developed which only allows Portal gateways - IS NO LONGER WORKING. I'm starting to prefer the ampr-ripd that listens on udp/520 (as opposed to listening to IPENCAP Protocol 4 on the WAN-facing side) , from what I can see...
Procedure:
- Make tunl0 on a host on a PC on my LAN again - only place routes to a device in my LAN setup to receive routes - address tunl0 as 44.0.0.1 - send to default RIP router multicast address - see if it accepts routes
WHY 44.0.0.1?!?!:
- I earlier used ampr-ripd, it doesn't seem to accept routes from another ampr-ripd device, proper (I told someone earlier this week to use the -f and -e arguments, but they are NON-FUNCTIONAL). I assume from the code I've reviewed, that ampr-ripd is somehow "locked" to 44.0.0.1.
73,
- KB3BWG Lynwood
- Ampr-ripd (and amprd) accept only routes from 44.0.0.1, so that spoofing should be less probably.
- The -f and -e options rebroadcast standard RIPv2, not ampr-style RIP. They can be used to send routes to a second router using the first as a gateway. The second router needs to run a standard RIP daemon, like quagga.
- And to some earlier statements: ampr-ripd never listened to protocol 4, only to udp/520, starting with its first version.
Marius, YO2LOJ
On 2017-05-11 03:02, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob et all,
I'll work on making my traffic available to you if anyone's interested. As I mentioned and as we chatted, I stopped blocking individual addresses long ago. I use port scanning iptables rules, etc. I mainly have rules for open ports.
I'm more concerned about my inability to block traffic on the WAN-facing side of my tunl0 at this time.
I'm working on an experiment to see if my firewall rules are working, as it's not blocking traffic whatsoever (from what I can determine). The firewall rule/script on the Wiki developed which only allows Portal gateways - IS NO LONGER WORKING. I'm starting to prefer the ampr-ripd that listens on udp/520 (as opposed to listening to IPENCAP Protocol 4 on the WAN-facing side) , from what I can see...
Procedure:
- Make tunl0 on a host on a PC on my LAN again
- only place routes to a device in my LAN setup to receive routes
- address tunl0 as 44.0.0.1
- send to default RIP router multicast address
- see if it accepts routes
WHY 44.0.0.1?!?!:
- I earlier used ampr-ripd, it doesn't seem to accept routes from
another ampr-ripd device, proper (I told someone earlier this week to use the -f and -e arguments, but they are NON-FUNCTIONAL). I assume from the code I've reviewed, that ampr-ripd is somehow "locked" to 44.0.0.1.
73,
- KB3BWG
Lynwood _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-
Brian Kantor -
lleachii＠aol.com -
Marius Petrescu -
Rob Janssen