44net

44net@mailman.ampr.org

2 participants
3201 discussions

gw.ampr.org from tunnel system
by Rob Janssen 12 Jul '17

12 Jul '17

Recently I saw a header in the DNS robot reply mails that the mail address has changes and the update mails now have to be sent @gw.ampr.org. I changed that in my script, but then I noticed that my system on the IPIP tunnel network cannot send mail there. Of course gw.ampr.org is 44.0.0.1 and there have been issues with reaching that from the IPIP gateway systems, but I thought those were fixed. I have changed my mail config to send the mail via my ISP smarthost and that works, but what is the status on this? Is it supposed to be working, does it work for others? It only affects my gateway on the IPIP tunnel network. From the BGP routed gateway and the radio-connected systems here in the Netherlands there is no problem, and neither from normal internet addresses. Rob

3 2

misconfigured gateways
by Brian Kantor 07 Jul '17

07 Jul '17

In general, all encapsulated packets sent to the amprgw router for decapsulation and forwarding should have inner source addresses on the 44.0.0.0/8 network, since they are being originated by hosts on that network. The owners of the following gateways should contact me or consult the error listing in the /private/pkterrors.txt file regarding misconfiguration of their gateway routing rules which is leading to the sending of packets to amprgw which have a non-44 inner source address. These packets are being discarded by the gateway router, so they're not being delivered anywhere. This could be caused by an erroneous default route pointing at amprgw. Probably you shouldn't have one of those. This isn't causing any harm, but it's not doing any good either. - Brian VE3CGG 24.55.194.111 KE5MKM 98.6.215.34 EB1AJP 188.82.69.230 VE2HOM 206.80.251.222

1 0

Re: [44net] Traceroute storm
by Rob Janssen 03 Jul '17

03 Jul '17

> For several hours now, amprgw has been seeing a storm of traceroutes from > hundreds of different source addresses. It looks like a botnet has been > activated to probe net 44 using short-TTL packets like traceroute. > In reaction to this, I've temporarily set the gateway to discard any > packet with a TTL of less than 30. (The TTL is decremented by one when > the packet is forwarded; normally, of course, only packets with a TTL > value of zero are discarded.) Interesting... is it real traceroute traffic (to UDP port 33434 and higher) or is it different? I have had this rule (with TTL limit 16 and only for UDP 33434-33499) on our gateway for quite some time and I do not see many hits on it. Maybe the traffic is different. I do not observe increased input traffic. Rob

5 6

Re: [44net] Traceroute storm
by Rob Janssen 03 Jul '17

03 Jul '17

> However, there's quite a bit more insidious kind of traffic. The Nagra > people (Kudelski Switzerland) are probing our network with false > NTP packets from the subnet 185.35.62.0/23. The comment in the RIPE > database is > inetnum: 185.35.62.0 - 185.35.63.255 > descr: This IP network is used for Internet security research. Internet-scale port scanning activities are launched from this network. Don't hesitate to contactportscan at nagra.com <http://hamradio.ucsd.edu/mailman/listinfo/44net> would you have any question. > I've added that subnet to the "security research" blocking list here. > Seems it's a never-ending battle. It sure is. 185.35.60.0/22 was already in the blocklist here, I have seen "research" traffic from the bottom half of that network as well. Rob

1 0

Traceroute storm
by Brian Kantor 03 Jul '17

03 Jul '17

For several hours now, amprgw has been seeing a storm of traceroutes from hundreds of different source addresses. It looks like a botnet has been activated to probe net 44 using short-TTL packets like traceroute. In reaction to this, I've temporarily set the gateway to discard any packet with a TTL of less than 30. (The TTL is decremented by one when the packet is forwarded; normally, of course, only packets with a TTL value of zero are discarded.) This will not affect normal traffic, most of which has TTL values in the 40 to 64 range, but will throw away the short TTL packets used by traceroute. If you have problems with some site suddenly timing out instead of its normal reachability, let me know and I'll re-enable the normal TTL processing. In that case, we'll have to find some other way to cope with the storm of traceroutes. - Brian

2 1

Mikrotik script issues
by Mark Scrano 30 Jun '17

30 Jun '17

Hello,I am having an issue with the routes script for the Mikrotik routers. I got through all the steps to get RIP working and routes began populating based of the guides here: http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_MikroTik_Routers . Then I got the latest script from http://www.yo2loj.ro/ version 3.1, while ssh'd into the box I copied and pasted the script http://www.yo2loj.ro/hamprojects/ampr-gw-3.1.rsc into the terminal. I used my public IP address in the AmprPublicIp field and my AMPRnet IP assigned to the DMZ IP address 44.68.204.1 then ran the update_amprgw script. At first I thought it was working but not all of the routes appear to be populating. I am only seeing 55 interfaces, much less than the 400+ I would expect. Any advise on this issue?ThanksMark ScranoK2EXE

3 5

Re: [44net] SYN Flood, etc.
by Josh 28 Jun '17

28 Jun '17

Sorry, that would be mine. I'm building a new gateway and was having some issues, I'll disable that host asap. Josh - VK2HFF -------- Original message -------- From: lleachii--- via 44Net <44net(a)hamradio.ucsd.edu> Date: 28/06/2017 05:03 (GMT+10:00) To: 44net(a)hamradio.ucsd.edu Cc: lleachii(a)aol.com Subject: Re: [44net] SYN Flood, etc. Rob, It appears the SYN Flood are actually coming from AMPPRNet, not the Interent: 2017-06-27 13:16:16.705 3600.001 TCP 44.136.24.62:52055 -> 44.60.44.3:53 9 695 1 2017-06-27 13:16:16.705 3600.001 TCP 44.60.44.3:53 -> 44.136.24.62:52055 41 49452 1 2017-06-27 13:18:41.842 3600.004 TCP 44.136.24.62:51655 -> 44.60.44.3:53 4 306 1 2017-06-27 13:18:41.842 3600.004 TCP 44.60.44.3:53 -> 44.136.24.62:51655 28 37152 1 After closing tcp/53, this is the only host causing hits on my SYN Flood filter. - KB3VWG _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

3 5

Re: [44net] SYN Flood, etc.
by Rob Janssen 27 Jun '17

27 Jun '17

> Further inspecting the firewall, only 5 packets in over 20,000 were > dropped. Perhaps the SYN Flood setting is too sensitive for a series of > multiple DNS queries at the same time. I sometimes see mis-detections of floods on TCP port 53 too. The resolver has to open a separate connection for each request once it has to use TCP mode. Due to the increased use of DNSSEC this happens more often than in the past. Rob

1 0

Re: [44net] SYN Flood, etc.
by Rob Janssen 27 Jun '17

27 Jun '17

> I'll be closing TCP/53 to the Internet - NOW. You need to close UDP/53 as well! It is widely abused for DDoS amplification, you really should not offer DNS service on internet unless you have modern software to do rate limiting etc. Look at the poor souls who make a change to their MikroTik router (usually configuring it for PPPoE according to the directions they find on Youtube instead of according to the manual) and mistakenly open their DNS resolver on internet... they end up being abused as DDoS amplifier/reflector all the time. We run a slave DNS server for AMPRnet as well, but: only on the 44 network. Rob

2 2

Re: [44net] SYN Flood, etc.
by Rob Janssen 27 Jun '17

27 Jun '17

> - The only tcp/53 I have open is AMPR DNS (most connections are coming from 104.236.176.72) Those are on my list of scanners/blackhats. The name "stretchoid.com" is already indicative of what they do. However, as Brian Kantor also wrote, it is a really bad idea to run a DNS server on an internet-facing interface. Keep it accessible only from the amprnet side. Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net