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
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
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
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
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
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@aol.com To: 44net 44net@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
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.
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@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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
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
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
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
Charles, Yes, all firewall rules are indeed amended - for the /9 and /10 - after the sale.
- KbB3VWG
Scott,
The netflow printouts are from NfSen:
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
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
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
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@aol.com To: 44net 44net@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
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@aol.com To: 44net 44net@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@aol.com To: 44net 44net@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
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
-
Brian -
Charles J. Hargrove -
lleachii＠aol.com -
Scott Nicholas