44net

44net@mailman.ampr.org

3198 discussions

router stats
by Brian Kantor 13 May '17

13 May '17

I know that very few of you are looking at the amprgw router statistics, but for those who do care: the current statistics (packet/byte counts) accumulate since router boot time. Would it be more helpful/meaningful if the totals reset at midnight so that they reflect daily trends? Also, some of the numbers are getting large enough that they're not intuitively meaningful. There's no convenient way to insert thousands separators. Would 'scientific notation' (eg, 1.56e9) be helpful? (This is the 'g' format specifier in 'C'.) Or alternatively, notation such as 1.5k, 2.4M, 8.1G, or 1.2T could possibly be generated. - Brian

4 13

Re: [44net] the current worldwide Windows ransomware situation
by Rob Janssen 13 May '17

13 May '17

> Patches are often applied late because it's not rare to experience serious disruption. > Anyway the software being patched is poorly made in the first place. > The problems caused by patches are actually another sign of very poor software design. And not the least: after 25 years of development on Windows the patching mechanism still is in a sad state, requiring unreasonable time and resources to find and install required patches. It is very clear that quality isn't a priority for Microsoft *at all*. They only care about making money, what happens to their customers and how much time they waste on using and maintaining their products does not matter to them as long as they keep buying. Rob

1 0

Re: [44net] Critical vulnerability in Intel Active Management Technology (CVE2017-5689)]
by Rob Janssen 12 May '17

12 May '17

> 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. Thanks for the hint. It is surprisingly difficult to get technical information from the Intel documents. Do you block TCP only or also UDP? And what about ports 16993 and 16994? (and maybe even 623 and 664?) The nice thing about such new vulnerabilities is that they allow you to identify the aforementioned scanners and put them on the permanent blacklist. Aside from shodan.io (that were already on the blocklist) I also see 52.174.52.33 census01.project-magellan.com Yet another annoying "research" project... You could try to get 44.0.0.0/8 opted out via research(a)project-magellan.com Rob

2 2

RIP44 send speed
by Brian Kantor 12 May '17

12 May '17

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

1 0

Critical vulnerability in Intel Active Management Technology (CVE2017-5689)]
by Brian Kantor 12 May '17

12 May '17

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

1 0

Re: [44net] unreachable gateways
by Rob Janssen 11 May '17

11 May '17

> 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

3 3

AMPR + VyOS
by Miguel Rodriguez 11 May '17

11 May '17

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.

4 12

Odd Features/Bug? ampr-ripd
by lleachii＠aol.com 11 May '17

11 May '17

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

2 7

unreachable gateways
by Brian Kantor 11 May '17

11 May '17

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. So if any of the following gateways have been wondering why they weren't getting any AMPRNet traffic, this may be why. - Brian ICMP 24.247.95.42 protocol 4 unreachable ICMP 40.143.112.188 protocol 4 unreachable ICMP 54.146.4.133 protocol 4 unreachable ICMP 71.226.154.52 protocol 4 unreachable ICMP 73.227.91.174 protocol 4 unreachable ICMP 73.229.62.200 protocol 4 unreachable ICMP 75.145.123.237 protocol 4 unreachable ICMP 81.99.51.155 protocol 4 unreachable ICMP 96.82.54.108 protocol 4 unreachable ICMP 97.84.0.85 protocol 4 unreachable ICMP 104.236.122.16 protocol 4 unreachable ICMP 107.150.38.138 protocol 4 unreachable ICMP 107.172.42.138 protocol 4 unreachable ICMP 107.223.221.1 protocol 4 unreachable ICMP 158.69.169.207 protocol 4 unreachable ICMP 159.203.42.8 protocol 4 unreachable ICMP 162.157.83.249 protocol 4 unreachable ICMP 172.114.102.251 protocol 4 unreachable ICMP 172.90.97.192 protocol 4 unreachable ICMP 177.131.213.13 protocol 4 unreachable ICMP 185.10.249.21 protocol 4 unreachable ICMP 189.27.214.32 protocol 4 unreachable ICMP 195.187.71.116 protocol 4 unreachable ICMP 205.171.203.226 protocol 4 unreachable ICMP host 69.181.181.170 unreachable ICMP host 73.146.173.214 unreachable ICMP host 78.236.231.196 unreachable ICMP host 104.131.81.118 unreachable - admin prohibited ICMP host 104.5.53.79 unreachable ICMP host 179.190.230.27 unreachable ICMP host 188.230.236.122 unreachable ICMP host 201.227.57.207 unreachable ICMP host 216.161.250.188 unreachable ~

1 0

Re: [44net] storm blocking
by Rob Janssen 11 May '17

11 May '17

> 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

4 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net