SRX UTM: Antivirus - Kaspersky Full

Today we are going to take a little look at Antivirus on the SRX and testing it to make sure its actually working.

There are currently 3 Antivirus solutions for the SRX all of which require a different license to activate:
* Kapersky
* Sophos
* Juniper Express

Briefly, some differences between the 3 options are:
Kaspersky 
* Full file based AV
* Local signature database lookups. AV signatures downloaded as a package.
* Largest cpu performance impact 
* Supports Intelligent Prescreening

Sophos
* Cloud based signature database which therefore requires..
* Constant Internet access needed for AV lookups.
* Moderate cpu perfomance impact
* No Prescreening 

Juniper Express
* Less protection than the other 2 options 
* Only protects against critical threats. Modified Kaspersky database.
* Does not reconstruct content prior to scanning 
* Pattern matching based solution. No heuristics.
* No protection against polymorphic or metamorphic viruses
* Supports Intelligent Prescreening

* Least cpu performance impact and highest throughput.

SRX UTM: Web Filtering (Enhanced Web Filtering)

This summary is not available. Please click here to view the post.

SRX UTM: Web Filtering (Local)

Time to test the UTM Web Filtering feature.

The first thing to know is that there are 4 different ways to do this on the SRX.

1) Surfcontrol - This is know as Integrated Web Filtering and uses a cloud based Surfcontrol server to categorise URLs. This option requires a license and of course you can test with the 30 day trial license. The cloud based Surfcontrol server doesn't permit or deny anything. When queried by the SRX it provides a category that is permitted or denied by the policy you create on the SRX. The URL-to-category site results from the Surfcontrol server are cached locally which means subsequent requests for the same site don't require a lookup on the Surfcontrol server. This is a sensible approach as it means you dont have to download the whole database from Surfcontrol every time you start the SRX - it just requests the info from Surfcontrol on as as needed realtime basis.

Note: Surfcontrol is now owned by Websense though Juniper still name this option as Surfcontrol.

2) Enhanced Web Filtering - This is another type of Integrated solution which uses the Websense ThreatSeeker Cloud (TSC). Similar to Surfcontrol option above it provides a cattergory for the site to be checked but in addition also provides a reputation for the site.
A license is required for this option.

Juniper consider this option "next-generation URL filtering solution, building upon the existing SurfControl solution".

3) Websense - This is known Redirect Web Filtering and uses your local Websense server. This option does not require a licence. The main difference here to the Surfcontrol option is the the Websense server itself, through its own polices is doing the denying or permitting.

4) Local lists. This option uses local black and white lists to permit or deny access to URLs. No license required.

In this post I will configure and test the Local lists 

SRX IDP

This post will show you how to get IDP on an SRX100H going and tested to be working.

I will be using a Trial licence which is valid for 30days.

1) GET AND INSTALL THE IDP LICENSE

a) First make sure you can ping a URL from your SRX as the download process will use name lookups.

blogger@LEFTY> ping www.juniper.net inet

PING e1824.dscb.akamaiedge.net (184.87.23.148): 56 data bytes

64 bytes from 184.87.23.148: icmp_seq=0 ttl=54 time=33.373 ms

64 bytes from 184.87.23.148: icmp_seq=1 ttl=54 time=30.299 ms

64 bytes from 184.87.23.148: icmp_seq=2 ttl=54 time=29.531 ms

^C

--- e1824.dscb.akamaiedge.net ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max/stddev = 29.531/31.068/33.373/1.660 ms

If that doesn’t work, setup name servers in the config.

SRX Traceoptions: Security Flow

Following on from the last post lets quickly see how we go using TCPDUMP with reth interfaces;

Using the same methodology as in my last post...I.e having separate input and output filters and applying those filters on the reth interface, I find that the SRX generates 2 files, one for the reth and one for the (I assume active) physical interface.Eg.

-rw-r--r--  1 root  wheel  1878 Apr 27 18:15 dumptest.fe-0.0.2
-rw-r--r--  1 root  wheel  1298 Apr 27 18:15 dumptest.reth0

Looking at the 2 files we can capture what we want however each file only shows the traffic in one direction. So you need to look at both files to see everything that is going on. For sure not too handy.

At any rate in the Junos release notes (Branch SRX) they state..
                Sampling features like J-FLow, packet capture, and port mirror on the reth interface are not supported.
And thats from 12.1! So its not a limitation that will disappear soon if ever.

If your insistent and put the filters on the physical interface instead of the reth like this ..

fe-0/0/2 {
        fastether-options {
            redundant-parent reth0;
        }
        unit 0 {
            family inet {
                filter {
                    input INGRESS-TCPDUMP;
                    output EGRESS-TCPDUMP;
                }
            }
        }
   }

Well your out of luck there as that will again only show the one direction. Not recommended!

So Is there another way to see whats going on at a very raw level on the firewall?

Yup..Hello traceoptions.

Logging Policy and TCPDUMP (SRX)

How can we know if our policies are being hit or if traffic is getting to the firewall?

* SETUP

The policy in question for all the below work is just the default trust to untrust policy on the SRX. The source IP on trust is 192.168.56.50 and the destination on IP on untrust is 172.20.123.2

blogger@LEFTY> show configuration security policies from-zone trust to-zone untrust
policy trust-to-untrust {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}

* LOGGING

First lets look at logging. Lets add logging to the policy. If your going to have logging you must choose session-init or session-close or both. From my perspective session-init is way more useful as if you have very long lasting sessions you may never know that you got a policy hit. Sure you might want to know when a session ends but at the very least you would want to know when and if your policy even got hit so make sure you at least use session-init.

Logging (Olive - Firewall)

Now we can login to the olive, control the login through a firewall filter and see hits on the filter. But that only gives us a packet and byte count. It doesn't tell us when the counts happened or where they were sourced from. For that we need logging.

An easy way to do this is to use the action "log" on the term..

user@olive-core> show configuration firewall
filter ACCESS-CNTRL {
    term TELNET-BLOCK {
        from {
            destination-port telnet;
        }
        then {
            count COUNTER-TELNET-BLOCK;
            log;
            discard;
        }
    }
    term PERMIT-ALL {
        from {
            source-address {
                0.0.0.0/0;
            }
        }
        then {
            count COUNTER-PERMIT-ALL;
            accept;
        }
    }
}

To see the log..(And there must be hits against the term to see the kind of output below)