Am I being attacked?
-
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
-
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..
-
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.
-
@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...
-
@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 ;)
-
@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!
-
@spookymonkey said in Am I being attacked?:
SURICATA UDPv4 invalid checksumWith 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.
-
@steveits exactly - not sure why you would ever run it on wan to be honest.
-
@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.
-
@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...
-
@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?
-
@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. -
@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..
-
@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.
-
@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..
-
@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? =)
-
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..
-
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
-
@stephenw10 said in Am I being attacked?:
extremely unlikely
Most likely an understatement IMO... More likely to get hit by lightening as you were cashing your winning mega millions lottery ticket ;) On a clear sunny day..
-
Yup, an attack is extremely unlikely because the chances of it even getting to the target host are basically zero. So why bother.
Steve
