Juniper recently released their AppSecure suite of tools for the high-end SRX units (1400, 3400, 3600, 5800). This is the piece of the puzzle that will give SRX visibility into the application layer in terms of monitoring and security polices. It will bring you over to the dark side and have you slapping “I love JUNOS” bumper stickers on your car…..okay maybe not, but the stuff is pretty cool.
I have been working with the SRX line of firewalls since they came out and have been hearing about AppSecure for quite some time. Well, I finally got my hands on an SRX-1400 (smallest of the high-end models) and threw on a trial license of AppSecure.
My SRX-1400
I wanted to fire up this blog to describe how to configure the AppFW part of AppSecure, and also show off a little bit of how it works. There is more information out there on how to build your own time machine, so I hope this may help a few people along the way.
More info on building this then AppSecure configs
Step one: Hook yourself up with some licensing
If you want to just try out features of an SRX unit, all you need to do is connect it to the Internet and configure a DNS server. Issue the following command, and you will receive an early Xmas/Hanukkah/Birthday/whatever you celebrate gift.
root> request system license update trial
root> show system license
License usage:
Licenses Licenses Licenses Expiry
Feature name used installed needed
idp-sig 1 1 0 2012-01-06 00:00:00 UTC
appid-sig 0 1 0 2012-01-06 00:00:00 UTC
logical-system 1 1 0 permanent
Step Two: Download signatures
Okay, now that we have the licenses, let’s get our updates. In our case, now we have both IDP and Appsecure, so downloading the IDP signatures will include the application signatures
root> request security idp security-package download
Verify the download status.
root> request security idp security-package download status
Done;Successfully downloaded from(https://services.netscreen.com/cgi-bin/index.cgi).
Version info:2050(Tue Dec 20 12:05:38 2011, Detector=11.6.140110920)
If you want to schedule automatic updates, add the line below (mine will update every 72 hours).
root#set security idp security-package automatic interval 72 start-time 12-21:02:00
Sweet business! I now have a ton (I weighed them) of signatures sitting on my box waiting to match and kick traffic to the curb. The current list of application is pretty good as can be seen here.
The SRX firewall is now ready to have policies defined to match based on application signatures and not just ports. The best way to demonstrate its application will be with an example:
I am an admin working at company De-motivation. We manufacture 90% of the Internet’s De-motivational posters.
Our Product
It is very important that my employees only spend their time working on posters and not chatting on MSN.
As we know, MSN is a pain to block since it port hops around and eventually goes out port 80 which is almost always open.
AppFW to the rescue! AppFW works by creating an application rulebase. This works on a whitelist/blacklist approach. We either allow a few things with a default action of deny or deny a few things with a default action of permit. If you have ever written an ACL this is nothing new.
In my case I only want to block MSN and permit everything else.
set security application-firewall rule-sets BLOCK-STUFF rule chat match dynamic-application junos:MSN
set security application-firewall rule-sets BLOCK-STUFF rule chat match dynamic-application junos:MSN2GO
set security application-firewall rule-sets BLOCK-STUFF rule chat then deny
set security application-firewall rule-sets BLOCK-STUFF default-rule permit
Here is an example if I wanted to only allow HTTP and block everything else:
set security application-firewall rule-sets ALLOW-ONLY rule outbound match dynamic-application junos:HTTP
set security application-firewall rule-sets ALLOW-ONLY rule outbound then permit
set security application-firewall rule-sets ALLOW-ONLY default-rule deny
Here is what it looks like in the classic JUNOS look:
Ahhh...JUNOS
I will now go back to my original policy and add the extra command to actually look at the application signature.
set security policies from-zone inside to-zone untrust policy main match source-address any
set security policies from-zone inside to-zone untrust policy main match destination-address any
set security policies from-zone inside to-zone untrust policy main match application any
set security policies from-zone inside to-zone untrust policy main then permit application-services application-firewall rule-set BLOCK-STUFF
set security policies from-zone inside to-zone untrust policy main then log session-init
set security policies from-zone inside to-zone untrust policy main then log session-close
A GUI look at the policy
The traffic will be inspected as it passes this policy. Attempting to launch MSN messenger fails.
FAIL
Here is another example, where I try to launch my FTP client to my FTP server listening on port 80. As you can see from the log below, my feeble attempt at hiding ftp on port 80 is found and blocked.
root> show log policy_session | match deny
<14>1 2011-12-22T14:10:24.800Z – RT_FLOW – RT_FLOW_SESSION_DENY [[email protected] source-address="192.168.50.14" source-port="51810" destination-address="192.168.0.244" destination-port="80" service-name="junos-http" protocol-id="6" icmp-type="0" policy-name="APPSECURE" source-zone-name="inside" destination-zone-name="company" application="FTP" nested-application="UNKNOWN" username="^RM-^M^HM-^@" roles="^E" packet-incoming-interface="ge-0/0/1.0"] session denied 192.168.50.14/51810->192.168.0.244/80 junos-http 6(0) APPSECURE inside company FTP UNKNOWN ^RM-^M^HM-^@(^E) ge-0/0/1.0
This example may be a little extreme, but think of the value of this, especially on inbound services. We can ensure traffic going to the webserver is actually HTTP traffic. I know what you are thinking: I can do this with my IDP unit. Yes, you can, but this is a clean and simple way to define security polices using real applications and apply them neatly to your existing security policy. We are not looking for attacks here. We just want to accomplish one of the following:
- Ensure that an application is what it claims to be.
- Block an application regardless of what ports it is masquerading under.
On top of this you can then still apply a true IDP policy to look for attack signatures.
Closing thoughts
The AppFW is a pretty cool feature. The SRX Firewall is a beast when it comes to routing/security features, so it’s nice to be able to add some of these application level functions. The GUI still needs alot of work as it’s cumbersome, slow, and lacks features, but when you have the industry’s best CLI (starting a religious war here?) the GUI should be an afterthought.
Keep in mind, this was only the AppFW piece of the package. There is also AppID which, with the help of a syslog server, gives you great visibility into your traffic, AppDOS, and AppQoS.
More info on AppSecure
http://www.juniper.net/us/en/local/pdf/datasheets/1000327-en.pdf
