13 Mar
2020
13 Mar
'20
10:06 p.m.
All,
The following are RAW firewall hits indicating nested IPIP in IPIP packets.
I run a firewall that only allows IPIP from all of you (and rules that only allows the
AMPRGW routes and my destination IPs); but since this is a RAW rule - it implies nothing
of any operator.
I have not reviewed my Netflow records; but please be vigilant of this traffic. I warned
of this issue in the "ancient" 44 mailing archives.
Table: RawChain PREROUTING (Policy: ACCEPT, 94829408 Packets, 59.38 GB Traffic)Pkts.
Traffic Target Prot. In Out Source Destination Options Comment32 2.37 KB DROP 4 tunl0 *
0.0.0.0/0 0.0.0.0/0 - -
73 ::and elbow bump::,
- Lynwood
KB3VWG
13 Mar
13 Mar
10:28 p.m.
Greetings;
On Sat, 2020-03-14 at 03:06 +0000, lleachii--- via 44Net wrote:
The following are RAW firewall hits indicating nested
IPIP in IPIP packets.
44net (at least a majority of it in the western hemosphere) have been
under a brute force attack all week. Before we typically might not have
noticed such because BK would head em off at the pass in San Diego
however now that luxury no longer exists.
I run a firewall that only allows IPIP from all of you
(and rules that only allows the AMPRGW routes and my destination IPs); but since this is a
RAW rule - it implies nothing of any operator.
I have not reviewed my Netflow records; but please be vigilant of this traffic. I warned
of this issue in the "ancient" 44 mailing archives.
You may wish to repost your firewall rules.
73 ::and elbow bump::,
73 - from 3 feet distance
--
"Nature is puzzling. Why is it with deer the males have the nice
racks but with humans the females do?"
- n1uro
-----
73 de Brian N1URO - President of EastNet
IPv6 Certified
n1uro-dawt-ampr-dawt-org
uronode-dawt-n1uro-dawt-com
14 Mar
14 Mar
7:58 a.m.
For those who use it as I do in my JNOS autoexec.nos, "tcp access"
permit and deny are useful for weeding out who is allowed on my system.
The "all" at the end of each line is for port number/range.
tcp access permit 44.0/9 all <----- needed after ARDC sale
tcp access permit 44.128/10 all <----- needed after ARDC sale
tcp access permit x.x.x.x all <----- any trusted public IP address
tcp access permit x.x.x/24 all <----- any trusted public IP subnet
tcp access deny 1/1 all <----- make sure all others are dropped
tcp access deny 128/1 all <----- make sure all others are dropped
--
Charles J. Hargrove - N2NOV
NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.
NYC-ARECS/RACES Nets 441.100/136.5 PL
ARnewsline Broadcast Mon. @ 8:00PM
NYC-ARECS Weekly Net Mon. @ 8:30PM
http://www.nyc-arecs.org
NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM
on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32
"Information is the oxygen of the modern age. It seeps through the walls
topped
by barbed wire, it wafts across the electrified borders." - Ronald Reagan
"The more corrupt the state, the more it legislates." - Tacitus
"Molann an obair an fear" - Irish Saying
(The work praises the man.)
"No matter how big and powerful government gets, and the many services it
provides, it can never take the place of volunteers." - Ronald Reagan
13 Mar
13 Mar
10:41 p.m.
N1URO,
EMAILS:
500: 5.7.1 Service unavailable
+1-240-623-1324
- KB3VWG
10:59 p.m.
All,
I received this on tunl0...an operator is implicated. Please check your configs, or
coordinate this with me ASAP.
I have not reviewed my Netflow records; but please be vigilant of this traffic. I warned
of this issue in the "ancient" 44 mailing archives.
Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port
Packets Bytes Flows2020-03-10 13:54:00.024 0.004 IPIP 45.79.209.21:0
-> 44.60.44.132:0 2 148 12020-03-10 13:54:07.102 0.001
IPIP 45.79.209.21:0 -> 44.60.44.6:0 2 148
12020-03-10 13:54:12.970 0.005 IPIP 45.79.209.21:0 -> 44.60.44.3:0
2 148 12020-03-10 13:54:14.196 0.000 IPIP 45.79.209.21:0
-> 44.60.44.135:0 2 148 12020-03-10 13:54:18.845 0.000
IPIP 45.79.209.21:0 -> 44.60.44.11:0 2 148
12020-03-10 13:54:20.285 0.000 IPIP 45.79.209.21:0 -> 44.60.44.130:0
2 148 12020-03-10 13:54:21.122 0.000 IPIP 45.79.209.21:0
-> 44.60.44.129:0 2 148 12020-03-10 13:54:21.316 0.004
IPIP 45.79.209.21:0 -> 44.60.44.15:0 2 148
12020-03-10 13:54:23.458 0.000 IPIP 45.79.209.21:0 -> 44.60.44.10:0
2 148 12020-03-10 13:54:26.495 0.000 IPIP 45.79.209.21:0
-> 44.60.44.7:0 2 148 12020-03-10 13:54:26.946 0.000
IPIP 45.79.209.21:0 -> 44.60.44.14:0 2 148
12020-03-10 13:54:30.658 0.004 IPIP 45.79.209.21:0 -> 44.60.44.13:0
2 148 12020-03-10 13:54:32.915 0.005 IPIP 45.79.209.21:0
-> 44.60.44.131:0 2 148 12020-03-10 13:54:43.095 0.004
IPIP 45.79.209.21:0 -> 44.60.44.128:0 2 148
12020-03-10 13:54:43.226 0.005 IPIP 45.79.209.21:0 -> 44.60.44.12:0
2 148 12020-03-10 13:54:46.767 0.000 IPIP 45.79.209.21:0
-> 44.60.44.1:0 2 148 1Summary: total flows: 16, total
bytes: 2368, total packets: 32, avg bps: 405, avg pps: 0, avg bpp: 74Time window:
2020-03-06 20:42:15 - 2020-03-13 23:39:18Total flows processed: 785839, Blocks skipped: 0,
Bytes read: 50600280Sys: 0.532s flows/second: 1477141.0 Wall: 0.501s flows/second:
1567023.9
Times EDT.
---
root@OpenWrt:~# ip route get 45.79.209.21 from 44.60.44.25445.79.209.21 from 44.60.44.254
via 169.228.34.84 dev tunl0 table 44 uid 0 cache
(default route -nested IPIP loop)
73 ::and elbow bump::,
- Lynwood
KB3VWG
11:21 p.m.
All,
Just to be sure and display:
Chain zone_wan_input (2 References)12.83 K 1.96 MB ACCEPT 4 * * 0.0.0.0/0 0.0.0.0/0
match-set ipipfilter src Allow-AMPR_IPENCAP
This filter is on the Firewall Wiki - only traffic from you.
- KB3VWG
11:52 p.m.
All,
Since I have no record of these de-encapsulations, after analysis, I consider this a
concern - this is the specific packet of concern:
2020-03-10 13:54:46.767 0.000 IPIP 45.79.209.21:0 -> 44.60.44.1:0
2 148 1
Only IPs with DNS records (44.1) were hit...I will be searching my entire subnet record in
netflow.
I need an Operator to identify and describe this packet; and reveal themselves to me
ASAP.
N1URO, I will also be re-evaluating the kb3vwg-001.ampr.org A and PTRs - I'll contact
you.
- KB3VWG
-----Original Message-----
From: lleachii <lleachii(a)aol.com>
To: 44net <44net(a)mailman.ampr.org>
Sent: Fri, Mar 13, 2020 11:59 pm
Subject: Re: Security - Nested IPIP
All,
I received this on tunl0...an operator is implicated. Please check your configs, or
coordinate this with me ASAP.
I have not reviewed my Netflow records; but please be vigilant of this traffic. I warned
of this issue in the "ancient" 44 mailing archives.
Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port
Packets Bytes Flows2020-03-10 13:54:00.024 0.004 IPIP 45.79.209.21:0
-> 44.60.44.132:0 2 148 12020-03-10 13:54:07.102 0.001
IPIP 45.79.209.21:0 -> 44.60.44.6:0 2 148
12020-03-10 13:54:12.970 0.005 IPIP 45.79.209.21:0 -> 44.60.44.3:0
2 148 12020-03-10 13:54:14.196 0.000 IPIP 45.79.209.21:0
-> 44.60.44.135:0 2 148 12020-03-10 13:54:18.845 0.000
IPIP 45.79.209.21:0 -> 44.60.44.11:0 2 148
12020-03-10 13:54:20.285 0.000 IPIP 45.79.209.21:0 -> 44.60.44.130:0
2 148 12020-03-10 13:54:21.122 0.000 IPIP 45.79.209.21:0
-> 44.60.44.129:0 2 148 12020-03-10 13:54:21.316 0.004
IPIP 45.79.209.21:0 -> 44.60.44.15:0 2 148
12020-03-10 13:54:23.458 0.000 IPIP 45.79.209.21:0 -> 44.60.44.10:0
2 148 12020-03-10 13:54:26.495 0.000 IPIP 45.79.209.21:0
-> 44.60.44.7:0 2 148 12020-03-10 13:54:26.946 0.000
IPIP 45.79.209.21:0 -> 44.60.44.14:0 2 148
12020-03-10 13:54:30.658 0.004 IPIP 45.79.209.21:0 -> 44.60.44.13:0
2 148 12020-03-10 13:54:32.915 0.005 IPIP 45.79.209.21:0
-> 44.60.44.131:0 2 148 12020-03-10 13:54:43.095 0.004
IPIP 45.79.209.21:0 -> 44.60.44.128:0 2 148
12020-03-10 13:54:43.226 0.005 IPIP 45.79.209.21:0 -> 44.60.44.12:0
2 148 12020-03-10 13:54:46.767 0.000 IPIP 45.79.209.21:0
-> 44.60.44.1:0 2 148 1Summary: total flows: 16, total
bytes: 2368, total packets: 32, avg bps: 405, avg pps: 0, avg bpp: 74Time window:
2020-03-06 20:42:15 - 2020-03-13 23:39:18Total flows processed: 785839, Blocks skipped: 0,
Bytes read: 50600280Sys: 0.532s flows/second: 1477141.0 Wall: 0.501s flows/second:
1567023.9
Times EDT.
---
root@OpenWrt:~# ip route get 45.79.209.21 from 44.60.44.25445.79.209.21 from 44.60.44.254
via 169.228.34.84 dev tunl0 table 44 uid 0 cache
(default route -nested IPIP loop)
73 ::and elbow bump::,
- Lynwood
KB3VWG
14 Mar
14 Mar
12:32 a.m.
These 2 packets were also dropped - raw rule.
But who has a bot inside AMPR?
2020-03-10 13:54:46.767 0.000 IPIP 45.79.209.21:0 -> 44.60.44.1:0
2 148 1
Only IPs with DNS records (44.1) were hit...I will be searching my entire subnet record in
netflow.
I need an Operator to identify and describe this packet; and reveal themselves to me
ASAP.
N1URO, I will also be re-evaluating the kb3vwg-001.ampr.org A and PTRs - I'll contact
you.
12:43 a.m.
I am having a difficult time following these formats. What packet type
is this? the 45.x is the inside or outside source??
Rest of this is hopefully unrelated --
I have been playing with AWS and got myself a 44.x IP after requesting
elastics IPs a few times.. I downloaded the amprhosts and did a quick
ICMP echo scan of those with DNS entries. It was just before whatever
this traffic is (Mar 9 03:25 UTC). Maybe unrelated or maybe they saw
my scan and did a scan.. I don't know...
I was hoping to put together a list of IPs that are still trusting the
AWS parts of 44.x whereas they should not. I only very briefly looked
at the difference between the 2 scans I ran -- from within AWS 44.x IP
space, and a non-44 IP. I would expect the results to be the same,
but the 1 site I checked was trusting AWS gave me a mikrotek router
login page.
A bit more concerning is I didn't see the IP in the portal. It was
44.170.101.1. They are announcing entire /16 for Croatia. Probably
legit but just undocumented and a bit trusty of address space which is
no longer amprnet...
regards,
scott
On Sat, Mar 14, 2020 at 1:34 AM lleachii--- via 44Net
<44net(a)mailman.ampr.org> wrote:
These 2 packets were also dropped - raw rule.
But who has a bot inside AMPR?
2020-03-10 13:54:46.767 0.000 IPIP 45.79.209.21:0 -> 44.60.44.1:0
2 148 1
Only IPs with DNS records (44.1) were hit...I will be searching my entire subnet record
in netflow.
I need an Operator to identify and describe this packet; and reveal themselves to me
ASAP.
N1URO, I will also be re-evaluating the kb3vwg-001.ampr.org A and PTRs - I'll contact
you.
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
10:26 a.m.
All,
Since I have no record of these de-encapsulations
I think have the POSSIBLE origin of the outer packet:
Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port
Packets Bytes Flows2020-03-10 10:31:26.430 7120.652 IPIP 89.229.166.34:0
-> 173.66.138.124:0 86 7609 12020-03-10 10:31:26.430 7120.652
IPIP 173.66.138.124:0 -> 89.229.166.34:0 67 14247
12020-03-10 14:00:01.416 3606.239 IPIP 173.66.138.124:0 -> 89.229.166.34:0
68 16572 12020-03-10 14:00:01.416 3606.239 IPIP 89.229.166.34:0
-> 173.66.138.124:0 84 7128 12020-03-10 16:30:06.437 1.169
IPIP 173.66.138.124:0 -> 89.229.166.34:0 15 3569
12020-03-10 16:30:06.437 1.169 IPIP 89.229.166.34:0 -> 173.66.138.124:0
18 1486 12020-03-10 16:34:19.372 1883.215 IPIP 141.75.245.225:0
-> 173.66.138.124:0 28 2303 12020-03-10 16:34:19.372 1883.215
IPIP 173.66.138.124:0 -> 141.75.245.225:0 28 7792 1Summary:
total flows: 8, total bytes: 60706, total packets: 394, avg bps: 20, avg pps: 0, avg bpp:
154Time window: 2020-03-09 12:35:36 - 2020-03-10 18:46:54Total flows processed: 86880,
Blocks skipped: 0, Bytes read: 5583424Sys: 0.076s flows/second: 1143157.9 Wall: 0.059s
flows/second: 1471544.7
root@OpenWrt:~# ipset test ipipfilter 89.229.166.34Warning: 89.229.166.34 is in set
ipipfilter.
root@OpenWrt:~# ip route show table 44 | grep 89.229.166.3444.165.65.0/24 via
89.229.166.34 dev tunl0 proto 44 onlink window 840
44.165.65.0 / 24 HamNET Augustów
To those who've emailed me:
What is posted thus far are IP Headers 0 and 1 of nested IPIP packets. I do not believe I
can find a log of Header 2 - as it should have been RAW DROP on it's second loop
through the Routing Place. This third header and the traffic it generated (without
firewalling in place by others) is my concern. It should also be borne in mind that this
is why such traffic should not be entering our gateways without our knowledge.
- KB3VWG
10:46 a.m.
All,
Times UTC in this post:
root@OpenWrt:~# tcpdump -vv -i eth0.2 proto 4 and host 89.229.166.34
15:30:07.246887 IP (tos 0x0, ttl 64, id 658, offset 0, flags [DF], proto IPIP (4), length
492) pool-173-66-138-124.washdc.fios.verizon.net > host-89-229-166-34.dynamic.mm.pl:
IP (tos 0x0, ttl 63, id 37286, offset 0, flags [DF], proto TCP (6), length 472)
dns-mdc.ampr.org.53 > sq4bjo.ampr.org.49277: Flags [.], cksum 0x198a (correct), seq
1:421, ack 52, win 227, options [nop,nop,TS val 644116773 ecr 886448869], length 420 61816
q: DS? ampr.org. 0/6/1 ns: org. SOA a0.org.afilias-nst.info. noc.afilias-nst.info.
2013855735 1800 900 604800 86400, org. RRSIG, atjop9o5etdmctlc3gics8odi0er6i6k.org.
RRSIG[|domain]
15:30:07.247010 IP (tos 0x0, ttl 64, id 659, offset 0, flags [DF], proto IPIP (4), length
410) pool-173-66-138-124.washdc.fios.verizon.net > host-89-229-166-34.dynamic.mm.pl:
IP (tos 0x0, ttl 63, id 37287, offset 0, flags [DF], proto TCP (6), length 390)
dns-mdc.ampr.org.53 > sq4bjo.ampr.org.49277: Flags [P.], cksum 0xe3e8 (correct), seq
421:759, ack 52, win 227, options [nop,nop,TS val 644116773 ecr 886448869], length 338
41210 op6 NotZone|$ [8240q] q: Type40139 (Class 56493)?
?QtHM-;M-q_^^^BM-%M-h^DM-^HzM-@M-|^@2^@^A^@^@^CM-^D^@&^A^A^@^A^DM-SM-^YM-jM-+^TWj}[wpe^WM-^?j^V'M-^[M-^QM-^AM-<M-^Q~^?M-s^@^F@^@^@^@^@^B
h9p7u7tr2u91d0v0ljs9l1gidnp90u3hM-A;^@.^@^A^@^@^CM-^D^@M-^W^@2^G^B^@^AQM-^@^M-^HM-'M-Q^lM-jAM-^AM-9^Corg.,
q:[|domain]
I've seen little DNS traffic that I'd define as "normal"...
- KB3VWG
2:57 p.m.
Rob,
I respect you - you helped me identify the AMPR routing plane on Linux and TNOS/JONS...
The spoofing is happening on GRE too...GRE was first.
73,
- Lynwood
KB3VWG
3:11 p.m.
Charles,
Yes, all firewall rules are indeed amended - for the /9 and /10 - after the sale.
- KbB3VWG
11:36 p.m.
Scott,
The netflow printouts are from NfSen:
http://nfsen.sourceforge.net/
The running traffic is tcpdump:
https://linux.die.net/man/8/tcpdump
If you provide the approximate date/time of your search, I'll look it up - but my
firewall should have treated your traffic with all non-AMPR DROP rules applicable...and
(obviously) the Header 0 would have come from AMPRGW...unless you were spoofing IPIP
packets and that device's IP is also your registered GW?
And your test shows that some operators need to work on their firewall sets - especially
after the sale. And I do not believe your described traffic is related to this.
73,
- Lynwood
KB3VWG
15 Mar
15 Mar
12:56 p.m.
N1URO,
Your email still giving mostly 5.7.1, contact me in regard to the last task. The data I
sent and traffic I posted are valid (i.e. the gateways are real), I had TCP traffic as you
recall.
- Lynwood
11:27 p.m.
All,
At this point, I think I've got enough SMTP 500 errors from my coordinator:
* Some are seeing rogue packets across their GWs (I only found, blocked and identified 32
such attempted packets on 10MAR at approx 2100 UTC via an existing raw rule that drops
IPENCAP packets received into tunl0, nested in a rule that only allows IPENCAP on WAN from
you)...an operator sent that rogue 10MAR traffic to me and is still online; and has not
yet responded to my request to identify
** I believe this COULD be nested IPENCAP packets entering your tunnels (such as the 32
packets I blocked), if not firewalled, the current origin of such traffic would be
inconsequential. This is more dangerous if your routing policies use the same table for
your AMPR IPs and interfaces...I don't want to get into what information was gleaned
to determine this...if an operator does not expect a nested IPENCAP - I advise a rule to
all in such condition - to drop IPENCAP on the tunnel itself, this prevents a malicious
person from addressing your router as the destination in Header 1 and hence using your
router to forward the payload contained under Header 2
A rule to check for such is: `tcpdump -vvv -n -i tunl0 proto 4`
Except in cases an operator knowingly uses IPENCAP to send and receive to downstream
operators, you should see 0 traffic; and if you see traffic with your router as the
destination in its outer header (i.e. Header 1) - that's the issue. The traffic under
Header 2 is rogue and being routed without your knowledge and consent. I hope nobody sees
such traffic. Our BGP operators who also run IPENCAP on the same Routing Plane definitely
need to take caution.
############################################################# DROPS IP TRAFFIC THAT'S
INVALID ENTERING OR EXITING AMPR# THIS PREVENTS A GENERAL LOOP# iptables -I FORWARD -i
tunl0 -o tunl0 -j DROP
# THIS PREVENTS NESTED IPENCAPiptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP
...THIS REMINDED ME TO CHECK THAT (commented) FIREWALL LOOP RULE [I now have in OpenWrt
UCI syntax]!
509.93 K 26.31 MB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop
* If this is occurring - without proper firewalling, those who forward their IPENCAP
downstream from their border to an internal device could even experience activity that
appears as if a rogue device existed on LAN/AMPRLAN - interacting Locally
* Abnormal/uncommon traffic to my AMPR-only services, sent from some registered gateways
that are still online (I am actively experiencing this, a majority of this traffic is from
the same operator)
* MikroTik discoveries from nodes (normal)
* Normal bad traffic from the Internet via AMPRGW (I hope everyone blocks this anyway -
normal)...I did see some very sophisticated SIP/VoIP strings
* Some of you query the NTP with your Public IP thru AMPRGW instead of directly to me thru
the mesh (just a note to make your SRC IP an AMPR address, not your Public IP - I may
disable your access thru AMPGW in the future, as it's announced as
"AMPR-only")
73,
- Lynwood
KB3VWG
11:32 p.m.
509.93 K 26.31 MB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop
All,
To be clear:
These are packets that seem to have come from one of you...that wanted me to route it to a
destination - that was not my subnet.
- KB3VWG
-----Original Message-----
From: lleachii <lleachii(a)aol.com>
To: 44net <44net(a)mailman.ampr.org>
Sent: Mon, Mar 16, 2020 12:27 am
Subject: Re: Security - Nested IPIP
All,
At this point, I think I've got enough SMTP 500 errors from my coordinator:
* Some are seeing rogue packets across their GWs (I only found, blocked and identified 32
such attempted packets on 10MAR at approx 2100 UTC via an existing raw rule that drops
IPENCAP packets received into tunl0, nested in a rule that only allows IPENCAP on WAN from
you)...an operator sent that rogue 10MAR traffic to me and is still online; and has not
yet responded to my request to identify
** I believe this COULD be nested IPENCAP packets entering your tunnels (such as the 32
packets I blocked), if not firewalled, the current origin of such traffic would be
inconsequential. This is more dangerous if your routing policies use the same table for
your AMPR IPs and interfaces...I don't want to get into what information was gleaned
to determine this...if an operator does not expect a nested IPENCAP - I advise a rule to
all in such condition - to drop IPENCAP on the tunnel itself, this prevents a malicious
person from addressing your router as the destination in Header 1 and hence using your
router to forward the payload contained under Header 2
A rule to check for such is: `tcpdump -vvv -n -i tunl0 proto 4`
Except in cases an operator knowingly uses IPENCAP to send and receive to downstream
operators, you should see 0 traffic; and if you see traffic with your router as the
destination in its outer header (i.e. Header 1) - that's the issue. The traffic under
Header 2 is rogue and being routed without your knowledge and consent. I hope nobody sees
such traffic. Our BGP operators who also run IPENCAP on the same Routing Plane definitely
need to take caution.
############################################################# DROPS IP TRAFFIC THAT'S
INVALID ENTERING OR EXITING AMPR# THIS PREVENTS A GENERAL LOOP# iptables -I FORWARD -i
tunl0 -o tunl0 -j DROP
# THIS PREVENTS NESTED IPENCAPiptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP
...THIS REMINDED ME TO CHECK THAT (commented) FIREWALL LOOP RULE [I now have in OpenWrt
UCI syntax]!
509.93 K 26.31 MB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop
* If this is occurring - without proper firewalling, those who forward their IPENCAP
downstream from their border to an internal device could even experience activity that
appears as if a rogue device existed on LAN/AMPRLAN - interacting Locally
* Abnormal/uncommon traffic to my AMPR-only services, sent from some registered gateways
that are still online (I am actively experiencing this, a majority of this traffic is from
the same operator)
* MikroTik discoveries from nodes (normal)
* Normal bad traffic from the Internet via AMPRGW (I hope everyone blocks this anyway -
normal)...I did see some very sophisticated SIP/VoIP strings
* Some of you query the NTP with your Public IP thru AMPRGW instead of directly to me thru
the mesh (just a note to make your SRC IP an AMPR address, not your Public IP - I may
disable your access thru AMPGW in the future, as it's announced as
"AMPR-only")
73,
- Lynwood
KB3VWG
16 Mar
16 Mar
12:01 a.m.
All,
I ran the following against my netflow (which is tcpdump syntax) tunl0 logs:
not dst net 44.60.44.0/24 and not src net 44.60.44.0/24 and not dst host 224.0.0.9
I forwarded 0 traffic from the said loop in the last 14 days, all dropped. Please start
checking!
- KB3VWG
-----Original Message-----
From: lleachii <lleachii(a)aol.com>
To: 44net <44net(a)mailman.ampr.org>
Sent: Mon, Mar 16, 2020 12:32 am
Subject: Re: Security - Nested IPIP
509.93 K 26.31 MB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop
All,
To be clear:
These are packets that seem to have come from one of you...that wanted me to route it to a
destination - that was not my subnet.
- KB3VWG
-----Original Message-----
From: lleachii <lleachii(a)aol.com>
To: 44net <44net(a)mailman.ampr.org>
Sent: Mon, Mar 16, 2020 12:27 am
Subject: Re: Security - Nested IPIP
All,
At this point, I think I've got enough SMTP 500 errors from my coordinator:
* Some are seeing rogue packets across their GWs (I only found, blocked and identified 32
such attempted packets on 10MAR at approx 2100 UTC via an existing raw rule that drops
IPENCAP packets received into tunl0, nested in a rule that only allows IPENCAP on WAN from
you)...an operator sent that rogue 10MAR traffic to me and is still online; and has not
yet responded to my request to identify
** I believe this COULD be nested IPENCAP packets entering your tunnels (such as the 32
packets I blocked), if not firewalled, the current origin of such traffic would be
inconsequential. This is more dangerous if your routing policies use the same table for
your AMPR IPs and interfaces...I don't want to get into what information was gleaned
to determine this...if an operator does not expect a nested IPENCAP - I advise a rule to
all in such condition - to drop IPENCAP on the tunnel itself, this prevents a malicious
person from addressing your router as the destination in Header 1 and hence using your
router to forward the payload contained under Header 2
A rule to check for such is: `tcpdump -vvv -n -i tunl0 proto 4`
Except in cases an operator knowingly uses IPENCAP to send and receive to downstream
operators, you should see 0 traffic; and if you see traffic with your router as the
destination in its outer header (i.e. Header 1) - that's the issue. The traffic under
Header 2 is rogue and being routed without your knowledge and consent. I hope nobody sees
such traffic. Our BGP operators who also run IPENCAP on the same Routing Plane definitely
need to take caution.
############################################################# DROPS IP TRAFFIC THAT'S
INVALID ENTERING OR EXITING AMPR# THIS PREVENTS A GENERAL LOOP# iptables -I FORWARD -i
tunl0 -o tunl0 -j DROP
# THIS PREVENTS NESTED IPENCAPiptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP
...THIS REMINDED ME TO CHECK THAT (commented) FIREWALL LOOP RULE [I now have in OpenWrt
UCI syntax]!
509.93 K 26.31 MB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop
* If this is occurring - without proper firewalling, those who forward their IPENCAP
downstream from their border to an internal device could even experience activity that
appears as if a rogue device existed on LAN/AMPRLAN - interacting Locally
* Abnormal/uncommon traffic to my AMPR-only services, sent from some registered gateways
that are still online (I am actively experiencing this, a majority of this traffic is from
the same operator)
* MikroTik discoveries from nodes (normal)
* Normal bad traffic from the Internet via AMPRGW (I hope everyone blocks this anyway -
normal)...I did see some very sophisticated SIP/VoIP strings
* Some of you query the NTP with your Public IP thru AMPRGW instead of directly to me thru
the mesh (just a note to make your SRC IP an AMPR address, not your Public IP - I may
disable your access thru AMPGW in the future, as it's announced as
"AMPR-only")
73,
- Lynwood
KB3VWG
4:07 p.m.
All,
Here is a sample of 2 spoofed VoIP/SIP packets. As you see, this packet appears crafted to
solicit an error message from a SIP-based VoIP server behind the tunnel. This particular
traffic came from AMPRGW; but (as I've noted) I see rogue traffic from operators as
well. Time are UTC:
20:32:32.489281 IP (tos 0x0, ttl 53, id 38790, offset 0, flags [none], proto IPIP (4),
length 450) 169.228.34.84 > 71.178.206.102: IP (tos 0x0, ttl 48, id 0, offset 0,
flags [DF], proto UDP (17), length 430) 194.55.132.250.5098 > 44.60.44.1.5060: [udp
sum ok] SIP, length: 402 INVITE sip:100@44.60.44.1 SIP/2.0 Via: SIP/2.0/UDP
127.0.0.1:5098;branch=z9hG4bK-2583203840;rport Content-Length: 0 From:
"sipvicious"<sip:100@1.1.1.1>;tag=3263336332633031313363340133333730373737313235
Accept: application/sdp User-Agent: friendly-scanner To:
"sipvicious"<sip:100@1.1.1.1> Contact: sip:100@127.0.0.1:5098 CSeq: 1
INVITE Call-ID: 1165477011722833972303821 Max-Forwards: 70 20:32:32.489429 IP (tos 0x0,
ttl 53, id 50088, offset 0, flags [none], proto IPIP (4), length 449) 169.228.34.84
> 71.178.206.102: IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17),
length 429) 194.55.132.250.5098 > 44.60.44.2.5060: [udp sum ok] SIP, length: 401
INVITE sip:100@44.60.44.2 SIP/2.0 Via: SIP/2.0/UDP
127.0.0.1:5098;branch=z9hG4bK-3385379125;rport Content-Length: 0 From:
"sipvicious"<sip:100@1.1.1.1>;tag=3263336332633032313363340134313435373433363337
Accept: application/sdp User-Agent: friendly-scanner To:
"sipvicious"<sip:100@1.1.1.1> Contact: sip:100@127.0.0.1:5098 CSeq: 1
INVITE Call-ID: 710126403977583954741903 Max-Forwards: 70
This is a spoofed ICMP message - appearing to reject a GRE connection attempt sent from
me. It appears to be backscatter, or malicious traffic crafted to solicit my gateway to
generate rejection traffic. Obviously, I did not attempt to connect to a GRE tunnel from
my AMPRLAN IP:
18:58:42.000423 IP (tos 0x0, ttl 53, id 51481, offset 0, flags [none], proto IPIP (4),
length 596) 169.228.34.84 > 71.178.206.102: IP (tos 0x0, ttl 51, id 7873, offset 0,
flags [none], proto ICMP (1), length 576) 85.25.5.43 > 44.60.44.15: ICMP 85.25.5.43
protocol 47 unreachable, length 556 IP (tos 0x0, ttl 118, id 29947, offset 0, flags
[none], proto GRE (47), length 980) 44.60.44.15 > 85.25.5.43: GREv1, Flags [key
present, sequence# present], call 37065, seq 2146734303, length 960 unknown PPP protocol
(0x004b) 0x0000: e093 66bc 4f34 6b86 5816 3665 1b72 72fe 0x0010: d730 f8f4 384f d43c
bb45 bbcb 8eba 401f 0x0020: 9ad3 0000 0000 0000 0000 0000 0000 0001 0x0030: 0000 0002
0000 0055 1905 2b00 0000 0000 0x0040: 0000 0045 00d4 0300 0000 0080 2fcf 322c 0x0050:
3c2c 0f55 1905 2b63 5788 0b8c 7ede 28b2 0x0060: 1738 494b e05b 6643 7d17 8f7a a3d9 0064
0x0070: c6e0 1f2c 6ea0 2eb7 a42b 308d 053c 0c63 0x0080: 653e 7a9d 07d5 0000 0000 0000
0000 0000 0x0090: 0000 0001 0000 0002 0000 0055 1905 2b00 0x00a0: 0000 0000 0000 0045
00d0 0300 0000 0080 0x00b0: 2fcf 329c bf97 c455 1905 2b9f 8388 0bda 0x00c0: 7977 2dc7
9dba 024b e07a 662f e55c 1494 0x00d0: 859b 34b7 8f96 c40b 34bb cc7d 8cca 8540 0x00e0:
6d61 bae4 0e02 0248 04fc 0000 0000 0000 0x00f0: 0000 0000 0000 0001 0000 0002 0000 0055
0x0100: 1905 2b00 0000 0000 0000 0045 00fe 0300 0x0110: 0000 0080 2fcf 3247 df2a 3455
1905 2b42 0x0120: 2a88 0bc2 5a87 bb6a 47ab 5a4b e0bb 66be 0x0130: e125 53c5 d451 4d25
0eba 5d74 e3e1 e42f 0x0140: a807 1f32 f362 0cfa 1ef6 c149 517d 0000 0x0150: 0000 0000
0000 0000 0000 0001 0000 0002 0x0160: 0000 0055 1905 2b00 0000 0000 0000 0045 0x0170:
0025 0400 0000 0080 2fcf 321d 472b 3a55 0x0180: 1905 2b37 0788 0b65 68a8 3c4b 0aa1 c34b
0x0190: e0b1 6626 c14a 52d0 1af7 9040 7070 f413 0x01a0: 8769 9364 307e 0850 3dec b8e5
2983 704a 0x01b0: 4722 0000 0000 0000 0000 0000 0000 0001 0x01c0: 0000 0002 0000 0055
1905 2b00 0000 0000 0x01d0: 0000 0045 0019 0400 0000 0080 2fcf 32df 0x01e0: 4a4e 4c55
1905 2bd8 ed88 0b9f 8fab 37bf 0x01f0: dcc5 514b e0ea 6647 5a53 c1c7 ea56 63e1 0x0200:
6577 a7
Again, only IPs listed in the DNS zone were attempted.
73,
- Lynwood
KB3VWG
1714
days inactive
1716
days old
18 comments
4 participants
participants (4)
-
Brian -
Charles J. Hargrove -
lleachii＠aol.com -
Scott Nicholas