REDELIJKHEID
When you have a registered Juniper UAC / IC appliance, you have to option to download a VMWare version of the system. This is called a DTE appliance (Development and Test Environment). With this you have a full-blown UAC at your disposal for testing and development. Only downside is that it's limited to 5 connected users. Apart from that, it's just like the real-deal.
A while back I wrote a blog post about enabling global logging on security rules. This week I applied the same technique to enable ping on all zones for testing / troubleshooting purposes.
Instead
of adding ping as a host-inbound-traffic system-service to all zones,
and if you have a couple this means some configuring, you can solve this
by adding just 3 (three) lines of config to the firewall.
Juniper entered the realm of
application firewalling since the release of Junos 11.4 (for SRX
platforms). A realm that is mainly dominated by Palo Alto (they
basically invented it) and Checkpoint, but more and more vendor's are
starting to move in on that territory.
And Juniper is one of those vendors that started to implement Application Firewalling (AppFW) on their (SRX) firewalls.
Since the release of Junos v12.1x44D10 for branche SRX firewalls, Juniper added a feature called DNS-Proxy. This features enables the Junos device as a caching DNS server with several additional options. One of those feature is to define a Fully Qualified Domain Name (FQDN) with an IP address which overrides (if it exists) the entry in the 'official' DNS system on the Internet.
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.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).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.
When you create (SSL)VPN access for you employees, you might enable split-tunneling to save corporate bandwidth. No split-tunneling means that all traffic is forwarded into the VPN tunnel. So if you browse the internet with an active VPN, the traffic goes through the VPN, and accesses the Internet through the corporate Internet connection. This isn't a big problem with a couple of employees, but with hundreds on the road or working from home, this might frustrate the employees in the building.
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
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.