IPS Sensor Being Applied to Internal Host

[TopJimmy]

Hello all! I' m running into a little problem recently and I' m not sure why it' s happening. Here is the scenario: I have an inbound webserver policy (just http and https) to a couple of webservers and I also have a " webserver" IPS sensor applied to it. One of the matched signatures is the OpenSSL.TLS.HeartBeat.Information.Disclosure signature and I have that set to quarantine the source IP for 1 week. Everything is working normally until last week when I start getting alert emails from my FAZ saying that my Webserver has been quarantined. Looking at the logs I see that the xxx.xxx.xxx.xxx IP (src) is the address of our webserver and the dst IP is some address on the Internet. Immediately I' m thinking that the server has been compromised and is attempting to " hack" other servers on the Internet. We then isolate the server and scan it with every known tool and it comes up clean which I thought it would. Server admins prove that they' ve patched the heatbeat vulnerability the week it was disclosed. So then I look at the traffic logs and the traffic logs have the traffic originating (src) on the Internet and ending (dst) on our server however the attack logs are showing it in reverse and because I quarantine attackers IP address, it " bans" our IP. It' s not only that webserver, it' s others including a Internal server that has an external VIP associated with it. Here is the Attack Log for this " attack" showing my IP (xxx.xxx.xxx.xxx) as the source which it is not: --------------- 2014-06-25 13:52:33 log_id=0419016384 type=ips subtype=signature pri=alert severity=critical carrier_ep=" N/A" profilegroup=" N/A" profiletype=" N/A" profile=" N/A" src=xxx.xxx.xxx.xxx dst=96.47.226.20 src_int=" port3" dst_int=" port1" policyid=54 intf_policyid=N/A identidx=0 serial=190410668 status=reset proto=6 service=54439/tcp vd=" root" count=1 attack_name=OpenSSL.TLS.Heartbeat.Information.Disclosure src_port=443 dst_port=54439 attack_id=38307 sensor=" IPS-Sensor-Servers-DMZ" ref=" http://www.fortinet.com/ids/VID38307" user=" N/A" group=" N/A" incident_serialno=1705129081 msg=" applications: OpenSSL.TLS.Heartbeat.Information.Disclosure," ---------------- Here is the Traffic log of the " attack" showing my IP as the destination which is how it should be: ---------------- 2014-06-25 13:52:33 log_id=0021000002 type=traffic subtype=allowed pri=notice status=accept vd=" root" dir_disp=org tran_disp=noop src=96.47.226.20 srcname=96.47.226.20 src_port=54439 dst=xxx.xxx.xxx.xxx dstname=xxx.xxx.xxx.xxx dst_country=" United States" src_country=" Anonymous Proxy" dst_port=443 tran_ip=N/A tran_port=0 tran_sip=N/A tran_sport=0 service=443/tcp proto=6 app_type=N/A duration=1 rule=54 policyid=54 identidx=0 sent=597 rcvd=5176 shaper_drop_sent=0 shaper_drop_rcvd=0 perip_drop=0 shaper_sent_name=" TS-Servers" shaper_rcvd_name=" TS-Servers" perip_name=" N/A" sent_pkt=7 rcvd_pkt=7 vpn=" N/A" vpn_type=UNKNOWN(65535) vpn_tunnel=" N/A" src_int=" port1" dst_int=" port3" SN=190410668 app=" N/A" app_cat=" N/A" user=" N/A" group=" N/A" carrier_ep=" N/A" profilegroup=" N/A" subapp=" N/A" subappcat=" N/A" ---------------- The simple fix for me was to delete the quarantine from the sensor and then delete the " Banned User" but ultimately I need to figure why all of a sudden this started happening. Literally nobody was in the firewall on the day the problem started and no configuration changes were made. The only thing I noticed was a scheduled auto update to the IPS and AV engines but I' m not sure how that could be the source of this problem. Any suggestions would be much appreciated.

[TopJimmy]

Whoops...I forgot: Model: Fortigate FGT600B FortiOS: 4.3.15 (build 0672) We are getting ready to move to 5.0.x in the next couple of weeks on this unit. All my other FGTs are running 5.0.7 already.

[ShrewLWD]

Hi TopJimmy, Unfortunately, there is only a partial answer, -it is seeing traffic matching attempts to compromise a website using Heartbleed, coming from your webserver. I have over 200 Fortinets, almost all on 4.3.15, and when they made that update, it caused complete chaos across our data network, as if millions of voices suddenly cried out in terror, and were suddenly silenced! For whatever reason, random (legitimate) outbound HTTPS traffic was found to contain sufficient data to match what this Heartbleed signature was looking for, so it got flagged. What was worse for us was that; 1) it was listed as critical 2) while it was defaulted to Detect (not drop), we had set all Critical to Quarantine (for 5 minutes), so 1,000s of our users suddenly found themselves blocked with a loud IPS alert message! Fortinet TAC was not able to give me an answer, nor assist us in developing a way to overcome this, so we ended up changing our UTM profile to not detect Heartbleed for outbound traffic. Sad, but I guess it is the lesser of two evils. In your case, especially if your webserver is being VIP' d, your outbound traffic is using the same rule, so you may have to do the same..patch and verify you don' t have heartbleed, them remove the heartbleed signature from your UTM inspection.

[TopJimmy]

Thanks for the info. I wonder if 5.0.x has the same issue. This A-P cluster is the last of our units on 4 and is slated for upgrade in the next week or so. I may escalate the upgrade due to this issue as long as 5.0.x doesn' t have it.

[ShrewLWD]

It does. My 100D runs 507 and I had to turn off hearbleed checking too. :-( For some reason (possibly sloppy browser code?), some HTTPS requests are sent to a site with the flags in the packets, making it look like an end user is actively attacking a website. I don' t have enough insight into what specifically it finds, so I just removed it. If we end up inadvertently hacking another site, C' est la vie. Maybe someone else here on the site has found a way around it.

[Nihas]

According to their release note they have fixed the SSL Heart bleed issue in 5.0.7

[lightmoon1992]

best practice is to enable strong cryptography on the FortiGate itself as all 5.0.x releases are vulnarable till P7. this is pretty important if you have internet facing interface with https or ssh administration allowed # config system global (global) # set strong-crypto enable

[netmin]

When this issue came up for the first time, a custom signature was posted on Fortiguard and it was specified as " --src_port 443; --flow from_server,reversed" , which explains the attack direction (disclosure). Normally, " reversed" would lead to client ip quarantine. Taking a look at the current IPS signature on the FGT, the target is specified as client AND server, so this signature now appears to work bi_directional and if documentation is correct, this can' t be reversed -> the attack source is quarantined (either client or server, depending on detection). If the current signature is only in parts similar to the custom one, the test pattern (encrypted data) is relatively short and given that the entire stream is scanned, it provides the potential for higher numbers of false positives as already observed. Likely the reason it is not set to block by default.

[ShrewLWD]

Hi netmin, I agree with your assessment, but need to add, the ' quarantine attacker' feature kicks in regardless of status, so even ' Detected' is sufficient for the quarantine to kick in. The only way to continue using the quarantine function is to create an IPS policy that explicitly removes that rule from the sensor, and then apply it (to an outbound traffic firewall policy).