Virtualisation.
That got your attention didn't it! It's the big topic these days and in the SRX we can apply in several ways.
In the Juniper world we have VSYS on ScreenOS and LSYS for high end SRXs both of which allow the creation of logical firewalls with different administrative rights within a single box.
There is also Firefly Perimeter to consider (Eval for 60 day)
http://www.juniper.net/us/en/products-services/security/firefly-perimeter/#evaluation
Even though we can't use LSYS on a branch SRX device we can still set up logical routers called Routing Instances on them and then apply specific zones/interfaces to those Routing Instances thereby gaining some degree or virtualisation in the branch SRX.
Lets look at a simple example of how to apply this..
Showing posts with label Srx. Show all posts
Showing posts with label Srx. Show all posts
SRX IDP: Templates Update
Did you notice that Juniper has updated their IDP policy templates?
First lets review the list of old of pre-defined templates..
blogger@SRX> show security idp policy-templates-list
Web_Server
DMZ_Services
DNS_Service
File_Server
Getting_Started
IDP_Default
Recommended
Lets check the version of that template..
blogger@SRX> show security idp security-package-version
Attack database version:2395(Wed Jul 2 18:14:04 2014 UTC)
Detector version :12.6.160140626
Policy template version :2192
Lets check and see whats available..
blogger@SRX> request security idp security-package download check-server
Successfully retrieved from(https://services.netscreen.com/cgi-bin/index.cgi).
Version info:2395(Detector=12.6.160140626, Templates=2395)
So you see, even if you are automatically updating the attack database that doesn't update the policy templates.
First lets review the list of old of pre-defined templates..
blogger@SRX> show security idp policy-templates-list
Web_Server
DMZ_Services
DNS_Service
File_Server
Getting_Started
IDP_Default
Recommended
Lets check the version of that template..
blogger@SRX> show security idp security-package-version
Attack database version:2395(Wed Jul 2 18:14:04 2014 UTC)
Detector version :12.6.160140626
Policy template version :2192
Lets check and see whats available..
blogger@SRX> request security idp security-package download check-server
Successfully retrieved from(https://services.netscreen.com/cgi-bin/index.cgi).
Version info:2395(Detector=12.6.160140626, Templates=2395)
So you see, even if you are automatically updating the attack database that doesn't update the policy templates.
SRX NAT: Destination
Today we will have a look at some Destination NAT (DNAT) on the SRX with port translation.
We have the following network scenario..
In the this scenario we need to do DNAT using the actual external interface IP (192.168.200.200).
So the flows will go like this..
PRENAT POSTNAT
192.168.200.10 --> 192.168.200.200:8088 192.168.200.10 --> 10.31.254.17:80
192.168.200.10 --> 192.168.200.200:2088 192.168.200.10 --> 10.31.254.17:22
We have the following network scenario..
In the this scenario we need to do DNAT using the actual external interface IP (192.168.200.200).
So the flows will go like this..
PRENAT POSTNAT
192.168.200.10 --> 192.168.200.200:8088 192.168.200.10 --> 10.31.254.17:80
192.168.200.10 --> 192.168.200.200:2088 192.168.200.10 --> 10.31.254.17:22
SRX VPN: Multipoint
Happy New Year to all readers!
Today we are going to make a multipoint VPN.
One hub site (VPN-CORE) and 2 spokes sites (LEFTY and RIGHTY2). All devices are SRXs.
Multipoint is only supported with Route based VPNs so that's what we will be using and the key point to note is that the multipoint hub only uses a single tunnel interface regardless of the number of VPN tunnels.
In real life you probably wouldn't bother with multipoint for just 2 spokes but this is a lab so lets do it!
Here is the network we are working on..
We will want to get traffic between the 2 trust zones and the server-zone running over the VPN.
Today we are going to make a multipoint VPN.
One hub site (VPN-CORE) and 2 spokes sites (LEFTY and RIGHTY2). All devices are SRXs.
Multipoint is only supported with Route based VPNs so that's what we will be using and the key point to note is that the multipoint hub only uses a single tunnel interface regardless of the number of VPN tunnels.
In real life you probably wouldn't bother with multipoint for just 2 spokes but this is a lab so lets do it!
Here is the network we are working on..
We will want to get traffic between the 2 trust zones and the server-zone running over the VPN.
SRX UTM: Antivirus - Sophos
Here is a quick overview of getting Sophos AV working on an SRX
Sophos is the Cloud based solution and so needs an active Internet connection to work. This means the AV database is not stored locally on the SRX like Kaspersky. The SRX uses DNS queries to the Sophos Cloud to perform AV queries. We'll see later how these work.
Sophos can also perform URI content checking over HTTP to detect malware.This is essentially a reputataion check and can be disabled if you wish.
The Sophos solution should put less load on the SRX, processor and memory wise due to not having to download a giant AV database and run checks against it though it does cache responses to improve lookup performance.
Sophos is the Cloud based solution and so needs an active Internet connection to work. This means the AV database is not stored locally on the SRX like Kaspersky. The SRX uses DNS queries to the Sophos Cloud to perform AV queries. We'll see later how these work.
Sophos can also perform URI content checking over HTTP to detect malware.This is essentially a reputataion check and can be disabled if you wish.
The Sophos solution should put less load on the SRX, processor and memory wise due to not having to download a giant AV database and run checks against it though it does cache responses to improve lookup performance.
SRX VPN: Checkpoint to SRX Site-to-Site Policy Based.
Today we are going to take a look at a site to site VPN between a Checkpoint and an SRX.
We will focus more on configuration and testing rather than VPN theory as the Internet is full of great resources in that respect. No NAT in this one either to keep it more simple and just focused on the VPN side of things. We will do a seperate Blog for VPN troubleshooting.
Here is a layer 3 view of the network we will be using..
We will focus more on configuration and testing rather than VPN theory as the Internet is full of great resources in that respect. No NAT in this one either to keep it more simple and just focused on the VPN side of things. We will do a seperate Blog for VPN troubleshooting.
Here is a layer 3 view of the network we will be using..
SRX UTM: Antivirus - Kaspersky Full
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
SRX Trunk
After the epic that was STP, just a quickie today on a couple of points I recently came across when setting up a trunk between a Cisco switch and SRX.
The trunk will trunk VLANs 1,5 and 8. VLAN 1 is native on the Cisco
The Cisco side setup..
The trunk will trunk VLANs 1,5 and 8. VLAN 1 is native on the Cisco
The Cisco side setup..
SRX STP
In smaller sites when rolling out low end SRXs, it's not uncommon for them to be connected to Cisco switches that may be running multiple VLANs
How can we connect up our SRXs to Cisco switches without stuffing up spanning tree on the core Cisco switch and still prevent loops? Lets see what happens when we aim to work with that situation from a spanning tree (STP) perspective.
How can we connect up our SRXs to Cisco switches without stuffing up spanning tree on the core Cisco switch and still prevent loops? Lets see what happens when we aim to work with that situation from a spanning tree (STP) perspective.
SRX UTM: Enhanced Web Filtering - Redirect
Hi Folks,
I was recently asked in regards to Enhanced Web Filtering...
Is there any way to remove the "CATEGORY: Enhanced_Social_Networking_
And by the way to the person who posted that, your email shows up to me as noreply-comment@blogger.com. So doesn't show on the blog as a comment and I cant reply. Google "noreply-comment@blogger.com". You will find out how to fix.
I was recently asked in regards to Enhanced Web Filtering...
Is there any way to remove the "CATEGORY: Enhanced_Social_Networking_
And by the way to the person who posted that, your email shows up to me as noreply-comment@blogger.com. So doesn't show on the blog as a comment and I cant reply. Google "noreply-comment@blogger.com". You will find out how to fix.
Anyway the answer is yes! There is a way to solve the issue.
We will test 3 scenarios while trying to access Playboy.
SRX APPLICATION FIREWALL
Today we will look at running an Application Firewall (AppFW) on the SRX.
This is different to the normal firewalling in that we are not filtering based on TCP/UDP ports but instead filtering on application signatures that can detect applications whether or not they are not running on the standard ports expected.Further even when we are running on the standard ports, through the signatures we can detect and block access to specific services without you having to worry about blocking all access to a certain IP on a certain port. Eg. We could block access to Facebook Farmville without having to know the either the IP of Facebook or having to block all of Facebook. I will try and show some examples of this functionality.
This is different to the normal firewalling in that we are not filtering based on TCP/UDP ports but instead filtering on application signatures that can detect applications whether or not they are not running on the standard ports expected.Further even when we are running on the standard ports, through the signatures we can detect and block access to specific services without you having to worry about blocking all access to a certain IP on a certain port. Eg. We could block access to Facebook Farmville without having to know the either the IP of Facebook or having to block all of Facebook. I will try and show some examples of this functionality.
SRX ADSL - NZ
I recently installed an SRX in NZ so I though I'd put up here the working ADSL config for our cousins across the pond...
Telecom NZ - PPPOA
at-1/0/0 {
mtu 1540;
encapsulation atm-pvc;
atm-options {
vpi 0;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation atm-ppp-vc-mux;
vci 0.100;
ppp-options {
pap {
default-password "!9$uQQhy76fg543es8XYoZGq.P5QF9A"; ## SECRET-DATA
local-name "whoareu.xadsl@xtra.co.nz";
local-password "%9$q.Qnkn8765sgvq8LVbs24aDi"; ## SECRET-DATA
passive;
}
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop at-1/0/0.0;
Telecom NZ - PPPOA
at-1/0/0 {
mtu 1540;
encapsulation atm-pvc;
atm-options {
vpi 0;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation atm-ppp-vc-mux;
vci 0.100;
ppp-options {
pap {
default-password "!9$uQQhy76fg543es8XYoZGq.P5QF9A"; ## SECRET-DATA
local-name "whoareu.xadsl@xtra.co.nz";
local-password "%9$q.Qnkn8765sgvq8LVbs24aDi"; ## SECRET-DATA
passive;
}
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop at-1/0/0.0;
SRX GLOBAL ADDRESS BOOK
Lets have a look today at the issue of using the WebUI with the Global address book.
When I say Global address book, I mean using creating addresses on the SRX in this way...
root# set security address-book ?
Possible completions:
<book-name> Address book name
global Default global address book name
Example of address with the Global Address book..
security {
address-book {
global {
address aaaa 1.1.1.1/32;
address bbbb 2.2.2.2/32;
}
}
These Global addresses form a common address pool that should be available for use in any zone as opposed to the old way of creating separate address books under each zone.
When I say Global address book, I mean using creating addresses on the SRX in this way...
root# set security address-book ?
Possible completions:
<book-name> Address book name
global Default global address book name
Example of address with the Global Address book..
security {
address-book {
global {
address aaaa 1.1.1.1/32;
address bbbb 2.2.2.2/32;
}
}
These Global addresses form a common address pool that should be available for use in any zone as opposed to the old way of creating separate address books under each zone.
SRX ADSL
Here is a couple of SRX ADSL configs to 2 different ISPs.
Both these configs have been tested to actually work.
1) Telstra - PPPOA
at-1/0/0 {
mtu 1540;
encapsulation atm-pvc;
atm-options {
vpi 8;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation atm-ppp-vc-mux;
vci 8.35;
ppp-options {
chap {
default-chap-secret "$9$78fgoJGD.fT3JtuBIcS"; ## SECRET-DATA
local-name "yourname@direct.telstra.net";
passive;
}
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop at-1/0/0.0
2) Netspace - PPPOE
at-1/0/0 {
mtu 1492;
encapsulation ethernet-over-atm;
atm-options {
vpi 8;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation ppp-over-ether-over-atm-llc;
vci 8.35;
}
}
pp0 {
unit 0 {
point-to-point;
ppp-options {
pap {
default-password "$9$CYEtAOwKvLXNdpqvLx92g5Qz"; ## SECRET-DATA
local-name "yourname@netspace.net.au";
local-password "$9$vMwMxdoraUDHq7XaUjhTQRhc"; ## SECRET-DATA
passive;
}
}
pppoe-options {
underlying-interface at-1/0/0.0;
idle-timeout 0;
auto-reconnect 2;
client;
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop pp0.0
Both these configs have been tested to actually work.
1) Telstra - PPPOA
at-1/0/0 {
mtu 1540;
encapsulation atm-pvc;
atm-options {
vpi 8;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation atm-ppp-vc-mux;
vci 8.35;
ppp-options {
chap {
default-chap-secret "$9$78fgoJGD.fT3JtuBIcS"; ## SECRET-DATA
local-name "yourname@direct.telstra.net";
passive;
}
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop at-1/0/0.0
2) Netspace - PPPOE
at-1/0/0 {
mtu 1492;
encapsulation ethernet-over-atm;
atm-options {
vpi 8;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation ppp-over-ether-over-atm-llc;
vci 8.35;
}
}
pp0 {
unit 0 {
point-to-point;
ppp-options {
pap {
default-password "$9$CYEtAOwKvLXNdpqvLx92g5Qz"; ## SECRET-DATA
local-name "yourname@netspace.net.au";
local-password "$9$vMwMxdoraUDHq7XaUjhTQRhc"; ## SECRET-DATA
passive;
}
}
pppoe-options {
underlying-interface at-1/0/0.0;
idle-timeout 0;
auto-reconnect 2;
client;
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop pp0.0
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
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.
* 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.
DHCP server (SRX)
Just a quick one today about setting up an SRX as a DHCP server.
First you need to define the DHCP parameters..
dhcp {
router {
192.168.1.1;
}
pool 192.168.1.0/24 {
address-range low 192.168.1.2 high 192.168.1.254;
default-lease-time 3600;
domain-name blogger.net.au;
name-server {
192.168.1.1;
}
}
}
First you need to define the DHCP parameters..
dhcp {
router {
192.168.1.1;
}
pool 192.168.1.0/24 {
address-range low 192.168.1.2 high 192.168.1.254;
default-lease-time 3600;
domain-name blogger.net.au;
name-server {
192.168.1.1;
}
}
}
Subscribe to:
Posts (Atom)