IP source and destination not in LAN or public ip…

[Tech Junky]

Ok, So, it's sending keepalive / connectivity checks to the IP.

Could be a soundbar / thermostat / tv / console / etc.

Next thing to do is check the MAC and see which device it is.

Wireshark · OUI Lookup Tool

Wireshark: The world's most popular network protocol analyzer

www.wireshark.org

 

[HELLO_wORLD]

But the suricate log:

First entry is as expected, but the rest? None of these UDP packets were captured by tcpdump???
Could suricata have made them up? I am lost on that one…

"timestamp":"2022-06-28T00:54:20.238653+0200","flow_id":251518454920431,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"LAN_DEVICE_IP","dest_ip":"59.122.164.158","proto":"ICMP","icmp_type":8,"icmp_code":0,"flow":{"pkts_toserver":6,"pkts_toclient":0,"bytes_toserver":588,"bytes_toclient":0,"start":"2022-06-28T00:50:16.259311+0200","end":"2022-06-28T00:50:21.359963+0200","age":5,"state":"new","reason":"timeout","alerted":false},"community_id":"1:6LyQuwmWks1srlFd4xT9UZZ6IZ8="

"timestamp":"2022-06-28T01:43:23.049335+0200","flow_id":1977111958814495,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"59.122.164.158","src_port":29465,"dest_ip":"129.31.207.88","dest_port":7902,"proto":"UDP","app_proto":"failed","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":42,"bytes_toclient":0,"start":"2022-06-28T01:40:44.425759+0200","end":"2022-06-28T01:40:44.425759+0200","age":0,"state":"new","reason":"timeout","alerted":false},"community_id":"1:4gPpb3EPr6fGcJcoqN2Eqdc/gJo="

"timestamp":"2022-06-28T14:25:04.098775+0200","flow_id":910670283152624,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"59.122.164.158","src_port":30858,"dest_ip":"127.42.15.208","dest_port":59,"proto":"UDP","app_proto":"failed","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":42,"bytes_toclient":0,"start":"2022-06-28T14:23:24.007408+0200","end":"2022-06-28T14:23:24.007408+0200","age":0,"state":"new","reason":"timeout","alerted":false},"community_id":"1:zIiVIr6cxGM7dTZMncsiFRurHEs="

"timestamp":"2022-06-28T15:44:38.510590+0200","flow_id":2020932517056643,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"59.122.164.158","src_port":10430,"dest_ip":"175.183.144.32","dest_port":58099,"proto":"UDP","app_proto":"failed","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":42,"bytes_toclient":0,"start":"2022-06-28T15:40:27.938115+0200","end":"2022-06-28T15:40:27.938115+0200","age":0,"state":"new","reason":"timeout","alerted":false},"community_id":"1:Q30qGdRfTBGDxWYlhcdi3Qr29wc="

"timestamp":"2022-06-28T16:17:28.173509+0200","flow_id":361683704427068,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"59.122.164.158","src_port":61034,"dest_ip":"216.182.118.166","dest_port":55336,"proto":"UDP","app_proto":"failed","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":42,"bytes_toclient":0,"start":"2022-06-28T16:14:17.209468+0200","end":"2022-06-28T16:14:17.209468+0200","age":0,"state":"new","reason":"timeout","alerted":false},"community_id":"1:zRtiOfHPYROu5X1TOaR5D32Op8c="

2/2

 

[HELLO_wORLD]

Ok, So, it's sending keepalive / connectivity checks to the IP.

Could be a soundbar / thermostat / tv / console / etc.

Next thing to do is check the MAC and see which device it is.

Wireshark · OUI Lookup Tool

Wireshark: The world's most popular network protocol analyzer

www.wireshark.org

The MAC (and IP) is my SBC (same as where IDS is installed BTW).
It runs several containers (smokeping, openhab, influxdb, grafana, chronograf, telegraf, etc…) but their network is isolated (docker0, and other bridges).

Even though, nothing wrong in sending a ping, source is in LAN, destination on WAN, normal.
I don't see these WAN/WAN packets with tcpdump… But suricata does. I trust tcpdump more that suricata.

 

[Tech Junky]

I don't see these WAN/WAN packets with tcpdump

This is where moving around things to properly tap / intercept the packets would come into play vs redirecting things for capture. Mirroring doesn't give the full picture in this instance.

So, on my DIY setup my PC is the router connected directly to the ISP which gives complete surveillance of the packets. If you converted the SBC to a router function you would gain the same insight and be able to figure out the trigger causing the packets. The SBC should be capable of acting as a router with some configuration tweaks to add the functionality. I'm just using Linux as the OS on the DIY box vs a built to route OS option like some others. I'm not forced into a corner this way and can tweak things as needed w/o worrying about the underlying image not being compatible.

ISP <> DIY <> LAN/WIFI

The only hardwired device is my OTA tuner for recording ATSC/3 to Plex and everything else is wireless. Using Pihole for the DNS gives a quick look at what's hitting from what source but NTOP can dig a bit deeper. It all depends on how nerdy you want to get to figure out the source of the traffic and whether to block it or not. I personally don't like the call home functions of devices and block them, Eventually they give up and stop sending traffic and work just fine w/o the call home function. Particularly Google being invasive with their monitoring is a good excuse to block them. Streaming sticks tend to be quite chatty as well and don't need to have full access to ping out every 10 seconds. Devs and OEM's go a bit far in their reach to collect stats under the guise of connectivity checks.

 

[HELLO_wORLD]

SBC is not strong enough to route all my traffic (no hardware acceleration, particularly for symmetrical gbps).
The R7800 is a workhorse for routing (hardware acceleration is awesome), but not so great for anything else, including IDS (and forget about IPS)…

I have many rules protecting my LAN, port knocking, ebtables, iptables… So I am not worried.
I like the idea of an IDS to see if there is any suspicious activity, and the best way I found is the way I made it. I have a switch that can do port mirroring, but I would not see anything WLAN (or anything involving the router itself…).

The tee solution should mirror all the traffic, so should not be a problem.
The tcpdump I ran was even before the tee, on the router itself, so I really think that suricata is seeing a packet from somewhere on the WAN to somewhere else on the WAN that does not really exists… Maybe it is some embedded packet or a wrong detection/interpretation.

 

[Tech Junky]

True, it could be a false positive being picked up.

Running an SBC as a router though wouldn't be the first time it's been done. Now, running more apps / rules on it might be a bottleneck depending on how granular you get. I noticed on my DIY box using a full fledged CPU / RAM the rules impacting speed depending on how deep a packet goes before being denied. I switched the default functions to block in iptables and then a couple of permit statements per section works a lot better. Adding a deny at the end is just for counters observation as it's all denied if it doesn't match a rule in the first place.

For the WLAN I have the AP hooked up to a port on the DIY and have full visual of packets coming through since it's a direct connection. As well the DIY box being the router the same view. So, you mentioned a switch and that means you have more wired devices to contend with. You should still be able to capture all data with an inline approach between the ISP / router. Something that comes to mind is Firewalla. Though you can make your own with a small PC with more functionality for less $.

I've used the R7800 in the past and it worked better than the RT2600AC from Synology but, still left me wanting more out of it. Between the constant flurry of FW updates and sometimes issues with the WIFI I moved on to my own design instead. A couple of years into with no regrets and very few issues to deal with. Those issues though were self inflicted usually from updates on the system like the kernel sometimes not including the proper info for the NIC and requiring a rollback to the prior version.

 

[HELLO_wORLD]

More tweaks I set on my IDS config (SBC side):

net.ipv4.conf.IDS_ETH_INTERFACE.accept_redirects = 0
net.ipv4.conf.IDS_ETH_INTERFACE.accept_source_route = 0
net.ipv4.conf.IDS_ETH_INTERFACE.forwarding = 0
net.ipv4.conf.IDS_ETH_INTERFACE.promote_secondaries = 0
net.ipv4.conf.IDS_ETH_INTERFACE.secure_redirects = 0
net.ipv4.conf.IDS_ETH_INTERFACE.send_redirects = 0
net.ipv4.conf.IDS_ETH_INTERFACE.shared_media = 0
net.ipv4.conf.IDS_ETH_INTERFACE.rp_filter = 0
net.ipv4.conf.all.arp_ignore = 1

The arp_ignore was important as eth0 was also responding to arp requests sent to IDS_ETH_INTERFACE.

iptables -t raw -A PREROUTING -i IDS_ETH_INTERFACE -j DROP

Is still necessary to prevent duplicates… Without that, if I ping the IP attached to eth0 from another LAN device, I receive duplicate answers.

And I removed the static arp route from the router, and this from the service on the SBC:

ip link set dev IDS_ETH_INTERFACE arp off
ip link set dev IDS_ETH_INTERFACE promisc on

Because I realized that TEE was sending the packets on every device on the LAN… Reason is the switches did not know where IDS_ETH_INTERFACE was, so as when MAC are unknown, it was sent everywhere. Reenabling arp on the device allowed it to answer arp requests and to be known by switches, and the traffic is now only going to it and nowhere else.

Promiscuity is not required as all unicast packets teed are sent to the MAC of the teed IP (but it would be necessary if it was a real port mirroring).

 

[HELLO_wORLD]

So, with some distance, my IDS is working fine.

I noticed that I am missing some packets, and found out why:
Any packets generated on the router using raw sockets are not going through iptables, and therefore are not teed.

I took a different approach:
First, I mark all packets entering the router, either from wan or lan

ebtables -A INPUT --logical-in br0 -j mark --mark-set 0x99 --mark-target CONTINUE
ebtables -A INPUT -i ethwan -j mark --mark-set 0x99 --mark-target CONTINUE

Then in iptables, I tee any marked packet that is about to leave the router, or that is reaching the user space
I also mark the packets created in user space (except ones created via raw sockets…)

iptables -t raw -A OUTPUT ! -o lo -j MARK --set-xmark 0x99/0xffffffff
iptables -t filter -A INPUT -m mark --mark 0x99 -j TEE --gateway GW_IP
iptables -t mangle -A POSTROUTING -m mark --mark 0x99 -j TEE --gateway GW_IP

I might tweak the rules more, but for now, it is fine.

About raw sockets, I can see the packets if I do some logging in ebtables OUTPUT table, but I cannot tee from ebtables…
So my idea is create a dummy interface for wan and another one for lan, and put them respectively in the brwan and br0 bridges. Then, I will be able to force the packets to go into iptables using the BROUTING table and a DROP jump.
For that, I will have user space programs to aim the dummy interfaces instead of the bridge (mostly DHCP client/server that are notorious to use raw sockets).
@Voxel : could you easily add the dummy network interface module into the firmware?