Am I being attacked?
-
@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
-
@johnpoz I mean, this is how phishing emails work! =) Sorta like when an attacker has a foothold or access to an internal network and performs relay attacks against smb and other protocols to serve fake logins (e.g. Responder). I was just curious though if it was a known thing for attackers to craft packets for this purpose. I'll take your word for it though that this type of spoofing shouldn't be something to be concerned about from a security perspective!
-
@spookymonkey a state bypass attack by spoofing the IP and source port along with sequence numbers and timestamps is not how "phishing" emails work ;) heheh
You clicking a link in some email that you think is your bank asking you to "verify" info has nothing to do with spoofing an IP..
-
@stephenw10 That makes sense, much easier to get a user to execute a payload than playing the packet lottery as @johnpoz likes to call it =)
-
@johnpoz Lol, true.
-
@spookymonkey if your interested in ways to bypass a firewall.. Here is a method..
Keep in mind the server on the victim network was already exploited, and the firewall allowed legit traffic to it... The bad software on the server behind the firewall was just leveraging the open path to pass traffic back and forth to the bad guy via the already open gate.. Looking like legit traffic.
Something like this a ips might be able to catch such bad traffic - but quite often this traffic is inside a https tunnel, that IPS would not be able to see..
-
@johnpoz said in Am I being attacked?:
@spookymonkey if your interested in ways to bypass a firewall.. Here is a method..
Keep in mind the server on the victim network was already exploited, and the firewall allowed legit traffic to it... The bad software on the server behind the firewall was just leveraging the open path to pass traffic back and forth to the bad guy via the already open gate.. Looking like legit traffic.
Something like this a ips might be able to catch such bad traffic - but quite often this traffic is inside a https tunnel, that IPS would not be able to see..
The moral of this story (from the article) is don't open stuff like SSH on the WAN side of your firewall. The entire scenario outlined in the article @johnpoz linked started with a dictionary attack on the password of an SSH account that was allowed through the firewall over to the web server. Once the attacker was on the web server, it's pretty much game over at that point.
While it may be technically correct to say the traffic "bypassed the firewall", that is not really a fair way to describe the scenario in my view. The firewall was configured to allow HTTP(S) traffic, the "malware C2 traffic" was disguised as HTTP(S); ergo, the firewall allowed it. So "bypass the firewall" is not necessarily how I would characterize it.
This could have been prevented, or at least made much more difficult, by using certificate-based public key authorization with the SSH account on the web server; or even better, putting that remote access behind a VPN.
So while it makes for a nice sensational headline to say "bypass the firewall", the actual truth is a bit more mundane and common. Somebody allowed password-authenticated remote access through the firewall to trusted servers behind it. That was the original compromise path. After the attacker is inside your local network, you've lost the war.
-
@bmeeks said in Am I being attacked?:
The moral of this story (from the article) is don't open stuff like SSH on the WAN side of your firewall.
It should be don't use ssh with a password. Use passwordless ssh instead. Ssh supports that. You create a public/private key pair, to allow access.
