Juniper (JunOS) SRX’s support ssh public key authentication.

nick> show configuration system login | display set
set system login user nick uid 2001
set system login user nick class super-user
set system login user nick authentication ssh-rsa "PASTE_KEY"
nick>

No-one likes to type passwords!

In my frustration I have given up and created a shell script which converts a CSV into an ASA output, simply create a two column CSV with Col A containing your starting IP and Col B containing you end IP.

The script is a recursive loop so should support large outputs such as 10.1.2.10 to 10.2.1.20 howvere I’m not actually sure you’d want that in your firewall config but I wrote the computability for the fun it!

Have fun, click “more” below if you can’t see the script!

#!/bin/bash

# Commas separated VAR....
IFS=","
while read name firstip lastip
# Loop around CSV
do

# Split up our first ip into it's octects
firstipfirstoctect=$(echo $firstip | awk -F "." '{print $1}')
firstipsecondoctect=$(echo $firstip | awk -F "." '{print $2}')
firstipthirdoctect=$(echo $firstip | awk -F "." '{print $3}')
firstipforthoctect=$(echo $firstip | awk -F "." '{print $4}')

# Split up our last IP into it's ocects
lastipfirstoctect=$(echo $lastip | awk -F "." '{print $1}')
lastipsecondoctect=$(echo $lastip | awk -F "." '{print $2}')
lastipthirdoctect=$(echo $lastip | awk -F "." '{print $3}')
lastipforthoctect=$(echo $lastip | awk -F "." '{print $4}')

	# Re-set BASH
	unset IFS 

	# Echo out the object GROUP name
	echo "object-group network $name"

	# Loop through 1st Octect
	for a in `seq $firstipfirstoctect $lastipfirstoctect`;
	do
		# test to see if we need to print the whole range
		if [ $firstipfirstoctect -lt $lastipfirstoctect ]
		then
			firstipsecondoctectCOUNTER="0"
			lastipsecondoctectCOUNTER="255"
		fi

		# first IP might not be 1
		if [ $a -eq $firstipfirstoctect ]
		then
			firstipsecondoctectCOUNTER=$firstipsecondoctect
		fi

		# last IP might not be 255
		if [ $a -eq $lastipfirstoctect ]
		then
			lastipsecondoctectCOUNTER=$lastipsecondoctect
		fi

			# Loop through 2nd Octect
			for b in `seq $firstipsecondoctect $lastipsecondoctect`;
			do

				# Same tests as before except, next octect.
				if [ $firstipsecondoctect -lt $lastipsecondoctect ]
				then
					firstipthirdoctectCOUNTER="0"
					lastipthirdoctectCOUNTER="255"
				fi

				if [ $b -eq $firstipsecondoctect ]
				then
					firstipthirdoctectCOUNTER=$firstipthirdoctect
				fi

				if [ $b -eq $lastipsecondoctect ]
				then
					lastipthirdoctectCOUNTER=$lastipthirdoctect
				fi

					# Loop through 3rd Octect
					for c in `seq $firstipthirdoctectCOUNTER $lastipthirdoctectCOUNTER`;
					do

						# copy / paste / tweak
						if [ $firstipthirdoctect -lt $lastipthirdoctect ]
						then
							firstipforthoctectCOUNTER="0"
							lastipforthoctectCOUNTER="255"
						fi

						if [ $c -eq $firstipthirdoctect ]
						then
							firstipforthoctectCOUNTER=$firstipforthoctect
						fi

						if [ $c -eq $lastipthirdoctect ]
						then
							lastipforthoctectCOUNTER=$lastipforthoctect
						fi

							# final octect... echo result.
							for d in `seq $firstipforthoctectCOUNTER $lastipforthoctectCOUNTER`;
							do
								echo " network-object $a.$b.$c.$d  255.255.255.255"
							done

					done
			done
	done

done<./FirewallRanges.csv

You can now configure access rules that are applied globally, as well as access rules that are applied to an interface. If the configuration specifies both a global access policy and interface-specific access policies, the interface-specific policies are evaluated before the global policy.

The following command was modified: access-group global

For users/companies which have migrated from Check Point to Cisco (usually to save on licensing fees), getting their head around a new interface level policy rather than a system (global) level is usually a bit of a challenge.

I’m looking forward to seeing if this really helps with policy migrations!

Strict Firewalling
IMO Strict Firewalling is the traditional way to implement your traffic policies (ACLS), each rule should be as tight as possible… the idea of “any” should not be used at all and ranges should be kept at a minimum; hosts better than subnets, source and destination IPs restricted, specific TCP ports (not ranges) used.

Service Led Firewalling
A term I think I made up, Service Led Fierwalling is where you relax the ACL/policy at the source… to host a DNS Zone you need to allow “anyone” to perform lookups so Strict Firewalling cannot be applied here but you do know the destination and the service so both of these should be defined/restricted as appropriate… you see what I mean here the policy is defined by the “service” provided.

Open Firewalling
Possibly a contradiction in terms but bare with me; there are some instances whereby implementing a firewall provides little benefit, one example I’ve seen was a customer’s security officer wanted an internal firewall (i.e. no internet connection) in front of their Microsoft file server, in order for AD & MS clients to work properly all the MS ports had to be opened… so server guys continuously complained, what exactly is the firewall doing? What is Open Firewalling? It’s the process of implementing a black list followed by a white list, rather than the traditional permit then drop processing that a firewall does; I’d create a rule that Drops Prohibited applications (such as P2P or unencrypted protocols) and then create a policy permitting all ports from legitimate IP ranges.

When would I use these?
Your firewall should be broken into zones, each zone meets both security policy and business requirements, you should then apply a firewalling technique to each zone. For example it’s not uncommon to have a back-end database which should only ever be accessed by the front end application, therefore it could be in a zone protected by Strict Firewalling; public services such as websites/email servers require flexibility on their source thus require service led firewalling. Occasionally your business or application requirements suggest that firewalling impedes things, using open firewalling to “clean” traffic compromises “security people wanting firewalls” and any historical business/application issues… the firewall is there perhaps protecting against syn-flood attacks & as previously suggested blocking prohibited apps yet the business doesn’t see any traditional firewall headaches.

I don’t agree you fool!
That’s your choice, there’s no correct answer to security, the business you work in and the security policy mandated from senior management direct what you do, these are just my approaches

Today’s challenge was to get to grips with Cisco’s ZBFW, there are a few examples out there if you google but this cisco pdf was the best resource I found.

I’m going to share with you my GNS3 config, my first gotcha was getting the “right” IOS version, the latest advanced sec 12.4 image for the 3725 doesn’t cut it, you need to get a copy of c3725-advsecurityk9-mz.124-15.T7.bin.

My plan was simple, I wanted to re-create this following pseudo ASA style configuration:

access-list inside permit icmp any any
access-list inside permit tcp any any eq telnet
access-list outside permit tcp any host 192.168.10.100 eq telnet
access-group inside in interface inside
access-group outside in interface outside

What’s funny is that is 5 lines of code for ZBFW it’s more than 20! Yes the IOS FW isn’t a statefull firewall like the ASA but still more than 4 times the work… anyway, moving on…

The ZBFW is broken into four parts:

• Assign Zones to Interfaces
• Create a class-map to define interesting traffic
• Create a policy-map to give your class an action
• Create a zone pair to give you class a direction

As you can see in the picture, I have three routers Inside, Outside & Gateway; we will generate traffic from Inside -> Outside (and vice versa) and Gateway will be our firewall. In this blog post I’ll discuss the inside -> outside policy, read though the attached config to work out how outside->inside works

Creating zones and applying them to interfaces is the easy bit…

!
zone security inside
 description LAN
zone security outside
 description Internet
!
interface FastEthernet0/0
 ip address 10.10.10.10 255.255.255.0
 zone-member security outside
!
interface FastEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 zone-member security inside

ZBFW supports traffic matching by protocol, ACL or both. To start with I need to create a class map equivalent of:

access-list inside permit icmp any any

So that looks like:

class-map type inspect match-any myinspectclass
 match protocol icmp

Our action to this applied via the policy map will be “inspect” … not “permit” like the access list, what we want to happen is the echo-request (echo) packet passing from the inside interface to the outside to be inspected so that the echo-reply packet is let back in…

policy-map type inspect myinspectpolicy
 class type inspect myinspectclass
  inspect

To apply this inside -> outside we create a zone-pair…

zone-pair security in-out source inside destination outside
 service-policy type inspect myinspectpolicy

Part 1 done. breath, take a break.

We can now ping from inside to outside, but outside to inside fails. Part two is to create a separate “flow” to allow telnet out. Now we could update our existing class-map, but it’s much clearer to create a new one, first we need an access-list…

ip access-list extended telnet_any
 permit tcp any any eq telnet

This will restrict our TCP protocol inspection to permit only telnet, without this ACL the following class map would permit (inspect) any TCP.

class-map type inspect match-all inspecttelnetclass
 match access-group name telnet_any
 match protocol tcp

Now that we have defined our traffic we can using the existing policy that permits the ICMP traffic through to permit this TCP thru, so this is the new policy map that replaces the one above:

policy-map type inspect myinspectpolicy
 class type inspect myinspectclass
  inspect
 class type inspect inspecttelnetclass
  inspect

The policy map will work top down, permitting ICMP traffic thru flow 1 (rule 1) and telnet through flow 2…. we don’t need to touch the zone pair

Attached is my GNS3 .net file and the three router configs [1,2,3], hopefully it all makes sense

• Solution Title: How do I control / change access using defaultfilter and initialpolicy?
• Solution ID: sk41117

There are various options given in the article, this…

ipso[nick]# cp -p $FWDIR/conf/initial_module.pf $FWDIR/conf/initial_module.pf.OLD
ipso[nick]# cp $FWDIR/lib/defaultfilter.ipso $FWDIR/conf/initial_module.pf
ipso[nick]# comp_init_policy -g
initial_module:
Compiled OK.
ipso[nick]#

… will do in most cases!

Take a look at this debug arp….

CiscoASA# debug arp
debug arp  enabled at level 1
CiscoASA#
CiscoASA# arp-set: added arp outside 192.168.1.122 001e.7000.1234 and updating NPs at 4301321940
arp-set: added arp inside 192.168.1.61 001a.7100.1234 and updating NPs at 4301321940

arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.120 001e.7a51.1234
arp-in: rqst for me from 192.168.1.125 for 192.168.1.120, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.120 001e.7a51.1234 to 192.168.1.125 001a.3000.1234

arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.73 001e.7a51.1234
arp-in: rqst for me from 192.168.1.125 for 192.168.1.73, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.73 001e.7a51.1234 to 192.168.1.125 001a.3000.1234
arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.69 001e.7a51.1234

arp-in: rqst for me from 192.168.1.125 for 192.168.1.69, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.69 001e.7a51.1234 to 192.168.1.125 001a.3000.1234

arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.123 001e.7a51.1234
arp-in: rqst for me from 192.168.1.125 for 192.168.1.123, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.123 001e.7a51.1234 to 192.168.1.125 001a.3000.1234
arp-in: response at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.125 ffff.ffff.ffff
arp-in: updating gratuitous ARP 192.168.1.125 - 001a.3000.1234
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
CiscoASA#

The firewall is replying to arp requests even though both the source & destination of the traffic are on the same (outside) interface, now I haven’t manged to work out why the firewall was doing this, but I did find a fix on the cisco forums.

sysopt noproxyarp outside

Names, IPs & MAC’s have been changed to protect the innocent.

I ran a packet capture and found that the phone was “bouncing” the RTP stream off the firewall rather than connecting directly to the peer phone… very weird! The problem was solved by enabling…

same-security-traffic permit intra-interface

I thought I post this for some future googlers!

The following example creates two redundant interfaces:

asa(config)# interface redundant 1
asa(config-if)# member-interface gigabitethernet 0/0
asa(config-if)# member-interface gigabitethernet 0/1
asa(config-if)# interface redundant 2
asa(config-if)# member-interface gigabitethernet 0/2
asa(config-if)# member-interface gigabitethernet 0/3

Reference: Adding a Redundant Interface

If you want to get online gaming working though your firewall there’s a really good online reference here and my specific grumble about having to open up a shed load of ports for EA’s Burnout paradise is documented in their support area.

To summarize, this is what I’ve got open:

General Playstation Network Ports, these always need to be open.

udp 3658
udp 3478-3479

Open these extra ones for Motor Storm

udp 3659 – 3660

Open these extra ones for Burnout

udp 3659
udp 9600-9699

If you to have a cisco pix, you’ll need to open an entry on your outside access-list, something like

access-list outside permit udp any any eq  3658

and you’ll need a static entry….

static (inside,outside) udp interface 3658 playstation3 3658 netmask 255.255.255.255

For lots of ports the access-list command supports the range statement, so

access-list outside permit udp any any range 9600 9699

But you won’t be so lucky with statics, you’ll have to add an entry for each port, I created a small bash shell script to automate the task…

#!/bin/bash
#9600-9699
for i in `seq 9600 9699`;
do
        echo "static (inside,outside) udp interface $i playstation3 $i netmask 255.255.255.255"
done

I then pasted the output into my pix. If you are having problems here are some references that might be useful are the cisco pix command ref and the pix nat guide.