pfSense Gold Subscription

Author Topic: HAproxy SSL termination & Snort  (Read 151 times)

0 Members and 1 Guest are viewing this topic.

Offline tohil

  • Jr. Member
  • **
  • Posts: 48
  • Karma: +1/-0
    • View Profile
HAproxy SSL termination & Snort
« on: December 28, 2017, 01:58:56 am »
Hi Guys

I have the following config:

HAProxy

Frontend: SSL Offloading, Type: http/https Offloading, Public Cert
Backend: Adress+Port 443, SSL yes

Snort

active on WAN Interface


the question is: is snort able to scan the content of the https traffic, during decrypted phase on haproxy?

regards

Offline PiBa

  • Hero Member
  • *****
  • Posts: 819
  • Karma: +132/-1
  • PiBa-NL(on IRC)
    • View Profile
Re: HAproxy SSL termination & Snort
« Reply #1 on: December 28, 2017, 05:06:29 pm »
As decryption and encryption both happen 'inside' the haproxy process i don't think so.. Afaik it only 'intercepts' network traffic..

Offline bmeeks

  • Hero Member
  • *****
  • Posts: 3225
  • Karma: +835/-0
    • View Profile
Re: HAproxy SSL termination & Snort
« Reply #2 on: December 29, 2017, 08:16:45 am »
@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

« Last Edit: December 30, 2017, 09:33:18 am by bmeeks »

Offline tohil

  • Jr. Member
  • **
  • Posts: 48
  • Karma: +1/-0
    • View Profile
Re: HAproxy SSL termination & Snort
« Reply #3 on: December 29, 2017, 08:44:02 am »
@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

Offline PiBa

  • Hero Member
  • *****
  • Posts: 819
  • Karma: +132/-1
  • PiBa-NL(on IRC)
    • View Profile
Re: HAproxy SSL termination & Snort
« Reply #4 on: December 29, 2017, 09:15:53 am »
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...

Offline tohil

  • Jr. Member
  • **
  • Posts: 48
  • Karma: +1/-0
    • View Profile
Re: HAproxy SSL termination & Snort
« Reply #5 on: December 29, 2017, 09:50:48 am »
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