Checking HTTPS traffic
-
Hi,
Playing with Snort and Suricata since few week and really like those tools.
Currently using Suricata inline mode on Pfsense 2.4.5-rc.I'm checking alert daily and found some attacks on HTTP 80 port (screenshot bellow), well blocked by suricata.
I suppose that attempt listed bellow is also made on 443 but not filtered by suricata because HTTP header can't be read.
I wonder if there is any way to protect HTTPS 443 port and traffic ?
Maybe with some additional tools install on Pfsense or in another server.
-
@Le_Bleu said in Checking HTTPS traffic:
I'm checking alert daily and found some attacks on HTTP 80 port (screenshot bellow), well blocked by suricata.
I suppose that attempt listed bellow is also made on 443 but not filtered by suricata because HTTP header can't be read.
I wonder if there is any way to protect HTTPS 443 port and traffic ?
Maybe with some additional tools install on Pfsense or in another server.They'll be blocked by the default firewall rules unless you port forward port 80 & 443.
-
Port 80 and 443 are forwarded to my web server.
-
HTTPS is encrypted traffic. That can't be inspected as it passes the firewall unless the firewall is configured using some third-party tool to become a MITM (man-in-the-middle) point where the encryption chain from your client is terminated and a new stream established from the firewall on behalf of your client. That rarely works without issues, though, as it obviously breaks the chain of trust that is the supposed bedrock of SSL (HTTPS).
No IDS/IPS tool can peer into the content of encrypted traffic. The traffic the IDS/IPS sees must be in plaintext in order for content payloads to be inspected. IDS/IPS tools can examine certain parts of the headers for issues, but in most cases the "bad stuff" with malware is carried in the payload. And if the payload is encrypted, then your IDS/IPS can't examine it.
As more and more traffic becomes encrypted from endpoint to endpoint, the traditional security tools such as Snort and Suricata and similar ones are becoming less useful.
-
That's confirm my though. Not good news but still better than no IPS at all for the moment.
About my webserver, maybe I can set reverse proxy with SSL certificate on pfsense then forward to my webserver encrypted HTTP. So every request can be inspected by IPS.
-
That's were the IDS might come in handy.
But ..... for security reasons you would NOT run it on a firewall / router.
This one acts only asthe traffic cop.
Place your reverse proxy just before your web server on a dedicated, isolated LAN. The reverse proxy will terminate the SSL traffic", exposing itself to the world as the "web server", it will unwrap the SSL traffic, inspecting (like border control) the content and passing on the traffic, it could even stay ordinary http because the ext hop = one cable away, will be the web server.IDS was nice add on ones, but then that new kid come on the block : TLS ....
