SRX

From Network Security Wiki
Jump to navigation Jump to search


Architecture


SRX Flow.png

Source: juniper.net

  • JUNOS runs on top of FreeBSD.

Details of Flow

  • What happens in "TCP" section of the flow?
3 Way Handshake check
Sequence no check
Acknowledge check
  • Where are the TCP parameters checked?
It is check in First path & Fast path both.

Changes in Flow

Source: exactnetworks.net

Next-Generation NAT
  • In Junos 9.2 the flow module was changed
  • Static and Destination NAT now occurs prior to Route and Policy lookup
  • Source NAT takes place AFTER routing and policy evaluation.
  • NAT and Security Policy configuration was decoupled
  • Before Junos 9.2, all NAT was processed after routing and policy evaluation.
Issues with flow of Junos 9.1 or earlier

1. Destination NAT where the destination IP address within the incoming packet is not an IP address the SRX has a route to.

  • Assume we have "untrusted" and "trusted" Zones.
  • Our ISP has given us 1.1.1.1 to use for our FTP server and has routed this address to our SRX.
  • We have configured destination NAT for users on the internet to access the FTP server.
  • In this case the SRX will not have a route directing 1.1.1.1 to the internal zone.
  • This means zone lookup/polcy match will fail and ultimately drop the packet.
  • Placing a route on the SRX for the 1.1.1.1/32 address can be done as a workaround but this is inefficient and goofy.


2. NAT Configuration that requires multiple security policies (due to the fact that NAT and Security Poilcy are configured together).

  • An alternate private network of 192.168.2.0/24 has the exact same security requirements as the 200.200.200.0/30 network and they reside in the same zone.
  • Assume that no destination NAT is needed between 192.168.1.0/24 and 192.168.2.0/24 networks.
  • We can simply just route between these networks.
  • It would be ideal in this case to create a single rule in the security policy.
  • This cannot be done as NAT parameters are configured within the security policy.
  • To accomplish this tasks multiple policies would need to be configured.
200.200.200.1-------SRX-------192.168.1.10(FTP)
                     |
                     |
                192.168.2.10

Basics

Source = jsrx.juniperwiki.com

Physical Interfaces
  • Physical interfaces are the interfaces that you can touch, they are the interfaces that you see when you look at the device, and they are the interfaces you plug cables into. All interfaces are defined under the interfaces hierarchy as such
interfaces {
    ge-0/0/0 {
        <PHYSICAL PROPERTIES HERE>
        unit 0 {
...     
        }
    }
}


  • Physical properties such as MTU and framing protocols are defined directly under the interface.
Logical Interface
  • Logical interfaces are where the majority of the configuration is done. Every interface has to have at least 1 logical interface (usually 0). Logical interfaces are where you configure IP addresses and protocol families.
interfaces {
    ge-0/0/0 {
        unit 0 {
            <LOGICAL PROPERTIES HERE>
        }
    }
}
  • There are many different protocol families that you can configure. Some of them include inet (IPv4), inet6 (IPv6), iso, mpls, and ethernet-switching.
  • When using set commands to either set interfaces or refer to interfaces, you can use one of two methods. You can refer to the interface as "<interface> unit <#>" or "<interface>.<#>.
[edit] metacortex@DevourerofSouls# set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.1/24
[edit] metacortex@DevourerofSouls# set interfaces ge-0/0/0.0 family inet address 192.168.1.1/24
Multiple IP Addresses on a Single Interface
  • You can assign as many IP addresses as you would like to an interface as well as multiple families on an interfaces. When you want to specify what address gets preferred, you just use the preferred option.
interface {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 192.168.0.1/24;
                address 192.168.1.1/24 {
                    preferred;
                }
                address 10.0.0.1/8;
            }
        }
    }
}


  • OSPF and IS-IS will form adjacency across all subnets configured on a logical interface so if you do not want this, you need to separate the interfaces out across multiple logical interfaces.
  • To configure multiple protocol families on an interface, you do it like this
interface {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 192.168.0.1/24;
                address 192.168.1.1/24 {
                    preferred;
                }
                address 10.0.0.1/8;
            }
            family inet6 {
                address 3001::1/64;
            }
        }
    }
}


Interface Names
  • JunOS uses 4 criteria in naming an interface. It uses (and in this order) Media Type, FPC Slot Number, PIC Slot Number, and Port number. For instance, ge-2/1/4 would be the forth interface on PIC slot 1 of the FPC in the number 4 slot.
  • There are many different media types. Here are a few of them

ge = gigabit ethernet fe = fast ethernet lo = loopback ae = aggregated ethernet fab = fabric interface for JSRP clusters st = tunnel interfaces ls/lsq = link services


Rollback Config
  • Junos Stores 49 previously committed configurations on its storage device.
  • The factory default for the maximum number of backup configurations allowed is 5.[1]
  • Rollback number 0 is the current running configuration - before commit, If after commit = rollback 1
rollback 5
commit
  • The current operational configuration is stored in a file named juniper.conf,
  • The last 5 committed configurations are stored in the files juniper.conf.1 through juniper.conf.5.
  • If you create a rescue configuration, it is stored in a file named rescue.conf.
  • These files are located in the /config directory, which is on the flash drive of the SRX Series device.
  • Increasing this backup configuration number results in increased memory usage on disk and increased commit time.
  • When you edit a configuration, you work in a copy of the current configuration to create a candidate configuration.
  • To have a candidate configuration take effect, you commit the changes.
  • Rollback Commands:
rollback 5
commit
show rollback 5
show | compare rollback 5
Modes
Shell Mode
  • The shell mode is to troubleshoot from Linux like CLI.
Operational Mode
  • This mode is used for monitoring and troubleshooting of the device.
  • You can monitor all of the hardware components, test network connectivity, and view the current running configuration.
  • You can not make configuration changes in this mode.
  • Operational Mode is the mode you are placed into when initially logging in (except for the root acount).
  • This mode is indicated by the greater than sign at the end of the prompt
user@SRX240>
Configuration Mode
  • This mode is used for making configuration changes to JunOS.
  • Configuration would include interface ip address, routing protocol configuration, and user access/control.
  • When we get into configuration mode, you will see something new added to the top of the prompt and the greater than sign will change to a pound sign to reflect we are in configuration mode.
[edit]
user@SRX240#
  • The [edit] top of the prompt signifies what section of the XML configuration tree we are currently sitting in.
  • When it displays [edit], we are at the very top of the configuration.
  • Issuing a show will output the entire configuration from that section down.
  • For instance, if we wanted just to see the configuration of the interfaces we would run the following commands:
[edit]
user@SRX240# edit interfaces

[edit interfaces]
user@SRX240# show

ge-0/0/0 {
    unit 0 {
        family inet {
            address 6.6.6.6/30;
        }
    }
}
  • We can also view a specific section of the tree by specifying it in the show command like so
[edit]
user@SRX240# show interfaces

ge-0/0/0 {
    unit 0 {
        family inet {
            address 6.6.6.6/30;
        }
    }
}
  • You can also run any Operational Mode command in Configuration Mode by appending "run" to the beginning of it like so:
[edit]
user@SRX240# run ping 4.2.2.2 rapid count 5
Show
  • This shows everything in the configuration from the current level down
[edit]
user@SRX240# show 
Reference
  • Help reference will show you everything you need to know about a given command
[edit]
user@SRX240# help reference interfaces address
Apropos
  • If you remember one or two parts of a command but cant remember the full command, you can use help apropos to help you find that command
[edit]
user@SRX240# help apropos ssh


Taking Debug in SRX

Configure Traceoptions
set <option> traceoptions file filename
files                            (default 10)
size                             (default 128k)
read permissions                 (e.g. world-readable)
set <option> traceoptions flag   (define what you want to look at)

Packet Flow Trace

edit
set security flow traceoptions file Debug_log.txt size 1M files 5
set security flow traceoptions packet-filter f0 source-prefix 10.1.1.1/32 destination-prefix 172.16.1.1/32
set security flow traceoptions packet-filter f1 source-prefix 172.16.1.1/32 destination-prefix 10.1.1.1/32
set security flow traceoptions flag basic-datapath
exit
commit and-quit                                                        (Logging starts after the commit)

Verify changes:

show security flow traceoptions
show | compare
show configuration security flow

Check the output:

show log Debug_log.txt
show log Debug_log.txt | match route
show log Debug_log.txt | last 20
show log Debug_log.txt | trim 42                                         (remove timestamps)

Realtime Monitor (similar to tail –f cmd):

monitor start interface.txt
monitor stop interface.txt

Check the output using tail cmd:

start shell
srx% tail -f /var/log/ Debug_log.txt | grep -Evi ^$
srx% tail -f /var/log/ Debug_log.txt | grep -Evi ^$ | grep 10.10.10.1
srx% tail -f /var/log/ Debug_log.txt | grep -Evi ^$ | grep session
srx% tail -f /var/log/ Debug_log.txt | grep -Evi ^$ | grep tcp

Deleting filters & stopping debugs:

deactivate security flow traceoptions
commit

OR

delete security flow traceoptions
commit

Delete Files & Filters:

edit
del packet-filter f0 source-prefix 10.1.1.1/32 destination-prefix 172.16.1.1/32
del packet-filter f1 source-prefix 172.16.1.1/32 destination-prefix 10.1.1.1/32
del flag basic-datapath
clear log Debug_log.txt
file delete /var/log/Debug_log.txt
commit and-quit

Note:

  • It is security flow traceoptions, with a flag of basic-datapath (similar to debug flow basic in ScreenOS).
  • show | compare - This command displays the lines which will be added to your config)

Interface State Trace

Basic trace to monitor interfaces going up and down:

set interfaces traceoptions file interface.txt size 1M files 5 
set interfaces traceoptions flag config-states 
commit and-quit

Packet Captures

Capture control traffic to Routing Engine

Packet Capture of control traffic to and from the RE of the SRX :

> monitor traffic interface <int> layer2-headers  
> monitor traffic interface e1-0/0/0.0 no-resolve 

Packet capture on J-Series or SRX branch device

Source: juniper.net, fir3net.com

set forwarding-options packet-capture file filename pcap files 10 size 10000
set forwarding-options packet-capture maximum-capture-size 1500
set firewall filter PCAP term 1 from source-address 10.209.144.32
set firewall filter PCAP term 1 from destination-address 10.204.115.166
set firewall filter PCAP term 1 then sample
set firewall filter PCAP term 1 then accept
set firewall filter PCAP term 2 from source-address 10.204.115.166
set firewall filter PCAP term 2 from destination-address 10.209.144.32
set firewall filter PCAP term 2 then sample
set firewall filter PCAP term 2 then accept
set firewall filter PCAP term allow-all-else then accept 
set interfaces ge-0/0/0 unit 0 family inet filter output PCAP
set interfaces ge-0/0/0 unit 0 family inet filter input PCAP
commit and-quit                  (This will start the capture)

The term allow-all-else is used to make sure that the SRX does not drop any other traffic, but do not sample it either.

Verify capture file:

> file list /var/tmp/ | match pcap*  
pcap.ge-0.0

Display Capture:

start shell
cd /var/tmp/
tcpdump -r pcap.ge-0.0.0

Remove Capture Config:

delete interfaces ge-0/0/0 unit 0 family inet filter input PCAP
delete interfaces ge-0/0/0 unit 0 family inet filter output PCAP
delete firewall filter PCAP
delete forwarding-options packet-capture

A quick way to revert config is using rollback:

rollback 1
commit


Packet Capture on High-End SRX

Packet Capture on High-End SRX devices(SRX1400 or above):

   Paste.png     This section is under construction.

Important CLI Commands

Monitoring commands:

show version 			 		Software version
show chassis hardware detail 			Hardware and Serial numbers
show chassis environment 			Temperatures, Fan and Power Supply
show chassis routing-engine 			Temperatures, Memory, CPU Load
show interfaces terse 			 	Interface States
show interfaces extensive 			Interface and Zone Counters
monitor interface 		 		Real-time interface statistics
show security flow session 			Current sessions
show system alarms 			 	Alarms
show chassis alarms 			


Log Files:

show log					List all Logfiles available
show log messages				Show Log File from beginning
show log messages | last			List last Log Messages
show log messages | match LOGIN			Search within the Log
monitor start <file>				Send Logs to terminal (like tail -f)

SRX vs ScreenOS [2]

  • Security policy enforcement is entirely handled on the data plane. This protects from succumbing to DoS attacks that can leave the management engine unavailable. ScreenOS do at least the policy lookup on the control plane.
  • The SRX 210 has a whopping 1gb of flash.
  • Changes made to the SRX aren’t put into action as soon as you hit enter. After changes are made a “commit” must be done to save changes and put them into the running configuration.
  • Unit checks changes to ensure config makes sense before committing. Otherwise an error is returned and config is not committed.
  • The SRX makes a backup of the current config when you perform a “commit”, this way if the changes you made don’t work, you can roll back to the last config. You can have up to 49 rollback points. You can also setup the SRX ftp the backup config to a server every time you perform a commit.
  • You can create a rescue config save point. So that when you default a box, it goes to the Rescue config rather than the factory default.
  • Can do pattern search and replace commands in the config “ex replace 1.1.1.1 with 2.2.2.2” without having to manually scour the config.
  • Configuration is a bit cumbersome at first. Commands are long winded and wordy, but the autocomplete works very well!
  • With a root login, you are able to access the underlying BSD OS. This can be very dangerous in the hands of a inexperienced user, but also has its advantages (can perform administrative functions that are unavailable in most other vendor devices).
  • ScreenOS cannot separate the running of tasks from the kernel. All processes effectively run with the same privileges. Because of this, if any part of ScreenOS were to crash or fail, the entire OS would end up crashing or failing.
  • The modular architecture of Junos allows for the addition of new services.
  • With its ASIC-focused architecture, it allowed for amazing performance for stateful firewalling but poor performance deeper in the packet. Junos had the necessary underpinnings to allow for deeper inspection.
  • ScreenOS introduced the concept of zones to the firewall world. It increases the overall speed of policy lookup, and because multiple zones are always used in a firewall, it separates the overall firewall rulebase into many subsets of zone groupings. Junos also uses the same concept.


Comparison of SRX & ScreenOS commands

Session & Interface counters

ScreenOS SRX
get session show security flow session
get interface show interface terse
get counter stat show interface extensive
get counter stat <interface> show interface <interface> extensive
clear counter stat clear interface statistics <interface>

Debug & Snoop

ScreenOS SRX
debug flow basic # edit security flow
# set traceoptions flag basic-datapath
# commit
set ff # edit security flow
# set traceoptions packet-filter
get ff > show configuration | match packet-filter | display set
get debug > show configuration | match traceoptions | display set
get db stream View stored log: (recommended option)

> show log <file name> (enter h to see help options)
> show log security-trace (to view 'security flow' debugs)
> show log kmd (to view 'security ike' debugs)

View real-time: (use this option with caution)
> monitor start <debugfilename>
ESC-Q (to pause real-time output to screen)

clear db > clear log <filename> (clears contents of file)
undebug <debug> (stops collecting debugs) # edit security flow
# deactivate traceoptions OR # delete traceoptions (at the particular hierarchy)
# commit
undebug all Not available. You need to deactivate or delete traceoptions separately.
debug ike detail > request security ike debug-enable local <local gw> remote <remore peer> level 7

Event Logs

ScreenOS SRX
get event > show log messages
> show log messages | last 20 (helpful cmd because newest log entries are at end of file)
get event | include <string>

> show log messages | match <string>
> show log messages | match “<string> | <string> | <string>”
Examples:
> show log messages | match “error | kernel | panic”
> show log messages | last 20 | find error

clear event > clear log messages

Snoop

   Paste.png     This section is under construction.

Config & Software upgrade

ScreenOS SRX
get config > show config (program structured format)

> show config | display set | no-more (set command format)

get license > show system license keys
get chassis (serial numbers) > show chassis hardware detail

> show chas environment
> show chas routing-engine

exec license > request system license [add | delete |save]

(Does not require a reboot on SRX, but does on ScreenOS)

unset all
reset
load factory-default
set system root-authentication plain-text-password
commit and-quit
request system reboot
save config from tftp <tftp_server> <configfile> to flash > start shell and FTP config to router, i.e. /var/tmp/test.cfg.
Then:
# load override /var/tmp/test.cfg
save software from tftp <tftp_server> <screenosimage> to flash request system software add ftp:1.1.1.11/jsr/junos-srxsme-9.5R1.8-domestic.tgz reboot
-TFTP is not supported. Use only FTP. HTTP, or SCP
-'request system software rollback' to rollback to previous s/w package
save # commit OR
# commit and-quit
reset > request system reboot

Policy

ScreenOS SRX
get policy > show security policies
get policy from <zone> to <zone> > show security policies from <zone> to <zone>

VPN

ScreenOS SRX
get ike cookie > show security ike security-associations
get sa > show security ipsec security-associations
> show security ipsec sa
clear ike cookie > clear security ike security-associations
clear sa > clear security ipsec security-associations

High Availability

ScreenOS SRX
get nsrp > show chassis cluster status

> show chassis cluster interfaces
> show chassis cluster status redundancy-group <group>

exec nsrp vsd <vsd> mode backup (on master) > request chassis cluster failover redundancy-group <group> node <node>
> request chassis cluster failover reset redundancy-group <group>

DHCP

ScreenOS SRX
get dhcp client > show system services dhcp client
exec dhcp client <int> renew > request system services dhcp renew (or release) (DHCPD) OR

> request dhcp client renew (JDHCPD)

Routing

ScreenOS SRX
get route > show route
get route ip <ipaddress> > show route <ipaddress>
get vr untrust-vr route > show route instance untrust-vr
get ospf nei > show ospf neighbor
set route 0.0.0.0/0 interface <int> gateway <ip> # set routing-options static route 0.0.0.0/0 next-hop <ip>

NAT

ScreenOS SRX
get vip > show security nat destination-nat summary
get mip > show security nat static-nat summary
get dip > show security nat source-nat summary

> show security nat source-nat pool <pool>

Other

ScreenOS SRX
get perf cpu > show chassis routing-engine
get net-pak s > show system buffers
get file > show system storage
get alg > show security alg status
get service > show configuration groups junos-defaults applications
get tech > request support information
set console page 0 > set cli screen-length 0

Common Config commands

MIP in SRX

Internet------------SRX-----------Webserver
             1.1.1.10            192.168.1.10

Interfaces:

ge-0/0/1.0 = Internet   1.1.1.1/24
ge-0/0/0.0 = Internal   192.168.1.1/24

IP addresses:

MAPPED IP		 1.1.1.10
HOST IP ADDRESS         192.168.1.10

Required Configuration:

set security nat proxy-arp interface ge-0/0/1.0 address 1.1.1.10/32
set security nat static rule-set static-nat from zone Internal
set security nat static rule-set static-nat rule rule1 match destination-address 1.1.1.10
set security nat static rule-set static-nat rule rule1 then static-nat prefix 192.168.1.10
set security zones security-zone Internet address-book address webserver 192.168.1.10
set security policies from-zone Internal to-zone Internet policy static-nat match source-address any destination-address webserver application junos-http
set security policies from-zone Internal to-zone Internet policy static-nat then permit


Enable SSH

set system services ssh
set system services ssh protocol-version v2
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ssh

Configurational hierarchy

  • Interface-level configuration overrides the zone-level configuration.
  • Can configure the statement under the entire zone stanza:
user@host# set security-zone HR host-inbound-traffic system-services all
  • Can configure the statement under an interface stanza within a zone(If both configured,this one will take effect):
user@host# set security-zone HR interfaces ge-0/0/1 host-inbound-traffic system-services http

HA Log processing Bug

  • Data plane will process traffic logs.
  • Data & Controll plane should be in same HA Node.
  • If Data plane is in Node 1, but control plane on Node0, logs will be generated by node 1 but not sent to node 0.
  • So no logs will be sent to control plane hence no logs will be generated.

Enable SRX Cluster

Source: juniper.net & rtoodtoo.net

SRX HA Tolopogy

Logical Interfaces:

IFD.IFL        IP/mask           Security Zone
reth0.0        10.10.10.1/24     Trusted
reth1.0        20.20.20.1/24     Untrusted
  • Disable ethernet switching, vlans, control link, management ports(fxp0), Logical interfaces
  • Add both firewalls into cluster
set chassis cluster cluster-id 1 node 0 reboot
set chassis cluster cluster-id 1 node 1 reboot
  • Setup host names and management IP addresses
set groups node0 system host-name SRX-001
set groups node0 interfaces fxp0 unit 0 family inet address 172.16.20.1/24
set groups node1 system host-name SRX-002
set groups node1 interfaces fxp0 unit 0 family inet address 172.16.20.2/24
set apply-groups "${node}"
  • Managing both nodes from fxp0
set groups node0 system backup-router xx.xx.xx.xx destination 10.100.0.0/16

Since routing process is not running on Backup node, we require to configure backup router.
xx.xx.xx.xx is the Backup Router IP address (device shown above along with 2 SRX firewalls).
10.100.0.0/16 is the subnet from where SRX is being accessed.KB15580,KB17161

  • Configure fabric links (data-plane, used to sync RTO’s)
set interfaces fab0 fabric-options member-interfaces ge-0/0/0
set interfaces fab1 fabric-options member-interfaces ge-3/0/0
  • Redundancy Group Config
set chassis cluster reth-count 2
set chassis cluster redundancy-group 0 node 0 priority 200
set chassis cluster redundancy-group 0 node 1 priority 100
set chassis cluster redundancy-group 1 node 0 priority 200
set chassis cluster redundancy-group 1 node 1 priority 100
  • Redundant Ethernet Config
set interfaces reth0 unit 0 family inet address 10.10.10.1/24
set interfaces ge-0/0/1 gigether-options redundant-parent reth0
set interfaces ge-3/0/1 gigether-options redundant-parent reth0
set interfaces reth0 redundant-ether-options redundancy-group 1
set security zones security-zone Trusted interfaces reth0.0
set interfaces reth1 unit 0 family inet address 20.20.20.1/24
set interfaces ge-0/0/2 gigether-options redundant-parent reth1
set interfaces ge-3/0/2 gigether-options redundant-parent reth1
set interfaces reth1 redundant-ether-options redundancy-group 1
set security zones security-zone Untrusted interfaces reth1.0
  • Verifying configuration
#show chassis cluster
>show chassis cluster status
>show chassis cluster data-plane interfaces
>show chassis cluster interfaces
>show chassis cluster status redundancy-group 1

Note: In order to manage SRX Cluster, we need 3 IP address.

1 Common Interface IP address (reth0 or reth1)
2 IP addresses from a different subnet to be assigned to fxp0 interfaces

SRX Site to Site VPN



References
  1. www.techmahindra.com
  2. www.bt.com/india



blog comments powered by Disqus