2

I am running an IDS on the outside of my firewall (I know not ideal) and an IDS on the inside of my LAN running the same detection algorithms and definitions. My website auto redirects all HTTP requests to HTTPS. My IDS frequently detects nmap scans, OpenVAS scanning activity, GNU Bash Environment Variable Code Injection attempts, etc on the inside of my LAN that is not seen or blocked by my IPS on the outside of my network. I assume this is because these attacks come in encrypted using my own SSL and since my IPS on the outside does not host my SSL certs it cannot see these attacks. The traffic is decrypted on my LAN by a load balancer that hosts the SSLs prior to passing the traffic to IIS Servers and this is where the IDS detects the attacks.

My only conclusion based on the the lack of detection of these attacks are that the packets are entering our network encrypted with our own SSL certs and is therefore "invisible" to the IPS.

Is it possible, or maybe even common, for these exploit attempts to use a targets own SSL certificates to avoid detection?

CptnKeith
  • 23
  • 5

3 Answers3

2

Yes this is a known issue, you can also route all sorts of attacks to servers via a variety of encrypted protocols using SSL/TLS client-side proxies, or other client side services just to make attacks easier. This does create a situation where on some networks attacks against an http listener would not be effective (detected/blocked by a security control) but attacking the equivalent https listener would be very effective because it would not be detected/blocked. In some cases you'll also bypass other security controls such as the firewall's inspection capabilities.

Similarly attackers may have more success attacking things like SSH daemons, VPN's, or SSL/TLS encrypted services like mail servers for the same reason.

Note: you can also add decryption capabilities to your IDS/IPS, or other device, or simply change it's architectural placement to deal with this issue. some devices will even terminate the SSL session, inspect it then create a new ssl session to the server. There are many ways to work around this issue as a defender and yes you've discovered the problem first-hand.

Trey Blalock
  • 14,099
  • 6
  • 43
  • 49
0

Looks like you already have a Load Balancer that hosts the certificate on behalf of your web servers so inbound SSL can be inspected after they are decrypted. Your load balancer should have a public facing interface to decrypt your own SSL cert so your IPS can inspect.

However for outbound, your clients directly connects to a public website which may be malicious. In this case, you couldn't decrypt this traffic to scan for malicious signatures from your IPS.

One of the ways to deter such inbound web threats is prevention. And can be done through URL filtering and IP intelligence followed by a last line of Defence with end point protection software.

Davis
  • 49
  • 3
  • Our load balancer is a virtual appliance so placing a IPS in between it and our IIS servers (also VM's) presents a routing challenge since they reside on the same subnet (DMZ) and occasionally the same virtual hosts. I am researching some WAF options to help detect and block these attacks. Currently, our end-point security on our IIS servers does detect and block a good number of attempts but the more layers the better. – CptnKeith Jul 21 '16 at 13:16
0

End point protection may not be sufficient and is often seen as a last line of Defence.

You need a WAF solution yes.

May I ask specifically what routing challenges do you face within the same subnet? Default gateway issue that may by pass return traffic away from a LB or IPS?

To minimise the impact of so many network appliances, you can choose WAF, LB, Firewall, IPS solutions that sit on a single appliance such as F5. If you are due for a tech refresh you can consider that.

I know of a company who uses F5 to house almost every network solution. Very rare but i guess they have some serious Budget constraint.

Davis
  • 49
  • 3