Monthly Archives: August 2015

JNCIS-SEC, Security

JNCIS-SEC – Port forwarding on the SRX

Leave a comment

A common technique to obscure services from network probing is to host them on ports outside of the well-known ports range. This might help as a first defense, but in reality the ports are still there for anyone who steps out of the defaults. It also makes life harder for other firewall engineers 🙂 On the other hand, if your ISP is blocking services hosted in the well-known range, it might be your only option.

As in all the NAT examples, here is the topology:

SRX NAT topology

We are hosting an SFTP server, but are fed up with all the bruteforce attacks, so decide to host it on a different port. Traffic coming from the untrust zone, destined for 1.1.1.11 and arriving at TCP port 2222, will be translated to port 22 on the inside.

First, we define the real, internal port at the DNAT pool, together with the internal IP.

[edit security nat destination]
root@NP-vSRX-01# show pool DNAT-Host100-11
address 10.0.100.11/32 port 22;

Then, we go to our rule set, which defined the traffic direction (from untrust) and enter the address and port on which it should be listening, plus the pool to translate to: 

[edit security nat destination rule-set DNAT-From-Untrust]
root@NP-vSRX-01# show
from zone untrust;
rule DNAT-Host100-11 {
    match {
        destination-address 1.1.1.11/32;
        destination-port {
            2222;
        }
    }
    then {
        destination-nat {
            pool {
                DNAT-Host100-11;
            }
        }
    }
}

That’s it. After doing a telnet to port 2222, we see the following flow in the table: 

Session ID: 167059, Policy name: FW-SSH-Server/6, Timeout: 1778, Valid
  In: 10.6.60.68/62340 --> 1.1.1.11/2222;tcp, If: ge-0/0/0.0, Pkts: 3, Bytes: 132
  Out: 10.0.100.11/22 --> 10.6.60.68/62340;tcp, If: ge-0/0/1.0, Pkts: 2, Bytes: 126

Port forwarding with a dynamic IP

If you are running a dynamic IP address, it won’t be possible to define one IP as a match condition. Unless your ISP is always handing out addresses in one specific range, the only option is to define the destination-address as 0.0.0.0/0

All config stays the same, but the DNAT rule looks like this: 

[edit security nat destination rule-set DNAT-From-Untrust rule DNAT-Host100-11]
root@NP-vSRX-01# show
match {
    destination-address 0.0.0.0/0;
    destination-port {
        2222;
    }
}
then {
    destination-nat {
        pool {
            DNAT-Host100-11;
        }
    }
}
JNCIS-SEC, Security

JNCIS-SEC Lab – Destination NAT

2 Comments

In this lab, we will look at configuring the SRX to translate the destination field for incoming traffic, which is widely used for public servers in a DMZ.

As with all the NAT examples, I’ll be using the following topology:

SRX NAT topology

These are the requirements for the translations:

  • Only applies to traffic coming from the internet (untrust zone)
  • Destination 1.1.1.10/32 will be translated to DMZ IP 10.0.100.10/32
  • Destination 1.1.1.11/32 will be translated to DMZ IP 10.0.100.11/32

First, I will configure security policies for the following services:

  • Server 10.0.100.10 is hosting a Telnet server
  • Server 10.0.100.11 is an SSH/SFTP server

Because DNAT happens before policy lookup, we always refer to the address as it will be after translation.

[edit security policies from-zone untrust to-zone dmz]
root@NP-vSRX-01# show
policy FW-Telnet-Server {
    match {
        source-address any;
        destination-address Host-10.0.100.10-32;
        application junos-telnet;
    }
    then {
        permit;
        log {
            session-close;
        }
    }
}
policy FW-SSH-Server {
    match {
        source-address any;
        destination-address Host-10.0.100.11-32;
        application junos-ssh;
    }
    then {
        permit;
        log {
            session-close;
        }
    }
}

As this is a fresh config, we will first define a rule-set that specifies the traffic direction. Destination NAT does not give you the option to specify the to-zone, just the source zone.

[edit security nat destination]
root@NP-vSRX-01# show
rule-set DNAT-From-Untrust {
    from zone untrust;
}

Now, let’s add the two pools:

[edit security nat destination]
root@NP-vSRX-01# show
pool DNAT-Host100-11 {
    address 10.0.100.11/32;
}
pool DNAT-Host100-10 {
    address 10.0.100.10/32;
}

And here are the NAT rules themselves: 

[edit security nat destination rule-set DNAT-From-Untrust]
rule DNAT-Host100-10 {
    match {
        destination-address 1.1.1.10/32;
    }
    then {
        destination-nat {
            pool {
                DNAT-Host100-10;
            }
        }
    }
}

rule DNAT-Host100-11 {
    match {
        destination-address 1.1.1.11/32;
    }
    then {
        destination-nat {
            pool {
                DNAT-Host100-11;
            }
        }
    }
}

Because the upstream router is in the same segment as our firewall, we will also need to add ProxyARP to the global NAT config.

[edit security nat]
root@NP-vSRX-01# set proxy-arp interface ge-0/0/0.0 address 1.1.1.10/32 to 1.1.1.11/32

Verification

After starting a telnet and SSH session from my PC, this is the session table: 

Session ID: 166748, Policy name: FW-SSH-Server/6, Timeout: 1792, Valid
  In: 10.6.66.68/59016 --> 1.1.1.11/22;tcp, If: ge-0/0/0.0, Pkts: 3, Bytes: 132
  Out: 10.0.100.11/22 --> 10.6.66.68/59016;tcp, If: ge-0/0/1.0, Pkts: 2, Bytes: 126

Session ID: 166759, Policy name: FW-Telnet-Server/5, Timeout: 1798, Valid
  In: 10.6.66.68/60731 --> 1.1.1.10/23;tcp, If: ge-0/0/0.0, Pkts: 11, Bytes: 510
  Out: 10.0.100.10/23 --> 10.6.66.68/60731;tcp, If: ge-0/0/1.0, Pkts: 14, Bytes: 652

root@NP-vSRX-01> show security nat destination summary
Total pools: 2
Pool name            Address                           Routing        Port  Total
                     Range                             Instance             Address
DNAT-Host100-11      10.0.100.11    - 10.0.100.11                     0     1
DNAT-Host100-10      10.0.100.10    - 10.0.100.10                     0     1

Total rules: 2
Rule name            Rule set       From                               Action
DNAT-Host100-11      DNAT-From-Untrust untrust                         DNAT-Host100-11
DNAT-Host100-10      DNAT-From-Untrust untrust                         DNAT-Host100-10

root@NP-vSRX-01> show security nat destination pool all
Total destination-nat pools: 2

Pool name       : DNAT-Host100-11
Pool id         : 3
Total address   : 1
Translation hits: 1
Address range                        Port
    10.0.100.11 - 10.0.100.11           0

Pool name       : DNAT-Host100-10
Pool id         : 4
Total address   : 1
Translation hits: 8
Address range                        Port
    10.0.100.10 - 10.0.100.10           0
JNCIS-SEC, Security

JNCIS-SEC Lab – Pool-based Source NAT

Leave a comment

In the previous article, I configured the SRX to translate outgoing traffic to the external interface IP. In this article, we will look at a second way of configuring Source NAT, using a NAT address pool.

Again, I will be using the same topology:

SRX NAT topology

For the Source NAT with address pool, this is the requirement:

  • Traffic from the hosts in range 10.0.200.0/24
  • Destined to the untrust zone (the internet)
  • will be SNAT’ed to a pool with one IP address, 1.1.1.2/32

The firewall policies from the previous article, which allow basic web access, are still in place: 

root@NP-vSRX-01# show security policies from-zone trust to-zone untrust
policy FW-PermitWeb {
    match {
        source-address Net-10.0.200.0-24;
        destination-address any;
        application [ junos-http junos-https junos-dns-udp ];
    }
    then {
        permit;
        log {
            session-close;
        }
    }
}

First, configure a rule-set that defines the traffic direction:

[edit security nat source]
root@NP-vSRX-01# show
rule-set NAT-Trust-to-Internet {
    from zone trust;
    to zone untrust;
}

Then, create the address pool: 

[edit security nat source]
root@NP-vSRX-01# set pool SNAT-Pool-Trust-to-Internet address 1.1.1.2/32

Next, configure the NAT rule based on the requirements: 

[edit security nat source rule-set NAT-Trust-to-Internet rule NAT-Source-VLAN200]
root@NP-vSRX-01# show
match {
    source-address 10.0.200.0/24;
}
then {
    source-nat {
        pool {
            SNAT-Pool-Trust-to-Internet;
        }
    }
}

After a commit, the SRX is correctly translating the traffic to 1.1.1.2 (Out > In traffic):

root@NP-vSRX-01> show security flow session source-prefix 10.0.200.10/32
Session ID: 38803, Policy name: FW-PermitWeb/4, Timeout: 42, Valid
  In: 10.0.200.10/23772 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 63
  Out: 8.8.8.8/53 --> 1.1.1.2/15049;udp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

### omitted for brevity ###

Session ID: 38809, Policy name: FW-PermitWeb/4, Timeout: 42, Valid
  In: 10.0.200.10/15346 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 67
  Out: 8.8.8.8/53 --> 1.1.1.2/13144;udp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0
Total sessions: 7

Unfortunately, the machine does not have internet access yet. As we are translating to an address other than our interface IP, the upstream router does not have an ARP entry for it. To solve this problem, we could add a static route on the “ISP” router, or configure Proxy-ARP on the SRX. In the real world, getting an ISP to make changes would take days so let’s do Proxy ARP.

First, find the interface which has our public IP:

[edit security nat]
root@NP-vSRX-01# run show interfaces terse | match 1.1.1.1
ge-0/0/0.0              up    up   inet     1.1.1.1/28

Then, configure the proxy-arp as a global NAT command: 

[edit security nat]
root@NP-vSRX-01# set proxy-arp interface ge-0/0/0.0 address 1.1.1.2

Let’s see if we now have more sessions from the clients:

root@NP-vSRX-01# run show security flow session source-prefix 10.0.200.0/24
Session ID: 38967, Policy name: FW-PermitWeb/4, Timeout: 1792, Valid
  In: 10.0.200.10/54278 --> 54.149.61.73/443;tcp, If: ge-0/0/2.0, Pkts: 10, Bytes: 1265
  Out: 54.149.61.73/443 --> 1.1.1.2/4408;tcp, If: ge-0/0/0.0, Pkts: 8, Bytes: 3905

Session ID: 38971, Policy name: FW-PermitWeb/4, Timeout: 292, Valid
  In: 10.0.200.10/52289 --> 91.189.89.88/80;tcp, If: ge-0/0/2.0, Pkts: 7, Bytes: 1145
  Out: 91.189.89.88/80 --> 1.1.1.2/29288;tcp, If: ge-0/0/0.0, Pkts: 5, Bytes: 952

Session ID: 38975, Policy name: FW-PermitWeb/4, Timeout: 298, Valid
  In: 10.0.200.10/42145 --> 93.184.220.29/80;tcp, If: ge-0/0/2.0, Pkts: 7, Bytes: 1250
  Out: 93.184.220.29/80 --> 1.1.1.2/24688;tcp, If: ge-0/0/0.0, Pkts: 5, Bytes: 1844

Session ID: 38986, Policy name: FW-PermitWeb/4, Timeout: 1792, Valid
  In: 10.0.200.10/39442 --> 68.232.34.191/443;tcp, If: ge-0/0/2.0, Pkts: 9, Bytes: 1144
  Out: 68.232.34.191/443 --> 1.1.1.2/5689;tcp, If: ge-0/0/0.0, Pkts: 16, Bytes: 14208

### omitted for brevity ###

Session ID: 39167, Policy name: FW-PermitWeb/4, Timeout: 1792, Valid
  In: 10.0.200.10/42964 --> 37.252.170.5/443;tcp, If: ge-0/0/2.0, Pkts: 7, Bytes: 1577
  Out: 37.252.170.5/443 --> 1.1.1.2/6620;tcp, If: ge-0/0/0.0, Pkts: 6, Bytes: 1515

Session ID: 39169, Policy name: FW-PermitWeb/4, Timeout: 1792, Valid
  In: 10.0.200.10/42966 --> 37.252.170.5/443;tcp, If: ge-0/0/2.0, Pkts: 8, Bytes: 1641
  Out: 37.252.170.5/443 --> 1.1.1.2/25579;tcp, If: ge-0/0/0.0, Pkts: 7, Bytes: 1636

Session ID: 39172, Policy name: FW-PermitWeb/4, Timeout: 1794, Valid
  In: 10.0.200.10/45036 --> 37.252.170.182/443;tcp, If: ge-0/0/2.0, Pkts: 11, Bytes: 3599
  Out: 37.252.170.182/443 --> 1.1.1.2/32160;tcp, If: ge-0/0/0.0, Pkts: 10, Bytes: 6143
Total sessions: 55

Now that it’s working and we have HTTP and HTTPS sessions established, here is the full configuration again: 

[edit security nat]
root@NP-vSRX-01# show
source {
    pool SNAT-Pool-Trust-to-Internet {
        address {
            1.1.1.2/32;
        }
    }
    rule-set NAT-Trust-to-Internet {
        from zone trust;
        to zone untrust;
        rule NAT-Source-VLAN200 {
            match {
                source-address 10.0.200.0/24;
            }
            then {
                source-nat {
                    pool {
                        SNAT-Pool-Trust-to-Internet;
                    }
                }
            }
        }
    }
}
proxy-arp {
    interface ge-0/0/0.0 {
        address {
            1.1.1.2/32;
        }
    }
}

Translating to a range, with PAT

When using Port Address Translation, using one IP address gives us a theoretical 65.536 available ports (less are used for outbound connections), which means an equal amount of concurrent sessions. When we are nearing the limit with one IP address, we can add more addresses to the pool.

Suppose that we want to add 1.1.1.3/32 to the mix, we have two options. We can change the mask to /31:

[edit security nat source pool SNAT-Pool-Trust-to-Internet]
root@NP-vSRX-01# show
address {
    1.1.1.2/31;
}

Or, we can specify a from-to range:

[edit security nat source pool SNAT-Pool-Trust-to-Internet]
root@NP-vSRX-01# show
address {
    1.1.1.2/32 to 1.1.1.3/32;
}

After a commit, the flow table shows it’s translating to both 1.1.1.2 and 1.1.1.3 for one of my lab machines:

[edit security nat source pool SNAT-Pool-Trust-to-Internet]
root@NP-vSRX-01# run show security flow session
Session ID: 123095, Policy name: FW-PermitWeb/4, Timeout: 52, Valid
  In: 10.0.200.11/10224 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 3, Bytes: 189
  Out: 8.8.8.8/53 --> 1.1.1.3/15041;udp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

  ### omitted ### 
  
Session ID: 123104, Policy name: FW-PermitWeb/4, Timeout: 2, Valid
  In: 10.0.200.11/24055 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 67
  Out: 8.8.8.8/53 --> 1.1.1.2/26041;udp, If: ge-0/0/0.0, Pkts: 1, Bytes: 179

Session ID: 123105, Policy name: FW-PermitWeb/4, Timeout: 58, Valid
  In: 10.0.200.11/57407 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 65
  Out: 8.8.8.8/53 --> 1.1.1.3/2018;udp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

Session ID: 123106, Policy name: FW-PermitWeb/4, Timeout: 2, Valid
  In: 10.0.200.11/46570 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 67
  Out: 8.8.8.8/53 --> 1.1.1.2/11394;udp, If: ge-0/0/0.0, Pkts: 1, Bytes: 123

Session ID: 123107, Policy name: FW-PermitWeb/4, Timeout: 18, Valid
  In: 10.0.200.11/33438 --> 91.189.92.201/80;tcp, If: ge-0/0/2.0, Pkts: 2, Bytes: 120
  Out: 91.189.92.201/80 --> 1.1.1.3/17036;tcp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0
Total sessions: 9

Unfortunately, this doesn’t always work flawlessly. We can instruct JunOS to always NAT one particular client to the same external IP by adding the global source-NAT command address-persistent

[edit security nat source]
root@NP-vSRX-01# set address-persistent

[edit security nat source]
root@NP-vSRX-01# commit
commit complete

Disabling Port Address Translation

By default, the SRX will translate the outgoing port to a random number. We can disable this by adding port no-translation to the pool configuration.

Assume the following configuration:

  • The previous SNAT pool of 1.1.1.2/31 will remain as configured but PAT will be disabled
  • If the SRX runs out of available ports, we will PAT to the interface IP. This is referred to as an overflow pool.

SourceNAT configuration:

[edit security nat source pool SNAT-Pool-Trust-to-Internet]
root@NP-vSRX-01# show
address {
    1.1.1.2/32 to 1.1.1.3/32;
}
port {
    no-translation;
}
overflow-pool interface;

As shown below, the outgoing port stays the same on both the ingress and egress session. 

oot@NP-vSRX-01# run show security flow session
Session ID: 164827, Policy name: FW-PermitWeb/4, Timeout: 290, Valid
  In: 10.0.200.10/48125 --> 91.189.91.23/80;tcp, If: ge-0/0/2.0, Pkts: 25, Bytes: 5621
  Out: 91.189.91.23/80 --> 1.1.1.2/48125;tcp, If: ge-0/0/0.0, Pkts: 24, Bytes: 5768[edit]


To conclude, here are some show commands that will help during config and troubleshooting


root@NP-vSRX-01> show security nat source summary
Total port number usage for port translation pool: 64512
Maximum port number for port translation pool: 33554432
Total pools: 1
Pool                 Address                  Routing              PAT  Total
Name                 Range                    Instance                  Address
SNAT-Pool-Trust-to-Internet 1.1.1.2-1.1.1.2   default              yes  1

Total rules: 1
Rule name          Rule set       From              To                   Action
NAT-Source-VLAN200 NAT-Trust-to-Internet trust      untrust              SNAT-Pool-Trust-to-Internet



root@NP-vSRX-01> show security nat source pool SNAT-Pool-Trust-to-Internet

Pool name          : SNAT-Pool-Trust-to-Internet
Pool id            : 4
Routing instance   : default
Host address base  : 0.0.0.0
Port               : [1024, 63487]
Twin port          : [63488, 65535]
Port overloading   : 1
Address assignment : no-paired
Total addresses    : 1
Translation hits   : 275
Address range                        Single Ports   Twin Ports
            1.1.1.2 - 1.1.1.2            1              0



root@NP-vSRX-01> show security nat source rule all
Total rules: 1
Total referenced IPv4/IPv6 ip-prefixes: 1/0

source NAT rule: NAT-Source-VLAN200   Rule-set: NAT-Trust-to-Internet
  Rule-Id                    : 1
  Rule position              : 1
  From zone                  : trust
  To zone                    : untrust
  Match
    Source addresses         : 10.0.200.0      - 10.0.200.255
  Action                        : SNAT-Pool-Trust-to-Internet
    Persistent NAT type         : N/A
    Persistent NAT mapping type : address-port-mapping
    Inactivity timeout          : 0
    Max session number          : 0
  Translation hits           : 275
    Successful sessions      : 275
    Failed sessions          : 0
  Number of sessions         : 1
JNCIS-SEC, Security

JNCIS-SEC Lab – Interface NAT on the SRX

1 Comment

In this NAT configuration example I will be configuring Interface Network Adress Translation on the Juniper SRX, which will translate the source address of the original packets to the external interface addresss of the SRX.

This is the topology I will be using for all NAT configurations.

SRX NAT topology

These are the requirements for the configuration:

  • Traffic from the hosts in range 10.0.200.0/24
  • Destined to the untrust zone (the internet)
  • will be SNAT’ed to external interface IP of 1.1.1.1/32

First, I will configure an address book object for the network range.

[edit security zones security-zone trust]
root@NP-vSRX-01# set address-book address Net-10.0.200.0-24 10.0.200.0/24

And configure a security policy that allows http, https and dns-udp to the internet (any).

[edit security policies from-zone trust to-zone untrust policy FW-PermitWeb]
root@NP-vSRX-01# show
match {
    source-address Net-10.0.200.0-24;
    destination-address any;
    application [ junos-http junos-https junos-dns-udp ];
}
then {
    permit;
    log {
        session-close;
    }
}

To define the source NAT, I will first create a rule set that is specific for this zone pair.

Note – Rule-sets are where you will group different NAT rules based on traffic direction. You can match on interface, zone and routing-instance, as displayed below. When two rule-sets match for a particular traffic flow, the most specific one will be preferred, with interface being the most specific, then zones and finally routing-instances. 

[edit security nat source rule-set NAT-Trust-to-Internet]
root@NP-vSRX-01# set from ?
Possible completions:
+ interface            Source interface list
+ routing-instance     Source routing instance list
+ zone                 Source zone list

The rule-set for this zone pair: 

[edit security nat source]
root@NP-vSRX-01# show
rule-set NAT-Trust-to-Internet {
    from zone trust;
    to zone untrust;
}

And here is the NAT rule I have defined: 

[edit security nat source rule-set NAT-Trust-to-Internet]
root@NP-vSRX-01# show rule NAT-Source-VLAN200
match {
    source-address 10.0.200.0/24;
}
then {
    source-nat {
        interface;
    }
}

I could have also defined to match on 0.0.0.0/0 as the destination address, but that would just have been one more line of code.

Verifiying the translations: 

root@NP-vSRX-01> show security flow session source-prefix 10.0.200.0/24
Session ID: 17713, Policy name: FW-PermitWeb/4, Timeout: 2, Valid
  In: 10.0.200.10/49751 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 55
  Out: 8.8.8.8/53 --> 1.1.1.1/29242;udp, If: ge-0/0/0.0, Pkts: 1, Bytes: 71

Session ID: 17714, Policy name: FW-PermitWeb/4, Timeout: 2, Valid
  In: 10.0.200.10/49751 --> 8.8.4.4/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 55
  Out: 8.8.4.4/53 --> 1.1.1.1/13555;udp, If: ge-0/0/0.0, Pkts: 1, Bytes: 71
Total sessions: 2

We see an internal traffic flow from 10.0.200.10 going to 8.8.8.8 and 8.8.4.4 (IN). The return traffic (OUT) is being sent to a translated port on 1.1.1.1, the interface IP.
This means that the NAT is working as required.

For a brief summary of the NAT configuration, enter the following: 

root@NP-vSRX-01> show security nat source summary
Total port number usage for port translation pool: 0
Maximum port number for port translation pool: 33554432
Total pools: 0

Total rules: 1
Rule name          Rule set       From              To                   Action
NAT-Source-VLAN200 NAT-Trust-to-Internet trust      untrust              interface

And to view even more detail and some statistics about the rule: 

root@NP-vSRX-01> show security nat source rule NAT-Source-VLAN200

source NAT rule: NAT-Source-VLAN200   Rule-set: NAT-Trust-to-Internet
  Rule-Id                    : 1
  Rule position              : 1
  From zone                  : trust
  To zone                    : untrust
  Match
    Source addresses         : 10.0.200.0      - 10.0.200.255
  Action                        : interface
    Persistent NAT type         : N/A
    Persistent NAT mapping type : address-port-mapping
    Inactivity timeout          : 0
    Max session number          : 0
  Translation hits           : 604
    Successful sessions      : 604
    Failed sessions          : 0
  Number of sessions         : 0
JNCIS-SEC, Security

SRX Screen Options – Part 3

Leave a comment

Last post in this series about Juniper Screen Options. Again, I will be working on the topology below.

SRX Screen Options Topology

OS Attacks: Ping of Death, Teardrop & WinNuke

These three are pretty old attacks, so unless you are still running some legacy system, you shouldn’t be worried about them. Anyway, here goes:

  • Ping of death – This is a rather old attack in which packets were sent with a size exceeding the maximum IP datagram size of 65.535 bytes, including the headers. When reassembled, some operating systems experienced a buffer overflow, causing all sorts of unwanted behaviour. Read all about it here
  • Teardrop attack – triggered by sending IP fragments with overlapping data to a remote host. When reassembling, some OS’s would crash. More information here…
  • WinNuke – This is a one-packet-kill attack, which was performed by sending a NetBIOS packet with Out-of-Band data. Windows 95 could not handle this and would possibly BSOD. Used in abundance on IRC in the days 🙂 More info here

Enabling these screens is just a matter of turning on the switch: 

[edit security screen ids-option Attack-Screen]
root@NP-vSRX-01# set tcp winnuke

[edit security screen ids-option Attack-Screen]
root@NP-vSRX-01# set ip tear-drop

[edit security screen ids-option Attack-Screen]
root@NP-vSRX-01# set icmp ping-death

By enabling it, JunOS will look for the typical attack signatures in the packets and when detected, filter it. It’s not a bad idea to leave it enabled. Who knows, you might find someone still trying the WinNuke attack against your Windows 2012 servers 🙂

I don’t have any prehistoric OS’es lying around so I can’t test these ones.

unknown-protocol – Blocking packets with invalid protocol numbers

Although your security policy will probably be allowing only TCP, UDP and perhaps some traffic related to VPNs or routing protocols, this screen will check the packets for invalid (non-assigned) IP protocols before they enter the traffic flow. IANA has a list with all the protocol number assignments. Any protocol number not on the list should be dropped by JunOS. Wonder if Juniper keeps the software updated when new numbers are allocated.

Enabling the screen is again straight-forward: 

[edit security screen ids-option Attack-Screen]
root@NP-vSRX-01# set ip bad-option

syn-frag – Fragmented SYN packets

SYN packets are always very minimal in size, so it’s abnormal to have a SYN packet with the Fragment bit set. Junos will block this type of packet upon arrival on the interface. 

[edit security screen ids-option Attack-Screen]
root@NP-vSRX-01# set tcp syn-frag

By configuring nping to set the SYN-flag and the More Fragments bit we can craft a syn-frag packet

lab@Host200:~$ sudo nping --tcp --flags SYN 10.0.100.100 -p 21 --mf

Starting Nping 0.6.46 ( http://nmap.org/nping ) at 2015-08-16 20:36 CEST
SENT (0.0025s) TCP 10.0.200.200:15585 > 10.0.100.100:21 S ttl=64 id=52614 iplen=40 frag offset=0+  seq=3992461002 win=1480
SENT (1.0027s) TCP 10.0.200.200:15585 > 10.0.100.100:21 S ttl=64 id=52614 iplen=40 frag offset=0+  seq=3992461002 win=1480
SENT (2.0040s) TCP 10.0.200.200:15585 > 10.0.100.100:21 S ttl=64 id=52614 iplen=40 frag offset=0+  seq=3992461002 win=1480
SENT (3.0053s) TCP 10.0.200.200:15585 > 10.0.100.100:21 S ttl=64 id=52614 iplen=40 frag offset=0+  seq=3992461002 win=1480
SENT (4.0066s) TCP 10.0.200.200:15585 > 10.0.100.100:21 S ttl=64 id=52614 iplen=40 frag offset=0+  seq=3992461002 win=1480

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 5 (200B) | Rcvd: 0 (0B) | Lost: 5 (100.00%)
Nping done: 1 IP address pinged in 5.01 seconds

And again, the SRX performed as expected: 

2015-08-16 18:31:22 UTC  SYN fragment! source: 10.0.200.200:53479, destination: 10.0.100.100:21, zone name: attacker, interface name: ge-0/0/2.0, action: drop

Configuring the aggressive session ageout option

Another way to keep your firewalls session table from getting clogged is to configure an aggressive session timeout, also known as early aging. This will cause the SRX to age out idle sessions significantly faster than the default values (e.g. 30 minutes for TCP). All you need to do is define a low and high watermark, which is a percentage of the total sessions your box can handle, and a new “aggressive” age-out timer.

You can find out how much your SRX supports by entering the show security monitoring fpc 0 command (more FPCs are possible depending on model) and observing the Max flow session field. For example, the vSRX supports a total of 262144 sessions. 

root@NP-vSRX-01> show security monitoring fpc 0
FPC 0
  PIC 0
    CPU utilization          :    0 %
    Memory utilization       :   63 %
    Current flow session     :    3
    Current flow session IPv4:    3
    Current flow session IPv6:    0
    Max flow session         : 262144
Total Session Creation Per Second (for last 96 seconds on average):    0
IPv4  Session Creation Per Second (for last 96 seconds on average):    0
IPv6  Session Creation Per Second (for last 96 seconds on average):    0

There are three values to consider when configuring the feature:

high-watermark – This is the percentage of total session capacity that should be reached before the mechanism kicks in. Suppose that we define a high watermark of 75 percent on this vSRX, then it will start applying the aggressive timer once it reaches 196608 (=262144*0.75) sessions.

low-watermark – The percentage of session capacity it should reach to disable aggressive aging and go back to the default session timeout.

early-ageout – Agressive timeout period, in seconds.

Suppose that we want the vSRX to start agressively shutting down sessions that have been idle for more than 30 seconds once it is at 75 percent of its capacity, and resume normal operations when it hits 50 percent again, we would go to the security flow branch and configure the following: 

[edit security flow]
root@NP-vSRX-01# show
aging {
    early-ageout 30;
    low-watermark 50;
    high-watermark 75;
}

Monitoring Screen Options

A couple of commands that will help monitor the alarms and configuration

show configuration security screen – Shows the syntax in the config file

root@NP-vSRX-01> show configuration security screen
ids-option Attack-Screen {
    description "Screen Attacker Zone";
    icmp {
        ip-sweep;
    }
    ip {
        bad-option;
        record-route-option;
        timestamp-option;
        security-option;
        stream-option;
        spoofing;
        source-route-option;
        loose-source-route-option;
        strict-source-route-option;
    }
    tcp {
        syn-fin;
        fin-no-ack;
        tcp-no-flag;
        syn-frag;
        port-scan threshold 3000;
        syn-ack-ack-proxy threshold 4;
        land;
    }
}

show security screen ids-option [screen-name] – shows the enabled screens in a more readable format

root@NP-vSRX-01> show security screen ids-option Attack-Screen
Description: Screen Attacker Zone
Screen object status:

Name                                         Value
  TCP port scan threshold                    3000
  ICMP address sweep threshold               5000
  IP spoofing                                enabled
  IP source route option                     enabled
  TCP land attack                            enabled
  TCP SYN fragment                           enabled
  TCP no flag                                enabled
  IP bad options                             enabled
  IP record route option                     enabled
  IP timestamp option                        enabled
  IP security option                         enabled
  IP loose source route option               enabled
  IP strict source route option              enabled
  IP stream option                           enabled
  TCP SYN FIN                                enabled
  TCP FIN no ACK                             enabled
  TCP SYN-ACK-ACK proxy threshold            4

show security zones [zone-name] – Shows you which screen is applied to a particular zone

root@NP-vSRX-01> show security zones attacker

Security zone: attacker
  Send reset for non-SYN session TCP packets: Off
  Policy configurable: Yes
  Screen: Attack-Screen
  Interfaces bound: 1
  Interfaces:
    ge-0/0/2.0

show security screen statistics zone [zone-name] – shows you the hitcount for all the screens. 

root@NP-vSRX-01> show security screen statistics zone attacker
Screen statistics:

IDS attack type                              Statistics
  ICMP flood                                 0
  UDP flood                                  0
  TCP winnuke                                0
  TCP port scan                              47
  UDP port scan                              0
  ICMP address sweep                         0
  TCP sweep                                  0
  UDP sweep                                  0
  IP tear drop                               0
  TCP SYN flood                              0
  IP spoofing                                0
  ICMP ping of death                         0
  IP source route option                     0
  TCP land attack                            0
  TCP SYN fragment                           13
  TCP no flag                                791118
  IP unknown protocol                        0
  IP bad options                             0
  IP record route option                     0
  IP timestamp option                        0
  IP security option                         0
  IP loose source route option               0
  IP strict source route option              0
  IP stream option                           0
  ICMP fragment                              0
  ICMP large packet                          0
  TCP SYN FIN                                20
  TCP FIN no ACK                             20
  Source session limit                       0
  TCP SYN-ACK-ACK proxy                      0
  IP block fragment                          0
  Destination session limit                  0
  IPv6 extension header                      0
  IPv6 extension hop by hop option           0
  IPv6 extension destination option          0
  IPv6 extension header limit                0
  IPv6 malformed header                      0
  ICMPv6 malformed packet                    0

show security log – Shows you the syslog events with a bit more detail. Best to send this to a syslog server for retention… 

2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:58501, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:58502, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:58503, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:58504, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:58505, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7343, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7344, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7345, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7346, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7347, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7348, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7349, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7350, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7351, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7352, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-16 18:45:31 UTC  No TCP flag! source: 10.0.200.200:7353, destination: 10.0.100.100:0, zone name: attacker, interface name: ge-0/0/2.0, action: drop

Wrapping up

This was my last post on the Screen Options. I have omitted a few from the JNCIS-SEC study guide, either because I see little use for them in production or because there’s little to do in the lab besides turning it on.

Frankly, I never bothered with Screen Options because I wasn’t all familiar with them but I really see the benefits of having many of them enabled.

Anyway, if you’ve made it through the posts, thanks for reading and feel free to add a comment. Next labs, all about NAT 🙂

JNCIS-SEC, Security

SRX Screen Options – Part 2

Leave a comment

In my previous post I already went into a couple of screens, mainly ones that detect or block network reconnaissance tactics, such as Ping Sweeps, Port Scans and OS detection. This article will focus more on the DoS and DDoS attacks itself, like SYN and session floods.

The network topology will remain the same as last time, with one host on the dmz network and an attacker on the outside, where the Screen is positioned.

SRX Screen Options Topology

ip-spoofing – Unicast Reverse Path Forwarding check

Similar to how the RPF mechanism on routers and other L3 devices works, the IP-Spoofing Screen compares the source address of the incoming packet against the longest matched prefix in the forwarding-table. If the best route found is pointing to an interface other than the one on which the packet was received, the OS decides it must be a spoofed packet and drops it.

We already have a Screen profile configured from the previous post, so I will just be adding the ip-spoofing option:

[edit security screen ids-option Attack-Screen]
root@NP-vSRX-01# set ip spoofing

[edit security screen ids-option Attack-Screen]
root@NP-vSRX-01# show | compare
[edit security screen ids-option Attack-Screen ip]
+  spoofing;

To spoof the packets’ source IP, I will be using NPING, which gives you granular control of all the fields and options in the L3 and L4 protocol headers.

I will be sending 5 packets, destined for the server’s IP address on port 80, with a spoofed IP address of 10.0.100.50. 

lab@Host200:~$ sudo nping --tcp -p 80 -S 10.0.100.50 10.0.100.100

Starting Nping 0.6.46 ( http://nmap.org/nping ) at 2015-07-28 23:10 CEST
SENT (0.0028s) TCP 10.0.100.50:49704 > 10.0.100.100:80 S ttl=64 id=13538 iplen=40  seq=3917867081 win=1480
SENT (1.0032s) TCP 10.0.100.50:49704 > 10.0.100.100:80 S ttl=64 id=13538 iplen=40  seq=3917867081 win=1480
SENT (2.0046s) TCP 10.0.100.50:49704 > 10.0.100.100:80 S ttl=64 id=13538 iplen=40  seq=3917867081 win=1480
SENT (3.0060s) TCP 10.0.100.50:49704 > 10.0.100.100:80 S ttl=64 id=13538 iplen=40  seq=3917867081 win=1480
SENT (4.0073s) TCP 10.0.100.50:49704 > 10.0.100.100:80 S ttl=64 id=13538 iplen=40  seq=3917867081 win=1480

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 5 (200B) | Rcvd: 0 (0B) | Lost: 5 (100.00%)
Nping done: 1 IP address pinged in 5.01 seconds

The source IP obviously belongs to the same subnet as the destination so if the ip-spoofing Screen works as advertised, we should see it in the logs: 

2015-07-28 21:06:30 UTC  IP spoofing! source: 10.0.100.50, destination: 10.0.100.100, protocol-id: 6, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-07-28 21:06:31 UTC  IP spoofing! source: 10.0.100.50, destination: 10.0.100.100, protocol-id: 6, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-07-28 21:06:32 UTC  IP spoofing! source: 10.0.100.50, destination: 10.0.100.100, protocol-id: 6, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-07-28 21:06:33 UTC  IP spoofing! source: 10.0.100.50, destination: 10.0.100.100, protocol-id: 6, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-07-28 21:06:34 UTC  IP spoofing! source: 10.0.100.50, destination: 10.0.100.100, protocol-id: 6, zone name: attacker, interface name: ge-0/0/2.0, action: drop

The packets were dropped -which is good- but unfortunately, the log doesn’t mention any source or destination ports in the logs. If somebody was trying to send spoofed packets to my server, it would be great to know which port they were targeting.

Sidenote – the SRX also has a second way of configuring this, being the standard rpf-check, which is covered in the JNCIA curriculum. This one is easier though.

session-limt – Limiting sessions by Source or Destination IP

This Screen can put a cap on the maximum number of connections any given source or destination IP can create. Any subsequent connections will be dropped. This is a very basic setting, and it does require you to establish a baseline for the amount of connections you expect on any given server. If you are unsure at first, you can configure the alarm-without-drop setting to create a baseline first.

For this example, suppose that we are a small shop running an FTP service and we never expect more than 64 simultaneous connections to our server. I will configure a destination-limit of 64 connections and a source-limit of 16 to protect it against flooding by a single remote host. 

[edit security screen ids-option Attack-Screen]
root@NP-vSRX-01# set limit-session destination-ip-based 64 source-ip-based 16

Flooding the server with connection attempts, 1000 packets per second. 

lab@Host200:~$ sudo nping 10.0.100.100 --tcp-connect -rate=1000 -c 5000 -q $1 -p 21

Starting Nping 0.6.46 ( http://nmap.org/nping ) at 2015-08-11 23:10 CEST
Max rtt: 1.956ms | Min rtt: 0.108ms | Avg rtt: 0.950ms
TCP connection attempts: 5000 | Successful connections: 16 | Failed: 4984 (99.68%)
Nping done: 1 IP address pinged in 9.17 seconds

As configured on the screen, the remote host only received 16 responses from the FTP server. Again, this logging is pretty basic – no destination IP or port numbers mentioned…

2015-08-11 21:33:50 UTC  Src IP session limit! source: 10.0.200.200, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-11 21:33:50 UTC  Src IP session limit! source: 10.0.200.200, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-11 21:33:50 UTC  Src IP session limit! source: 10.0.200.200, zone name: attacker, interface name: ge-0/0/2.0, action: drop

By using randomized source IP addresses (with hping3) I was also able to trigger the destination-limit. 

2015-08-11 21:27:04 UTC  Dst IP session limit! destination: 10.0.100.100, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-11 21:27:04 UTC  Dst IP session limit! destination: 10.0.100.100, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-11 21:27:04 UTC  Dst IP session limit! destination: 10.0.100.100, zone name: attacker, interface name: ge-0/0/2.0, action: drop

It’s pretty basic, but it does protect your device from getting flooded by remote hosts. While testing without the screen, it wasn’t that difficult to DoS my virtual machines’ FTP, SSH and Telnet daemons when flooding connections (at 1 Gbps 🙂 )

syn-ack-ack – Handshake proxying

Similar to the session-limit, the SYN-ACK-ACK screen will limit the number of concurrent sessions any untrusted host can establish. This time, the SRX will serve as the middle-man between the source and destination hosts. First, the SRX will check the session table and, if a new session needs to be initiated, perform the three-way handshake with the initiator. Once the handshake between the remote host and SRX is complete, the SRX will proxy the three-way handshake to the server, after which the original source and destination can communicate.

The SRX keeps track of all the sessions it has established and will, once the syn-ack-ack proxy treshold for a particular source IP has been reached, reject any further connection attempts.

Defining a threshold of 512 sesssions:

[edit security screen ids-option Attack-Screen]
root@NP-vSRX-01# set tcp syn-ack-ack-proxy threshold 512

Again, it would be best to make a good baseline of expected traffic patterns before implementing this…

syn-flood – embryonic session floods

Probably the most commmon Layer4 attack is the SYN flood, in which your boxes get flooded with SYN packets from seemingly thousands of hosts. Although it is quite possible that you’re being pwned by a botnet, it’s more likely that the packets are being spoofed with random source IPs. The server will then create a half-open socket, reply to the bogus IP with a SYN-ACK and wait for a response that will never come. Obviously, at thousand and thousands of packets per second, this can fill up the session table quite rapidly and kill your server.

By enabling this screen, the SRX will monitor and police the number of SYN packets passing through the device. There are five parameters to consider for the syn-flood screen:

  • Attack Threshold – the total number of SYN packets per second that can be received before the SRX starts proxying SYN packets, taking the burden off the servers shoulders
  • Alarm Threshold – how many embryonic sessions can be created before a syslog event is logged
  • Source Threshold – the total number of SYN packets that can be received from any given source IP
  • Destination Threshold – the number of SYN packets that can be received destined for a particular destination IP (your server)
  • Timeout – how long the SRX should wait before killing of a half-open session

Let’s illustrate with an example. At 100 SYN packets, the SRX will go into proxying mode. When 50 more packets are received within a second, an alarm will be logged. The threshold per source IP is 50 pps. Half-open sessions will time out after 10 seconds. 

[edit security screen ids-option Attack-Screen tcp syn-flood]
root@NP-vSRX-01# show
alarm-threshold 150;
attack-threshold 100;
source-threshold 50;
timeout 10;

Flooding port 21 with hping3: 

lab@Host200:~$ sudo hping3 -S --flood -V $1 10.0.100.100 -p 21
using eth0, addr: 10.0.200.200, MTU: 1500
HPING 10.0.100.100 (eth0 10.0.100.100): S set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
--- 10.0.100.100 hping statistic ---
4735022 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

The SRX security log: 

2015-08-14 20:33:19 UTC  SYN flood Src-IP based! source: 10.0.200.200:1106, destination: 10.0.100.100:21, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-14 20:33:19 UTC  SYN flood Src-IP based! source: 10.0.200.200:1107, destination: 10.0.100.100:21, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-14 20:33:19 UTC  SYN flood Src-IP based! source: 10.0.200.200:1108, destination: 10.0.100.100:21, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-14 20:33:19 UTC  SYN flood! destination: 10.0.100.100, zone name: attacker, interface name: ge-0/0/2.0, action: alarm-without-drop
2015-08-14 20:33:20 UTC  SYN flood! destination: 10.0.100.100, zone name: attacker, interface name: ge-0/0/2.0, action: alarm-without-drop
2015-08-14 20:33:21 UTC  SYN flood! destination: 10.0.100.100, zone name: attacker, interface name: ge-0/0/2.0, action: alarm-without-drop

Another good example can be found on the Juniper site.

Enabling SYN Cookies

With the SYN cookie feature, the SRX will take some attributes of the original SYN packet and run it through a mathematical formula, resulting in a hashed number. This number will be used as the Initial Sequence number in the returned SYN-ACK packet. When the final ACK packet is received, it is validated against the “challenge” that was sent in the initial response.

You can read all about SYN Cookies here and here.

Enabling it is not done at the ids-options, but at the flow options: 

[edit security flow]
root@NP-vSRX-01# set syn-flood-protection-mode syn-cookie

Dropping TCP LAND attacks

By sending a specially crafted TCP packet to a server, which contains the same IP as destination in the source field it is possible to exhaust the session table. The server would then send the responses to itself and create half-open sessions. This is called a Local Area Network Denial attack. Seems like recent operating systems are no longer vulnerable but then again, not everyone is running recent operating systems 🙂

Enabling it – I also disabled the RPF check just to be sure it will be hit: 

[edit security screen ids-option Attack-Screen]
root@NP-vSRX-01# set tcp land

I first tried triggering this with just a couple of packets crafted in nping, but it was not triggering the Screen. Seems like the LAND screen doesn’t filter every packet, but instead only triggers when being flooded…

lab@Host200:~$ sudo hping3 -S --flood -V $1 10.0.100.100 -p 21 -a 10.0.100.100
using eth0, addr: 10.0.200.200, MTU: 1500
HPING 10.0.100.100 (eth0 10.0.100.100): S set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
--- 10.0.100.100 hping statistic ---
4561685 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

This time, the LAND attack was logged on the SRX: 

2015-08-14 21:09:59 UTC  Land attack! source: 10.0.100.100:21, destination: 10.0.100.100:21, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-14 21:10:00 UTC  Land attack! source: 10.0.100.100:21, destination: 10.0.100.100:21, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-14 21:10:01 UTC  Land attack! source: 10.0.100.100:21, destination: 10.0.100.100:21, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-14 21:10:01 UTC  Land attack! source: 10.0.100.100:21, destination: 10.0.100.100:21, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-14 21:10:01 UTC  Land attack! source: 10.0.100.100:21, destination: 10.0.100.100:21, zone name: attacker, interface name: ge-0/0/2.0, action: drop
2015-08-14 21:10:02 UTC  Land attack! source: 10.0.100.100:21, destination: 10.0.100.100:21, zone name: attacker, interface name: ge-0/0/2.0, action: drop

However, it didn’t stop all packets. This was rushing across the screen on the end node, using tcpdump: 

23:14:01.539414 IP 10.0.100.100.21 > 10.0.100.100.4271: Flags [S.], seq 1210268274, ack 1980846482, win 0, length 0
23:14:01.539415 IP 10.0.100.100.21 > 10.0.100.100.4272: Flags [S.], seq 1893206533, ack 1324671463, win 0, length 0
23:14:01.539416 IP 10.0.100.100.21 > 10.0.100.100.4273: Flags [S.], seq 1640167563, ack 1602524016, win 0, length 0
23:14:01.539641 IP 10.0.100.100.21 > 10.0.100.100.4274: Flags [S.], seq 1406775185, ack 1845052534, win 0, length 0
23:14:01.539643 IP 10.0.100.100.21 > 10.0.100.100.4275: Flags [S.], seq 339434124, ack 711012714, win 0, length 0
23:14:01.539644 IP 10.0.100.100.21 > 10.0.100.100.4276: Flags [S.], seq 1167828292, ack 2077183650, win 0, length 0
23:14:01.539645 IP 10.0.100.100.21 > 10.0.100.100.4277: Flags [S.], seq 275256947, ack 780565910, win 0, length 0
23:14:01.539645 IP 10.0.100.100.21 > 10.0.100.100.4278: Flags [S.], seq 296173682, ack 804236181, win 0, length 0
23:14:01.539646 IP 10.0.100.100.21 > 10.0.100.100.4279: Flags [S.], seq 505740912, ack 547788184, win 0, length 0

So it does detect the land packets, but doesn’t block all of them. A better option in this case would be to enable the ip-spoofing option: 

2015-08-14 21:23:48 UTC  IP spoofing! source: 10.0.100.100, destination: 10.0.100.100, protocol-id: 6, zone name: attacker, interface name: ge-0/0/2.0, action: drop

I’ll be wrapping up here for today. Part three will cover the last Screen options from the JNCIS-SEC curriculum, mostly smaller options related to OS attacks and some of the IP header fields.

Thanks for reading!