This post basically describes the technique of how to deal with traffic originating from the inside of a firewall, and directing the traffic over the external interface IP address to a different internal zone.
First a network overview of the things used in this setup.Filter / Block IP Addresses On A Juniper SRX
While exploring the configuration options on the Juniper SRX firewall, I stumbled upon the so-called firewall filters. These filters are not to be mistaken for the firewall policy rules. They are something different, but can be used for achieving similar goals.
In my case, I wanted to see if it was possible to quickly block a list of IP addresses (or subnets) without the hassle of creating addressbook entries (Address Sets). My list of IP addresses consists of known hosts that participate in the criminal ZeuS network. These IP addresses are either Command&Control servers or servers used to transfer (captured) data to. In any case, servers you don't want to communicate with.
The solution on the SRX is to create a firewall filter containing the list with hosts / networks. The filter, in my case, is applied to the outgoing interface (fe-0/0/0).Enable Global (Security) Logging On SRX Policies
Normally, one would enable logging on each security policy. If you have hundreds of policies, and you want/need logging for troubleshooting, it takes a while (and some serious) effort to enable this for all policies.
Ziggo Internet, Juniper Firewalls and DHCP
At the house I have currently two ISP delivering broadband. Well, broadband isn't the correct word, since the the one of them is only a mere 256kbps (I think). The other is a 'whopping' 20Mbps.
The 20Mb connection is provided by XS4ALL, and the 256kbps is for free (if you have a phone subscription with Ziggo). The 256kbp is the minimum they provide to transport the phone calls, but if you're a masochist you can also browse the internet over that connection.
So, two ISP @ home. Combine that with a Juniper SRX firewall, and a dual ISP setup is born. The theory of that setup is that I connect both ISP's to the firewall, and use the 20Mb line as a default internet connection, but when that one dies, I automatically get switched to the backup line (256kbps).
Adding Custom Logfile to OS X (Server) Log Rotation
The earlier posts on my logging experiences didn't include the logrotation solution I used on my OS X Server.
When you create a new logfile (and have syslog fill that file up), you're gonna run into a lack of space sooner or later. This happens because the syslog server keeps writing data to that file, and the system doesn't 'recognize' (read: isn't configured) the file for logrotation. So, you need to tell the logrotation process to include the new logfile (and what to do with it).
Dissecting SRX RT_FLOW Logs with Splunk
Now that I have a SRX running at home and a syslog server powered by Splunk (free version) it's time to be able to understand the logging. The raw logging is pretty unreadable for the average Joe. Thankfully, Splunk can be used to make more sense of it.
Downside is that I haven't found any add-ons / plugins etc. for Splunk to analyze the logging of a Juniper SRX firewall. There is a post on the Splunk forum which offers two regular expression which can be used to define the RT_FLOW fields.
Usefull Juniper SRX commands
This post contains several useful Junos SRX commands for the CLI. Mainly for myself, because I don't use those command regularly....
This post will be updated over time... Here it goes:
View session information:
root@srx100> show security flow session summary
Clear sessions through the firewall:
root@srx100> clear security flow session all
Switch to other node in a cluster via CLI (over the HA-link):
root@srx100> request routing-engine login node 1
Enable Juniper SRX Firewall Logging
Juniper started to migrate their firewalls from Netscreen to the Junos environment 'a couple of' months back. The advantage is that there's a universal OS for routers, switches and firewalls. Just like Cisco IOS. The disadvantage is that the Junos OS is being adapted for the firewalls. So the foundations are there, but there are still lots of features missing and bugs are also still abundant.
The bugs are thankfully mostly related to the WebGUI. On the commandlinethe bugs are in the same league as the Cisco, Checkpoint and every other vendor bugs. No piece of software is perfect.