Intercept traffic on pfsense box using pfsense means
-
Dear pfsense community,
I am currently investigating on the following issue that I did not find any answer so far that would work in a pfsense environment. The goal is to work on (unencrypted) network traffic in order to let some requests pass (i.e., those that are well-formed) and discard others (e.g., service fingerprinting or attacks) in the specified network scenario (cf. Fig 1). The scenario consists of one network segment with servers and n network segments with clients in it. The firewall FW_C offers an OpenVPN-Server to which the other firewalls (FW_A, FW_B …) connect to via OpenVPN-Clients. One tricky part is that the firewall in the server segment (currently) is connected to the same switch as the servers and is not in between (which will be the case in a couple of month and cannot be changed right now).
The reason why I especially need your help is that I found many approaches that could be a solution, but quite all of them will not work due to some limitations in either, my understanding of proper network configuration, the options that can be configured in pfsense GUI, or both. For instance, using the configuration files or tools of “pf” or “ipfw” directly, offers opportunities (forward-to, divert-to, etc.) that seem to be impossible using the GUI (that overwrites config.xml which is used in favor of the other configuration files). I am pretty sure that this will work out fine with config.xml as soon as I know how to configure the entire setup properly.
Fig. 2 shows some insights of the firewall (FW_C) in the server segment. Currently, it only has one physical interface available. There is also the virtual network interface of OpenVPN (tun interface). The traffic (encrypted, vpn) comes in via the physical interface and leaves after decryption by OpenVPN via the same interface into the local server network segment. This actually works, but the plan is to analyze the incoming network traffic (vpn) at application layer and only forward those packets that are compliant to specific filters (e.g., payload lengths, etc.). This behavior is indicated by the blue dotted line; the traffic passes the filter and leaves to the local network to the servers and answers by the servers should directly leave via OpenVPN tunnel.
Given the scenario, and of course we could discuss hours if this scenario is useful at all, I tested various approaches found in diverse forums. To name some: libpcap on vpn/wan interface, causes loops after injection due to routing configuration. Snort, cannot block traffic that passes - only indicate that something went wrong and block clients afterwards. Dummynet, the pipes are not flexible and have to be used within dummynet implementation (otherwise would be exactly what I need). Tap/tun bridges, seem to work different (not at all) as I expect them to work (Act as a virtual switch connecting interfaces). Forward-to, divert-to firewall rules cannot be set in pfsense (pf). Real proxy-ing is not possible due to limitations of the application protocols inside. Tap/tun with routing is currently under test (application on tap/tun evaluates traffic and copies it to another interface). Due to lack of knowledge about proper configuration of NAT, I cannot say much about it, but I assume that this (IP-Forwarding) could be an approach, too. If there is any need for more information, I will be happy to provide them.
TLDR; is there a way to intercept and pipe arbitrary tcp traffic to an application that discards bogus and forwards real packets - within the bounds of pfsense distribution?
Thank you very much!
Mario
-
"Snort, cannot block traffic that passes - only indicate that something went wrong and block clients afterwards."
Where did you get that idea? Snort inline mode can for sure block traffic..
-
Hi johnpoz,
thank you very much for pointing me in the right direction. I will check out Suricata and Snort inline. I was not aware of such an inline mode (which sounds very promising) and the default configuration of snort in pfsense felt more like adding a clever sniffer on some interface. I will keep you updated - if someone has other ideas for this scenario, please let me know.
Cheers,
Mario
