Juniper SRX IDP Attack Log Investigation

Last week I fiddled with the IDP functionality on my SRX100H. I eventually installed a modified version of the so-called "Recommended" IDP policy. The full Recommended policy consumes to much memory on the SRX100H, so I had to remove some rules.

After installing the IDP policy I 'configured' Splunk to run reports on IDP Attack Events (IDP Attacks in the last 24 hours). This way I have a nice overview of the detected attacks.

Today I checked the logging, and to my surprise I found several IDP_ATTACK_LOG_EVENT entries in the log. This triggered my curiosity a bit.

View fullsize

Thankfully I use an NTP server for syncing all the devices around the house, so working backward shouldn't be too hard. 

The IDP event was triggered by my iMac which had the 192.168.1.109 IP address at the time (hurray for DHCP logging). The reported exploit (HTTP:XSS:HTML-SCRIPT-IN-URL-VAR) is basically website related, so I started to dig through the browser history. Turned out that I visited the Victorinox website at the time looking for winter coats. During my visit at the website I tried to find a local store where they sell these items, but for some reason the 'Store Locator' thingy on the website didn't work. Now the logging explained why it didn't work.

It looks like they use a map-service (hosted on the destination address 199.16.46.10) in combination with some cross-site-scripting to deliver the functionality.

View fullsize

I tested this again, and indeed, every time I go to that website and try to locate a store, the same IDP_ATTACK_LOG_EVENT occurs.

In this case the cross-site-scripting (XSS) is relatively harmless. The use it to display a map with possible stores based on your query. Unfortunately, there are numerous other scenario's where this (XSS) isn't harmless. 

Quick And Dirty Juniper SRX IDP Test Config

When implementing a SRX IDP (Intrusion Detection and Prevention) configuration, you may want to check if everything is working properly. The 'default' templates supplied by Juniper can't be tested easily, since they protect your network from very specific attacks. Chances are small that you'll see one while you're testing. 

I usually use a simple ICMP-TEST policy which will drop all ICMP traffic, and logs the event to a local file (for basic testing, but you'll want to forward these events to a syslog server).

IDP Config: 

set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match from-zone any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match source-address any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match to-zone any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match destination-address any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match application default
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match attacks predefined-attacks ICMP:INFO:ECHO-REPLY
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match attacks predefined-attacks ICMP:INFO:ECHO-REQUEST
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 then action drop-packet
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 then notification log-attacks alert
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 then severity critical
set security idp active-policy ICMP-TEST

Add the IDP to the appropriate firewall rules and verify that your ICMP (ping) packets are being dropped.

Firewall rule example: 

set security policies from-zone trust to-zone untrust policy trust-to-untrust then permit application-services idp

If your ICMP packets aren't being dropped while 'pinging' to Google DNS (8.8.8.8), you dit something wrong :-)

View fullsize

Verification of IDP functionality in Splunk.