10 May
2017
10 May
'17
4:42 p.m.
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
10 May
10 May
5:37 p.m.
New subject: storm blocking
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
7:02 p.m.
New subject: storm blocking
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
11:39 p.m.
New subject: storm blocking
- 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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
2754
days inactive
2755
days old
3 comments
4 participants
participants (4)
-
Brian Kantor -
lleachii＠aol.com -
Marius Petrescu -
Rob Janssen