In the past there have been complaints of some RIP44 packets not
reaching their destination, enough so that routes sometimes
vanish from the RIP44 table on the receiver. Although there is
currently little I can do about packet loss on the network,
I have slowed down the rip sender by 100 microseconds per sent
packet to avoid saturating buffers on busy networking equipment
and thereby avoid causing possible congestion loss. This means
that it now takes a little over a second to send the complete set
of (currently) 26 RIP44 packets to each of (currently) 435 gateways.
I don't know if this was the cause nor whether this will help,
but it's a cheap fix and it may help. Slightly slower packet
delivery shouldn't negatively affect anyone.
RIP44 transmissions are still sent every five minutes.
- Brian
On May 1st, Intel released a security advisory regarding their Active
Management Technology. It's a nasty one, but luckily it doesn't seem
to affect home (non-datacenter) PC firmware.
> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&lang…
Intel has released a mitigation guide:
> https://downloadcenter.intel.com/download/26754
Security researchers have since been able to uncover more details and
release proof-of-concept exploit code. There is now a free nmap .nse
plugin available to scan for this vulnerability:
> https://nmap.org/nsedoc/scripts/http-vuln-cve2017-5689.html
To help prevent this from affecting AMPRNet systems, I am now blocking
inbound port 16992 at the amprgw gateway. I hope this won't cause you
any difficulties.
- Brian
> I've been curious how many of the 435 registered gateways were reachable,
> so I collected ICMP unreachable messages during a recent RIP transmission
> (which of course sends to every gateway) and got the following:
> 33 gateways aren't reachable or are rejecting inbound IPIP packets
I think it would be a good idea to somehow keep track of this information and remove
or at least mark inactive those gateways for which this condition persists
for some amount of time. Especially when protocol 4 is rejected.
Host unreachable could be because the internet is down or the power is out,
but an explicit protocol 4 rejected indicates nonexistent configuration, that
could temporarily exist because e.g. new system has just been installed that has
not been configured yet, but should not persist for longer than say 2 weeks.
The operator can alwayes re-enable or re-add the gateway when he has found the
opportunity to re-install it.
Rob
Hello everyone!
Does anyone have any experience setting up VyOS for use on the AMPR
network? I have the IPIP tunnel to UCSD set up, however, I don't know how
to proceed from there in terms of RIP.
This is what I did so far:
set interfaces tunnel tun0
set interfaces tunnel tun0 local-ip 'wanip'
set interfaces tunnel tun0 remote-ip 169.228.66.251
set interfaces tunnel tun0 encap ipip
set interfaces tunnel tun0 descr "Tunnel to AMPR Gateway"
set interfaces tunnel tun0 multicast enable
set protocols static table 1 interface-route 0.0.0.0/0 next-hop-interface
tun0
set policy route SOURCE_ROUTE rule 10 set table 1
set policy route SOURCE_ROUTE rule 10 source address 44.0.0.0/16
set interfaces ethernet eth1 vif 44 policy route SOURCE_ROUTE
set protocols rip interface eth1.44
set interfaces ethernet eth1 vif 44 ip rip authentication
plaintext-password [therippass]
--
Miguel Rodriguez
12th Grade Student
MIGUELR-DN42 / KM4VYU
miguemely101(a)gmail.com
Tel: *561-758-0631*
*Accredited District Since 2008; Re-certification - January 2013*
Home of Florida's first LEED Gold Certified School
*Disclaimer*: Under Florida law, e-mail addresses are *public records*. If
you do not want your e-mail address released in response to a public
records request, do not send electronic mail to this entity. Instead,
contact this office by phone or in writing.
All,
I need to ask if any of the following have been noticed or by anyone before.
As I try to test a few things today, I:
- cannot forward IPENCAP traffic to another LAN destination while
running ampr-ripd 1.16 on my router
- cannot block IPENCAP traffic whatsoever at my WAN while running
ampr-ripd 1.16 on my router
- cannot block receipt of RIP44 packets from AMPRGW running ampr-ripd
1.16 on my router
Procedure:
When setting up LEDE:
-I observed that I no longer had firewall hits for RIP44 from AMPRGW
- I removed the rule, and I still receive routes
Testing receipt of MACs on tunl0 today:
- I removed my rule allowing -p 4 from the IPSET of our GW IPs
- I made a port forward rule for -p 4 to a LAN machine I setup with a
tunl0 of 44.60.44.2
- I set up routes to use tunl0
- I pinged
- Using Wireshark I never received traffic
- My router saw no hits
- I connected to http://44.60.44.10 to perform a traceroute to 8.8.8.8
- It still worked, even though I have no firewall rule!
- the device is still in this configuration
- and I noticed one 'leaked' packet that never made it to my test tunl0
interface
- I notice that ampr-ripd 1.16 listens on protocol 4 instead of udp/520
as version 1.13 did
BUG:
It appears my firewall rules regarding IPENCAP/A.K.A. 'dev tunl0'
packets - after upgrading from 1.13 to 1.16 are infective.
Need to test:
- If I configure a valid 44 IP on my router's tunl0, I assume ALL
iptables rules for it COULD POSSIBLY be ineffective (since the RIP44
rule is)
- If I can send routes in this configuration
- If I can receive routes from someone else (with correct PW, of course)
- If I receive IPENCAP packets from a non GW (since I have no method of
it blocking, except if it exists ampr-ripd.c). Note - I'm not requesting
this feature
I will test later today.
- Lynwood
KB3VWG
> 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
> 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.
At the time I put it on the list it had the reverse DNS ipsecscanner.sysnet.ucsd.edu
and that is what it was doing. I removed it now. A problem of my method of blocking
is that I cannot keep stats of activity of the address, so addresses may remain on the
list far too long.
But again, there are enough other entries for "research" from several other US and
German universities. It appears to be a popular way of annoying people.
Of course the interesting thing about the UCSD ones was that the traffic came through
the tunnel even though our network is BGP routed. Not sure if it is still like that, I believe
you changed something there.
Several scanners offer opt-out but I think the research is mainly to see what people do
when removal is promised but not done or only very temporarily. For example, I
contacted the shodan.io guy twice for removal from his scanner, both times he removed
our network only to re-add it within days. He probably expects that you will check after
he answered the mail, see it is gone, and then not pay attention to it so he can continue
his abuse.
Rob
> The DDoS attack on net 44 continues. I'm filtering out a goodly amount
> of it at amprgw, but the people whose subnets are directly connected (BGP
> announced) are getting hit too, and there's nothing I can do to filter it
> out here.
Our traffic is not particularly high here, of course there is a few Mbit/s of noise
but it has been higher at times.
Rob
