Am I being attacked?

spookymonkey

Hi,

Recently I noticed that Suricata has been returning a ton of alerts with "1:2200075 SURICATA UDPv4 invalid checksum"

When I take a pcap this is what I get for just a couple seconds of capturing (notice it's nearly all ARP broadcast requests):

19:19:29.229547 ARP, Request who-has 99.241.5.179 tell 99.241.4.1, length 46
19:19:29.239022 ARP, Request who-has 38.35.216.133 tell 38.35.216.129, length 46
19:19:29.258399 ARP, Request who-has 99.241.9.180 tell 99.241.8.1, length 46
19:19:29.267626 ARP, Request who-has 38.39.57.236 tell 38.39.57.225, length 46
19:19:29.271376 ARP, Request who-has 99.241.7.50 tell 99.241.6.1, length 46
19:19:29.286129 ARP, Request who-has 99.241.21.86 tell 99.241.20.1, length 46
19:19:29.290078 ARP, Request who-has 24.212.192.115 tell 24.212.192.97, length 46
19:19:29.291731 ARP, Request who-has 99.241.18.154 tell 99.241.18.1, length 46
19:19:29.292505 ARP, Request who-has 24.212.192.125 tell 24.212.192.97, length 46
19:19:29.298632 ARP, Request who-has 104.204.135.143 tell 104.204.135.129, length 46
19:19:29.302382 ARP, Request who-has 99.241.21.71 tell 99.241.20.1, length 46
19:19:29.303357 ARP, Request who-has 72.141.66.37 tell 72.141.66.1, length 46
19:19:29.307256 ARP, Request who-has 99.241.7.89 tell 99.241.6.1, length 46
19:19:29.310758 ARP, Request who-has 216.181.175.83 tell 216.181.175.1, length 46
19:19:29.314084 ARP, Request who-has 206.188.76.163 tell 206.188.76.161, length 46
19:19:29.317460 ARP, Request who-has 99.241.19.203 tell 99.241.18.1, length 46
19:19:29.329686 ARP, Request who-has 38.80.102.206 tell 38.80.102.193, length 46
19:19:29.333486 ARP, Request who-has 99.241.9.146 tell 99.241.8.1, length 46
19:19:29.335112 ARP, Request who-has 99.241.5.34 tell 99.241.4.1, length 46
19:19:29.346713 ARP, Request who-has 99.X.X.X7 tell 99.241.10.1, length 46
19:19:29.355666 ARP, Request who-has 99.241.2.212 tell 99.241.2.1, length 46
19:19:29.359442 ARP, Request who-has 99.241.15.105 tell 99.241.14.1, length 46
19:19:29.373719 ARP, Request who-has 99.241.5.100 tell 99.241.4.1, length 46
19:19:29.390672 ARP, Request who-has 99.241.9.251 tell 99.241.8.1, length 46
19:19:29.402600 ARP, Request who-has 216.181.175.68 tell 216.181.175.1, length 46
19:19:29.410176 ARP, Request who-has 38.18.213.209 tell 38.18.213.193, length 46
19:19:29.413485 ARP, Request who-has 209.141.179.54 tell 209.141.179.33, length 46
19:19:29.419676 ARP, Request who-has 209.141.179.53 tell 209.141.179.33, length 46
19:19:29.432629 ARP, Request who-has 99.241.21.127 tell 99.241.20.1, length 46
19:19:29.434853 ARP, Request who-has 99.241.5.81 tell 99.241.4.1, length 46
19:19:29.436429 ARP, Request who-has 99.241.23.77 tell 99.241.22.1, length 46
19:19:29.456633 ARP, Request who-has 24.105.114.218 tell 24.105.114.193, length 46
19:19:29.460468 ARP, Request who-has 72.141.66.51 tell 72.141.66.1, length 46
19:19:29.462261 ARP, Request who-has 24.212.193.123 tell 24.212.193.97, length 46
19:19:29.463184 ARP, Request who-has 99.241.6.61 tell 99.241.6.1, length 46
19:19:29.466586 ARP, Request who-has 99.241.21.49 tell 99.241.20.1, length 46
19:19:29.470361 ARP, Request who-has 99.241.21.85 tell 99.241.20.1, length 46
19:19:29.479112 ARP, Request who-has 99.241.14.190 tell 99.241.14.1, length 46
19:19:29.482361 ARP, Request who-has 104.234.133.118 tell 104.234.133.1, length 46
19:19:29.483938 ARP, Request who-has 99.241.8.234 tell 99.241.8.1, length 46
19:19:29.492375 IP 99.X.X.X > 99.241.10.1: ICMP echo request, id 4831, seq 6067, length 9
19:19:29.500751 IP 99.241.10.1 > 99.X.X.X: ICMP echo reply, id 4831, seq 6067, length 9
19:19:29.507617 ARP, Request who-has 104.204.135.220 tell 104.204.135.129, length 46
19:19:29.511416 ARP, Request who-has 99.241.9.215 tell 99.241.8.1, length 46
19:19:29.516694 ARP, Request who-has 99.241.9.86 tell 99.241.8.1, length 46
19:19:29.520445 ARP, Request who-has 99.241.7.109 tell 99.241.6.1, length 46
19:19:29.523070 ARP, Request who-has 38.20.208.221 tell 38.20.208.193, length 46
19:19:29.526371 ARP, Request who-has 97.108.107.8 tell 97.108.107.1, length 46
19:19:29.528194 ARP, Request who-has 99.241.21.151 tell 99.241.20.1, length 46
19:19:29.537872 ARP, Request who-has 99.241.7.158 tell 99.241.6.1, length 46
19:19:29.539473 ARP, Request who-has 99.241.2.135 tell 99.241.2.1, length 46
19:19:29.546874 ARP, Request who-has 99.241.21.66 tell 99.241.20.1, length 46
19:19:29.550724 ARP, Request who-has 162.0.132.180 tell 162.0.132.161, length 46
19:19:29.554124 ARP, Request who-has 99.241.6.98 tell 99.241.6.1, length 46
19:19:29.557425 ARP, Request who-has 99.241.2.198 tell 99.241.2.1, length 46
19:19:29.576033 ARP, Request who-has 104.204.135.143 tell 104.204.135.129, length 46
19:19:29.579754 ARP, Request who-has 99.241.23.3 tell 99.241.22.1, length 46
19:19:29.585681 ARP, Request who-has 99.241.6.94 tell 99.241.6.1, length 46
19:19:29.594708 ARP, Request who-has 24.212.192.50 tell 24.212.192.33, length 46
19:19:29.598634 ARP, Request who-has 99.241.19.143 tell 99.241.18.1, length 46
19:19:29.624688 ARP, Request who-has 99.241.18.192 tell 99.241.18.1, length 46
19:19:29.642689 ARP, Request who-has 99.241.6.183 tell 99.241.6.1, length 46
19:19:29.648666 ARP, Request who-has 99.241.21.184 tell 99.241.20.1, length 46
19:19:29.652667 ARP, Request who-has 24.105.114.192 tell 24.105.114.193, length 46
19:19:29.654467 ARP, Request who-has 99.241.6.253 tell 99.241.6.1, length 46
19:19:29.669769 ARP, Request who-has 104.234.133.33 tell 104.234.133.1, length 46
19:19:29.694750 ARP, Request who-has 45.2.86.173 tell 45.2.86.129, length 46
19:19:29.705852 ARP, Request who-has 69.165.241.100 tell 69.165.241.97, length 46
19:19:29.711351 ARP, Request who-has 99.241.3.134 tell 99.241.2.1, length 46
19:19:29.717753 ARP, Request who-has 99.241.3.253 tell 99.241.2.1, length 46
19:19:29.732154 ARP, Request who-has 99.241.14.242 tell 99.241.14.1, length 46
19:19:29.735331 ARP, Request who-has 99.241.8.108 tell 99.241.8.1, length 46
19:19:29.771787 ARP, Request who-has 38.39.57.239 tell 38.39.57.225, length 46
19:19:29.775513 ARP, Request who-has 99.241.7.52 tell 99.241.6.1, length 46
19:19:29.777612 ARP, Request who-has 99.241.3.137 tell 99.241.2.1, length 46
19:19:29.798719 ARP, Request who-has 99.241.3.40 tell 99.241.2.1, length 46
19:19:29.810796 ARP, Request who-has 99.241.9.111 tell 99.241.8.1, length 46
19:19:29.818322 ARP, Request who-has 69.165.241.102 tell 69.165.241.97, length 46
19:19:29.837898 ARP, Request who-has 24.212.192.51 tell 24.212.192.33, length 46
19:19:29.839873 ARP, Request who-has 69.165.244.73 tell 69.165.244.65, length 46
19:19:29.841457 ARP, Request who-has 99.241.7.236 tell 99.241.6.1, length 46
19:19:29.868780 ARP, Request who-has 99.241.5.126 tell 99.241.4.1, length 46
19:19:29.872480 ARP, Request who-has 69.165.243.93 tell 69.165.243.65, length 46
19:19:29.886707 ARP, Request who-has 99.241.0.27 tell 99.241.0.1, length 46
19:19:29.920162 ARP, Request who-has 38.35.30.123 tell 38.35.30.97, length 46
19:19:29.923887 ARP, Request who-has 104.204.135.155 tell 104.204.135.129, length 46
19:19:29.938269 ARP, Request who-has 99.241.23.185 tell 99.241.22.1, length 46
19:19:29.947800 ARP, Request who-has 38.35.30.121 tell 38.35.30.97, length 46
19:19:29.951117 ARP, Request who-has 99.241.23.169 tell 99.241.22.1, length 46
19:19:29.974947 ARP, Request who-has 99.241.8.203 tell 99.241.8.1, length 46
19:19:30.000979 IP 99.X.X.X > 99.241.10.1: ICMP echo request, id 4831, seq 6068, length 9
19:19:30.006959 ARP, Request who-has 38.20.208.220 tell 38.20.208.193, length 46
19:19:30.017664 IP 99.241.10.1 > 99.X.X.X: ICMP echo reply, id 4831, seq 6068, length 9
19:19:30.018754 ARP, Request who-has 99.241.21.166 tell 99.241.20.1, length 46
19:19:30.027731 ARP, Request who-has 99.241.19.57 tell 99.241.18.1, length 46
19:19:30.046261 ARP, Request who-has 99.241.20.47 tell 99.241.20.1, length 46
19:19:30.055261 ARP, Request who-has 99.241.3.223 tell 99.241.2.1, length 46
19:19:30.059011 ARP, Request who-has 216.58.56.178 tell 216.58.56.161, length 46
19:19:30.068737 ARP, Request who-has 38.240.223.14 tell 38.240.223.1, length 46
19:19:30.070336 ARP, Request who-has 99.241.16.139 tell 99.241.16.1, length 46

When I dig into the ARP broadcast packets with Wireshark, they appear to all be coming from "Ethernet II, Src: Casa_93:a5:2c (00:17:10:93:a5:2c)". What's interesting is that under the Address Resolution Section the IPs for the Sender and Target are all different. Here is an example of one of the packets:

Frame 2: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Aug  6, 2021 19:19:29.239022000 EDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1628291969.239022000 seconds
    [Time delta from previous captured frame: 0.009475000 seconds]
    [Time delta from previous displayed frame: 0.009475000 seconds]
    [Time since reference or first frame: 0.009475000 seconds]
    Frame Number: 2
    Frame Length: 60 bytes (480 bits)
    Capture Length: 60 bytes (480 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:arp]
    [Coloring Rule Name: ARP]
    [Coloring Rule String: arp]
Ethernet II, Src: Casa_93:a5:2c (00:17:10:93:a5:2c), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: Casa_93:a5:2c (00:17:10:93:a5:2c)
        Address: Casa_93:a5:2c (00:17:10:93:a5:2c)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: ARP (0x0806)
    Padding: 000000000000000000000000000000000000
Address Resolution Protocol (request)
    Hardware type: Ethernet (1)
    Protocol type: IPv4 (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    Sender MAC address: Casa_93:a5:2c (00:17:10:93:a5:2c)
    Sender IP address: 38.35.216.129
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: 38.35.216.133

These are all coming in on my WAN interface, which I find a bit weird since I thought ARP was only for internal network communication unless maybe this is coming upstream from my ISP??

What's more is that when I check pfBlockerng, it blocked something from "Casa", which was blocked from the CINS Army block list:

193.163.125.94:51746
effective.census.cyber.casa

When I go to cyber.casa in Tor, it seems to be a super sketchy website about being a cyber research organization that checks which services people have exposed..

Does this look like some sort of ARP/DNS attack or a misconfiguration on my part?

Any suggestions on how I could stop my machine from attempting to establish connections to thousands of different servers around the world on port 53 and 123?

Gertjan

@spookymonkey said in Am I being attacked?:

suggestions on how I could stop my machine from attempting to establish connections

Stop using programs like 'tor' and other P2P sites ;)
Be discrete.
Some 'background noise' on WAN is normal.

Btw : why bother scanning your WAN ??

@spookymonkey said in Am I being attacked?:

.... to thousands of different servers around the world on port 53

Stop visiting these 'thousands' of web sites ;)
Every site or host has an IP address.
Every host that uses a domain name has a domain name server.
It will get contacted to obtain the IP address.
That how DNS works.
The pattern will always be the same : you contact a (DNS) server first and then you get an answer back. No need to scan these requests. You initiated them, so the traffic is what you want to happen.
Traffic that you not initiate will just hit 'the wall'.

stephenw10

It could be some sort of scan but since it's ARP broadcasts it would have to be from something on the same layer 2 as your WAN.
Since you're running Suricata your WAN interface will be running in promiscuous mode which means you will be seeing a lot more traffic there than you would normally.

So, no, you're probably not being actively attacked IMO.

Steve

johnpoz

Sender and Target are all different

Well yeah.. Your seeing the arp traffic on the L2 that makes up your wan network..

This is completely normal.. Only reason your seeing different address ranges is your isp is running multiple L3 on the same L2..

they appear to all be coming from "Ethernet II, Src: Casa_93:a5:2c (00:17:10:93:a5:2c)

This the mac address of the device your wan interface is connected too..

JKnott

@spookymonkey

Here is what I caught on my WAN interface in several seconds. Notice all the arp request and how they're from different subnets. My ISP provides Internet, phone, security and TV over IP. They also carry 3rd party ISPs, so there will be lots of different address ranges.

packetcapture (17).cap

spookymonkey

@jknott Thanks for the clarification on that, I guess this is legitimate traffic then and unrelated to the Suricata alerts... I did more research today on the Suricata Alerts and the Invalid Checksum errors for the outgoing traffic to destination port 53 I believe are being caused by my NIC which apparently does not support this feature in pfsense correctly so I disabled Hardware Checksum Offload under System > Advanced > Networking and those alerts are now gone. Also what had initially caused me to be suspicious was the number of requests being made to external DNS servers but I think this is being caused by Unbound, which is running for my DNS Resolver service which apparently continuously contacts root dns servers directly instead of querying 3rd party DNS servers like Google etc...

johnpoz

@spookymonkey said in Am I being attacked?:

continuously contacts root dns servers

While it talks to roots yes, it sure isn't continuous.. It would talk to roots to get the NS for say .com, now that would be cached for 24 hours..

Now if you look up something for .net, yeah it would have to query roots again.

it would cache the name servers for .com and .net for 24 hours... It would then ask one of those, which really are not root servers but global tld servers

a.gtld-servers.net

It would ask them for the NS of your domain.. So for example netgate.com, which have ttl of 48 hours.. so once you have looked up something.netgate.com, next time you need to look otherthing.netgate.com roots would not be involved at all, either would the global tld servers.

If you are restarting unbound often, then yeah you would loose all your cache, and you would see traffic to roots.. But after you have looked most of the tld NS, and then the common domains you look to - roots and gltd are not really talked to very often since the caches are quite long..

In the big picture - you prob end up doing less actual external dns queries using a resolver than a forwarder because you always get the full ttl from the authoritative sever vs whatever is left in the cache on where you forwarded too.. Normally the ttl on authoritative NS is quite long, like 24 hours or so.. So once you cache those you would only ever be talking to the authoritative NS to look up something in a domain..

So while getting to the authoritative NS for some domain might have a couple extra queries - they should be cached for quite some time. What is confusing most often to new users of a resolver is seeing IPs other than their isp ns or where they forward too.. But it really is very effective method of doing dns.. If your not resetting your cache every few minutes ;)

spookymonkey

@johnpoz Thanks for the explanation, I'm clearly not well versed on how DNS works! =S... Anyhow I think I'm all set now, until the next panic... Thanks!

SteveITS

@spookymonkey said in Am I being attacked?:

  SURICATA UDPv4 invalid checksum

With Suricata, check "Disable hardware checksum offload" (System->Advanced->Networking) or it will flag this sort of thing.

Also, if you run it on LAN instead of WAN then Suricata will not even see (and thus not waste time processing) any packets that would normally get dropped by the firewall. Plus, alerts will show the LAN IP of devices instead of the public IP of your router.

johnpoz

@steveits exactly - not sure why you would ever run it on wan to be honest.

SteveITS

@johnpoz said in Am I being attacked?:

why you would ever run it on wan to be honest

It was the default, and might still be...not sure.

spookymonkey

@steveits @johnpoz Yeah it was the default when I installed Suricata and wondered myself why this would even run on WAN if default deny is set by default by pfsense... it's somewhat interesting to see the types of attacks that are being attempted but other than that seems like a waste of resources. Just out of curiosity though, is there a way that you guys are aware of that would allow attackers to "punch through" a firewall that works based on states? For example, is it possible to craft a packet that looks like it's a response to a request made by a device from the internal network? If so, then I could see how running the Suricata service on WAN would make sense...

johnpoz

@spookymonkey said in Am I being attacked?:

like it's a response to a request made by a device from the internal network?

Doesn't actually work like that ;) And there are a few firewall rules that would stop it, for starters

antispoof for $WAN tracker 1000001570

https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html#anti-spoofing-rules

But if your talking about spoofing traffic to match an existing state.. So this attacker knows what IP(s) your talking to and what source port your connection came from?

Gertjan

@spookymonkey said in Am I being attacked?:

allow attackers to "punch through" a firewall that works based on states?

The answer is in the question.

For a state to be created, the very first initial packet has to match a rule - one of YOUR rules.
If none of your own rules matches, the last 'hidden' rule is used, which is a "discard" rule.

So, to be save : do not create rules on the 'danger' side of the router == the WAN interface.

There is no such thing as "throw huge quantity of packets to it and hope one passes".
The "system" compares them one by one, and if there are to many, they get dropped even earlier.

spookymonkey

@johnpoz Good to know. So, I guess even if an internal host sends out a request to the internet, the response packet is still inspected for spoofing. I was under the impression that when the response comes back, the firewall will look at some identifiers in the packet and if it matches an entry in its states table then would bypass all the "Rules" that are setup on the WAN interface but I guess that's not the case. Do you know where I can find the state table used in pfsense to have a better understanding of how this state table is structured and what it contains? I tried googling and searching the man pages for pfsense but couldn't find any reference to its location..

spookymonkey

@gertjan In the scenario I'm proposing, the first packet would be coming from the internal network such as a user making an HTTP request for a webpage to an external webserver on the internet. I thought the state would be created when the request is sent out by the user. My question was basically asking if a user sends out a request such as HTTP request, is it possible for an attacker to spray packets at the firewall to mimic a response and potentially get through with a malicious payload such as a web page that looks legitimate like a login page but is actually from the attacker. I'm very new to all this so if the state is created only after the response passes through the ruleset on the firewall, then this answers my question.

johnpoz

@spookymonkey said in Am I being attacked?:

Do you know where I can find the state table used in pfsense

Under Diagnostic menu - States..

attacker to spray packets at the firewall to mimic a response and potentially get through

Think about So I open say https to some site 1.2.3.4 to 443.. So now I have a source port which is going to be some random port on my wan IP, lets say 42321

Your saying this attacker, some how knows to spoof his traffic as coming from 1.2.3.4:443, and is just going to flood my IP with ever single possible port -- all 65K of them.. to hit 42321..

Now lets say he did that, that is one packet, how exactly is he getting any answer back? Any return traffic would really go to 1.2.3.4 and not him..

spookymonkey

@johnpoz In this scenario if the attacker did manage to get his HTTP response through to the target's browser, it would contain any html/javascript that the attacker wanted, so theoretically he could create a webpage that looks identical to say a login page for a website, except the form's action would point to a webserver somewhere else that he controlled (e.g., action="http://1.2.3.4/script.php" method="get"..) which would take the credentials the user input into the form thereby giving the credentials to the attacker -- so no response back is required. This attack wouldn't work with SSL encryption though but I was thinking for HTTP request this seems like it could be plausible.

Good point with the local port -- it does seem like a longshot but I did read some reports of people testing their maximum packets sent per second and people are reporting between 20,000pps - 40,000pps so if these are getting through to the target then the chances seem decent. However not sure if there are additional checks at the Application layer in the browser..

So let's say that the attacker hits the correct local port in the TCP portion of the packet with correct source/destination IP at the right moment, how would the firewall know the difference from these pieces of information between the true response and the malicious response? Are there any other identifiers that you know of that the firewall is looking at? Is this problem too complex to figure out without a team of specialized nerds? =)

johnpoz

Well I think your a bit out into fantasy land if you seriously think you would fall victim to such an attack. But pf should be checking sequence number and timestamps as well with antispoof.

https://man.openbsd.org/pf.conf
comparing a packet to a state involves checking its sequence numbers, as well as TCP timestamps if a rule using the reassemble tcp parameter applies to the connection. If these values are outside the narrow windows of expected values, the packet is dropped. This prevents spoofing attacks, such as when an attacker sends packets with a fake source address/port but does not know the connection's sequence numbers.

I have not looked into such things in a really long time ;) I do not believe these settings are exposed in the gui to manipulate..

stephenw10

A direct attack against a browser on a host behind the firewall like that is extremely unlikely IMO.

There are many far easier vectors a determined attacker might employ. Almost all of which involve the host connecting out to some malicious resource which the firewall will allow by default. You just need to trick the host into doing it.

You can filter outbound connections to lists of known malware sites and that can help against a wide spread generic attack. Targeted, spear-phishing type attacks are far less likely to be on a list like that though.

Steve