HAproxy SSL termination & Snort
-
Hi Guys
I have the following config:
HAProxy
Frontend: SSL Offloading, Type: http/https Offloading, Public Cert
Backend: Adress+Port 443, SSL yesSnort
active on WAN Interface
the question is: is snort able to scan the content of the https traffic, during decrypted phase on haproxy?
regards
-
As decryption and encryption both happen 'inside' the haproxy process i don't think so.. Afaik it only 'intercepts' network traffic..
-
@PiBa is correct. Snort can't see the encrypted traffic (well, not in clear-text form). Snort uses PCAP, and you can envision it as getting a copy of every single packet that traverses the NIC. Snort is the first thing a packet sees after coming off the wire going through the NIC inbound into pfSense, and Snort is the last thing a packet sees before leaving the NIC on the wire outbound for the Internet. That description assumes Snort is running on the WAN.
If it helps in understanding the flow, just remember that Snort sees exactly what the NIC driver sees – raw packets coming and going off the wire. For inbound traffic coming from the WAN into pfSense this means before the firewall rules have been applied and any NAT removed (thus the "destination IP" will always be the WAN IP address). For outbound traffic going out on the WAN, Snort sees the traffic after the WAN firewall rules have been applied and NAT put in place (so the "source IP" will always be the WAN IP address).
So generally I recommend running Snort on the LAN interface so that the NAT stuff is not masking internal hosts. It's not helpful to have a dozen alerts from internal hosts attempting to communicate with a malware C&C server but all the alerts showing up on the WAN with just the WAN IP address as the source IP due to NAT. Much easier to find the infected hosts when Snort is on the LAN and the alerts have the actual pre-NAT source IP addresses of the infected hosts listed.
EDIT: for others reading this in the future, I need to add a clarification to the flow description above. Snort is getting copies of packets coming from and going to the NIC driver. It is not inline, but rather is on a parallel path so to speak. The original packet continues on to pfSense for processing while a copy of the packet is passed over to Snort for it to analyze.
Bill
-
@PiBa is correct. Snort can't see the encrypted traffic (well, not in clear-text form). Snort uses PCAP, and you can envision it as getting a copy of every single packet that traverses the NIC. Snort is the first thing a packet sees after coming off the wire going through the NIC inbound into pfSense, and Snort is the last thing a packet sees before leaving the NIC on the wire outbound for the Internet. That description assumes Snort is running on the WAN.
If it helps in understanding the flow, just remember that Snort sees exactly what the NIC driver sees – raw packets coming and going off the wire. For inbound traffic coming from the WAN into pfSense this means before the firewall rules have been applied and any NAT removed (thus the "destination IP" will always be the WAN IP address). For outbound traffic going out on the WAN, Snort sees the traffic after the WAN firewall rules have been applied and NAT put in place (so the "source IP" will always be the WAN IP address).
So generally I recommend running Snort on the LAN interface so that the NAT stuff is not masking internal hosts. It's not helpful to have a dozen alerts from internal hosts attempting to communicate with a malware C&C server but all the alerts showing up on the WAN with just the WAN IP address as the source IP due to NAT. Much easier to find the infected hosts when Snort is on the LAN and the alerts have the actual pre-NAT source IP addresses of the infected hosts listed.
Bill
Hi Bill
Thanks for your detailed explanation!It makes sense, because I can see a lot of Traffic on the WAN interface, which is blocked on the packet filter rules.
Benefit of having the WAN Interface in snort, that it can detect infected or malicous source adresses and put them on a block list.
when somebody is scanning my IP, snort detects this and blocks even the allowed traffic to HAproxy in advance…from a HAproxy design perspective, it should use a local virtual loopback interface to transfer the traffic from decrypt to encrypt process. and the ability to use this interface in snort or other security services.
regards and happy new year
tohil -
No, haproxy should not use localhost interface to transfer data from frontend to backend.
And though you could do this 'manually' client>frontend(decrypt)>backend>>frontend>backend(encrypt)>webserver , but well it would be a connection from 127.0.0.1 to 127.0.0.1, not sure if snort would be able to do anything useful with that.. wouldn't want it to block every connection from haproxy to haproxy when 1 alert is triggered..
Not sure how you picture how this 'should' work…
-
No, haproxy should not use localhost interface to transfer data from frontend to backend.
And though you could do this 'manually' client>frontend(decrypt)>backend>>frontend>backend(encrypt)>webserver , but well it would be a connection from 127.0.0.1 to 127.0.0.1, not sure if snort would be able to do anything useful with that.. wouldn't want it to block every connection from haproxy to haproxy when 1 alert is triggered..
Not sure how you picture how this 'should' work…
I understand what you mean :-)
Okay, i will leave the current HAproxy&SNORT config as it is.thanks
-
I was thinking about similar setup, haproxy + suricata
Frontend: SSL Offloading, Type: http/https Offloading, Public Cert
Backend: Adress+Port 80, SSL noNot sure about snort, but suricata can inspect openvpn interface. I would connect webserver via openvpn to pfsense. Traffic would be encrypten within vpn tunnel but it would be still http, which can be fully inspected by suricata
I tested it and it was worked. but i am not sure if there is any other security caveat i didn't count with, of course that vpntunnel would need to be extra secured.