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. 

I'm Published (sort of...)

Someone mentioned that they found a link to my website in a Juniper exam training PDF. Looks like I did a good job on describing the implementation of the Application Firewall feature in the Juniper SRX.

Here is the link to the actual article.

Google+ Custom URL

Google+ introduced a new (shiny) feature recently called Custom URL's. Up till now people had to communicate these long URL's if you needed to find someone on Google+. Mine for example is: https://plus.google.com/u/0/105217840082627216167/. Not a real slick way of presenting yourself on the Interwebs. When you log in to your Google+ account you get the option of getting one of those URL's for 'free'. It basically is your screen-name in the URL.

View fullsize

Mine would be http://google.com/+GuillaumeRaisonnable/. Would be, because, I'm not getting mine. The reason for this is that you need to leave your mobile phone number with Google for so-called verification purposes. By doing this I would be giving away another piece of privacy for something shiny. Something a lot of other people will be more than willing to do so. Just remember that the NSA never had it any easier since the arrival of social media to violate your privacy.

Sony A7(r) Mirrorless Full Frame Camera

View fullsize

Sony A7

Sony launched the A7(r) camera today. It's a full frame camera without a mirror (like a Leica M). Also known as an Mirrorless Interchangeable Lens Camera (MILC).
It was something I didn't expect (mainly because I'm not that into the Sony rumors). The release of a full frame E-mount camera startled me somewhat. Why? Because the E-mount cameras today (Sony NEX cameras) are well known to work with various lens mount adapters (e.g. Leica M-mount, Nikon F-mount, etc.).

This camera could replace my Nikon D300. I mainly use that camera for macro and the occasional telephoto. I can still use my Nikon lenses on this body through an adapter. Even my Leica M-lenses can be used. This could be the camera to rule them all (all being MY current cameras). It's light, small (smaller than the M9 or the new M type-240) and packs a lot of (photographic) power.

I know what I want for X-Mas

View fullsize

View fullsize

View fullsize

Steve Huff has some additional images from the camera in various setup's (mainly with Leica lenses :-)) 

Capture Network Traffic With Wireshark Under Ubuntu

When you install Wireshark on Ubuntu Linux you need to be root to be able to capture traffic. The standard user doesn't have enough privileges to do this. 

A workaround for this is to add the user to a wireshark group and give the group special permissions. Afterwards, you're able to cpature traffic in Ubuntu with Wireshark, without needing root access. 

The complete list of commands: 

sudo groupadd wireshark

sudo usermod -a -G wireshark <YOUR-USER-NAME>

sudo chgrp wireshark /usr/bin/dumpcap

sudo chmod 750 /usr/bin/dumpcap

sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

sudo getcap /usr/bin/dumpcap

Just reboot, or log out and back in, and you're finished. 

HAPPY CAPTURING

Under the Bridge

Shot this weekend with the Leica M9 and the 35mm summicron. I still love that camera.