How to block https links?

Help
1

I am running an inline Suricata IDPS with AF-PACKET.

There are a lot of phishing or malicious Facebook pages and shortened URL links that I cannot simply to block the domain names due to those domain names are famous to public.

I tried SSLProxy but it requires Suricata’s IP address and port. However, my Suricata do not have those.

I also tried lua script and rules to block the links. However, it only works for non-encrypted traffics (http) only.

How can I block the those SSL/TLS phishing or malicious links?

2

I did get this somewhat working with sslproxy years ago. IIRC they bundle a simple tool to forward the traffic, and then I could hook up Suricata to use NFQ to pass/drop the traffic between sslproxy and that tool (I forgot its name). It worked with some issues, like the IP addresses being from the connection between sslproxy and the tool.

I did a WIP branch years ago to try and support it better, by parsing the embedded magic headers, but that is quite stale right now. I plan to revisit it some day. See

3

Thanks for the information.

Will Suricata be supporting SSLProxy in the future?

4

I cannot make SSLProxy to work with Suricata NFQ. Any hints, thank you.

5

you first have to make it work w/o suricata. Then there will be a tcp connection between the sslproxy tool and it’s forwarded application. You can create nftables/iptables rules for that connection, and use nfq to allow suricata to accept/drop on it.

Do you have it working w/o suricata?

6

The SSLProxy compiled properly and working without suricata. I can run it in debug mode too.

However, it cannot work with Suricata.

My iptables is as the following :

iptables -I FORWARD -j NFQUEUE --queue-balance 0:3
iptables -I INPUT -j NFQUEUE --queue-balance 0:3
iptables -I OUTPUT -j NFQUEUE --queue-balance 0:3
iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

My SSLProxy command is :

sslproxy -k /etc/sslproxy/ca.key -c /etc/sslproxy/ca.pem -l /var/log/sslproxy.log -J -w /etc/sslproxy/forge -P -I eth0 -e iptables -D https 127.0.0.1 8443 up:8080 ua:103.73.77.1 ra:103.73.77.1

Furthermore, you mentioned “forwarded application”, what is it? The UTMFW?

Any idea?

7

I know that this is an old thread, but as the developer of SSLproxy I couldn’t resist to reply. I bet you have already moved on, so I hope this helps those other users who ask the same question.

Victor is talking about lp, the listening program you can find under the tests folder in the source code.

What he means by the “tcp connection” is the decrypted traffic between sslproxy and lp. Basically, sslproxy decrypts the encrypted traffic and diverts (sends) it to lp, which parses the SSLproxy line in the first data packet and returns all packets to sslproxy to be reencrypted and sent to their original destination.

So, what you need to do is to divert (again) those decrypted packets to Suricata before they reach lp. How you do that depends on the packet filtering system. UTMFW runs on OpenBSD, so it uses divert sockets with pf. So, you need to do the equivalent of that with iptables on Linux.

But, note that the decrypted packets on UTMFW are on the loopback connection. The command line you have posted is trying to use remote listening programs, so your setup may be harder to configure. So, I’d recommend working on the loopback interface first (and be careful with remote listening programs, because the traffic in sslproxy → Suricata → lp → sslproxy is decrypted, that is I wouldn’t sent it to the Internet).

Once you achieve that, you should actually have Suricata running in IPS mode and it will be receiving decrypted packets from sslproxy. So, now you can write IPS rules to block those https links.

And lastly, I recommend this PreSuricon Webinar too.