malware outgoing blocked - help to interpret firewall log entry
-
I have a rule on WAN port firewall to block (not reject!) incoming and outgoing traffic coming from / going to a list of known malicious IPs (dynamically updated). The outgoing traffic is logged, as I want to know about any traffic going to such a malicious location.
Additionally, I have a port forwarding rule that forwards all web traffic (ports 80, 443) to the webserver that has an internal IP (non-routable, RFC 1918). Currently there is no webserver though, but the rules are still in place. There is no other server with the forward-to IP address of the webserver, so any traffic to the webserver is going nowhere. The default rule to block RFC 1918 incoming traffic is also enabled, but had no hits yet.
Now I see in the firewall log the following blocked traffic:
from: malicious IP from the list
to: internal IP of the webserver
rule: outgoing traffic on WAN
protocol: TCP:AWhat is happening there? Is that just the reply from the pfSense device that is being blocked? And why would pfSense reply if there's already an incoming rule that is blocking it? Is the port forwarding rule circumventing the incoming firewall block rule?
-
@e4ch firewall rules apply to incoming traffic on an interface, except floating rules can have a direction. So it’s very unclear. Post a screenshot of your rules?
To block outgoing to the malicious IPs add your rule on LAN.
-
@SteveITS This is the rule:
Firewall Rule:
- Action: Block
- Interface: WAN
- Address Family: IPv4
- Protocol: Any
- Source: Any
- Destination: Alias [URL Table (IPs)]
- Log: yes
- Description: Malicious out WAN
But you're right, yes, for blocking outgoing traffic, I should probably define this on the LAN Interface (and also on the OPTn Interfaces). Or better maybe as a floating rule, as it should apply to every Interface. But anyway, the way it is defined right now, what does this now block actually?
-
@e4ch not sure, actually. This:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html
…is usually on the default block rule.Response packets are not blocked if there is an open state/connection. It’s assumed if the connection is allowed the response is allowed.
Possibly from pfSense but again there’s no outbound on an interface rule. Maybe pfSense localhost? (DNS lookup etc)
-
@SteveITS said in malware outgoing blocked - help to interpret firewall log entry:
@e4ch not sure, actually. This:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html
…is usually on the default block rule.Response packets are not blocked if there is an open state/connection. It’s assumed if the connection is allowed the response is allowed.
Possibly from pfSense but again there’s no outbound on an interface rule. Maybe pfSense localhost? (DNS lookup etc)
Well, it cannot originate from pfSense itself, because in the log it says the source is the malicious IP.
Example log entry:
- Action: block
- Time: Nov 26 16:54:40
- Interface: WAN
- Rule: Malicious out WAN
- Source: 43.241.72.160:37904
- Destination: (private webserver IP):80
- Protocol: TCP:S
(the latest entries are of protocol TCP:S, but I've also seen TCP:A as mentioned earlier)
This cannot be DNS from the pfSense itself or anything like that.
I've now also defined the same blocking rules+logging on the LAN Interface. If there's really any outgoing traffic from my net, I should start seeing that in the log, but so far there is nothing and I do have new entries from the WAN.Maybe I should do a packet capture and look at the details. Currently there are quite a lot of those.
-
Show a screenshot of your rules or better of all the rules.
-
@e4ch said in malware outgoing blocked - help to interpret firewall log entry:
[...] This is the rule:
Firewall Rule:
- Action: Block
- Interface: WAN
- Address Family: IPv4
- Protocol: Any
- Source: Any
- Destination: Alias [URL Table (IPs)]
- Log: yes
- Description: Malicious out WAN
[...]
Here the same as screenshot for @Bob-Dig :
-
I did get a packet capture. Offending IP was 27.111.82.74 and I can see five TCP:S entries blocked in the log. I got the first four in the packet capture.
Opening this with Wireshark, I can see that the first is a SYN packet and the next ones are TCP Retransmissions.
Just a SYN is probably some port scanner.
Source port is 56744, destination port is 80, so it gets port forwarded to the non-existing webserver.I can see that the destination IP is my external IP, but in the log it's the private webserver IP.
So I think I now understand what happens: The incoming block rule gets circumvented due to the port forwarding rule. Then the data gets forwarded to the webserver and the WAN outgoing rule triggers. In the log we still see the source=bad ip, while the rule that triggers is the destination=bad ip, probably due to confirming the sender the forwarding or something.
-
@e4ch Your rule is an incoming rule on WAN that is logged. Everything works as expected. There is nothing special about this. You seem to have a problem understanding the Rule Methodology.
-
@Bob-Dig said in malware outgoing blocked - help to interpret firewall log entry:
@e4ch Your rule is an incoming rule on WAN that is logged. Everything works as expected. There is nothing special about this. You seem to have a problem understanding the Rule Methodology.
Would you care to explain then?
As mentioned, I have another rule (no logging) on the same WAN Interface for incoming traffic (Source=bad ip list, Destination=any). I would expect that rule to trigger on incoming traffic, but seems it does not.
This rule is on WAN for Source=any and Destination=bad ip list. Why would you declare this as incoming rule?
The source ip is one of those bad IPs, but the rule with Destination=bad ip is triggering. Maybe there is indeed something I don't understand.
-
@e4ch All rules are inbound rules (to the firewall) always. Only exception are floating rules, they can be modified but they should be used as little as possible. You don't mention floating rules so you probably aren't using them, which is advised.
Again, show all your rules as a screenshot but not in detail, all in one screenshot per interface is fine.
-
So a screenshot of a specific rule is not very helpful - show full list of your rules on wan/floating and lan if you have something specific on that your trying to block..
Example..
-
Here's the screenshot of the WAN rules:
There are three identical rules with different aliases in use. Three for incoming, and another set of three which is unclear which I originally thought was outgoing.I have no floating rules currently.
I cannot share all the LAN rules (many pages), but there are no rules related to the malware aliases from above. Only today I added that as well to make sure outgoing traffic to any malware IP is blocked on the LAN as well.
So coming back to the original question when you say all rules are incoming (from firewall view) rules. What does an incoming rule on the WAN Interface with Source=Any and Destination=external_bad_IP_list then do if it's an incoming rule? Especially if there is another rule first that would block such incoming traffic.
-
@e4ch not helpful to be honest.. looks like gov secret doc.. So alias that malware are they the same alias? If they contain public IPs then that rule there where its destination is never in a million years going to trigger..
How can help figure out if that is going to trigger or not? with destination blocked? Is that your wan IP? in both? Use the wan address if that is what you want. If that is blocking into your wan. Then your 2 allow rules will never trigger
Where is floating? Where is lan
Rules are evaulated as they enter your wan.. You can't stop something on your network with a wan rule, you need to put that on the interface they are connected too, or create an outbound rule in floating
-
not helpful [...]
There are just three different blocklists. I don't want to share publicly which blocklists I'm using. But yes, all are public IPs. For example 43.241.72.160 or 27.111.82.74 that I mentioned earlier is on the list. We can also disable four of these six rules and nothing to my question would change. The remaining two rules are:
- WAN Interface, Source=alias1, Destination=any
- WAN Interface, Source=any, Destination=alias1
(with alias1=43.241.72.160, 27.111.82.74, and more IPs)
I understand that the first rule is correct and blocks the incoming traffic from blacklisted external IPs. The question is about the second rule there.Where is floating? Where is lan
As mentioned, floating is empty. LAN rules don't matter here, assume no blocking rules for now.
You can't stop something on your network with a wan rule, you need to put that on the interface they are connected to, or create an outbound rule in floating
fully understood
So alias that malware are they the same alias?
Not sure what you mean there. Do you mean if it's the same alias for both rules? yes, they are the same alias.
If they contain public IPs then that rule there where it's destination is never in a million years going to trigger.
It does trigger, as the rule is named in the log as being hit. You see that rule has logging enabled from the icon. You can also see it in the screenshot above where it does NOT say "0/0 B", but has some values instead ("0/19 KiB"). And that's exactly my question. Why does it hit, if incoming traffic is already filtered (previous rule above with alias on Source) and we're only filtering incoming traffic on WAN interface. What does such a rule do? It might be wrong, but it obviously does block something.
-
@e4ch said in malware outgoing blocked - help to interpret firewall log entry:
It does trigger,
No its not triggering
if that alias contains bad sites.. How would that ever be destination into your WAN IP? It can't be, so no that rule could never trigger..
How could say a destination of say 1.2.3.4 some bad site on the internet ever come into your wan that is say 4.5.6.7 - its just not possible..
-
@johnpoz The one below says "0/19 KiB". It's just a different alias than the one you highlighted. That's actually the one that contains the mentioned IPs and is in the logs. So that one is triggering. That's what the question is about.
-
@e4ch the one you have hidden to what the destination is - if its not an IP on your wan, or a alias on your wan.. Then its not going to trigger unless your just seeing some broadcast traffic etc..
That traffic has to be inbound into your wan for any of the rules to trigger on the wan.. What is the destination? If its an alias and it contains your wan IP then sure it could trigger.. What is in the alias?
Source=Any and Destination=external_bad_IP_list then do if it's an incoming rule?
That rule would do NOTHING.. rules on your wan are inbound traffic to you wan.. Its not going to trigger unless your wan sees it as inbound traffic.. How would traffic for 1.2.3.4 hit your wan if its 4.5.6.7?
Depending on what might be in that alias - maybe its broadcast traffic.. Show us the log entry - what is the destination.
And it not going to ever do anything either if your client is allowed to talk to the bad IP, any return traffic would be allowed via the state..
Again that alias if has bad Ips would never be inbound traffic into your wan as destination - and even if your IP was in the alias, the return traffic would be allowed, unless your states were reset.
-
I might wonder if the rules aren’t loading as expected, try (IIRC) Diagnostics/Filter Reload.
-
I found the problem.
The one that did trigger was actually the FireHOL level 1 firewall blacklist. Not sure yet if I want to keep that (http://iplists.firehol.org/). It's one of the well-known blacklists, but has a problem.
That list contains all private IPs like 10.0.0.0/8 and 192.168.0.0/16 too. You probably already see where this goes.
So what happened is this: The incoming request is a port scanner for port 80 or 443 or a regular web request. Then the first alias block rule does not trigger, because the sender is not on the blacklist. The IPs mentioned earlier (43.241.72.160 and 27.111.82.74) are actually on none of the lists - I just verified. So they are legit.
Then the port forwarding rule applies and changes my external IP (the destination) to the webserver IP, which is on my private network (RFC 1918 address). Then the second (invalid and useless) rule where the blacklist is on the destination fires, blocks the incoming traffic that should go to the webserver and logs the request. As there is no webserver, this was never noticed (it blocks essentially all web traffic).
So I'll just delete the second rule (those three that you mentioned that will never fire in a million years). They did fire, but only because private IPs are on that blacklist.
As I want to block outgoing traffic to malicious IPs too (in case there's a C2 server), I have to add that on the LAN port with Destination=alias - that is understood. But if such a blacklist now contains private IPs, that might be a problem when internal traffic must go through the firewall (like from LAN to OPT1 or so). I might need a better blacklist or just use the remaining two lists.
Thanks for helping.
