password-less ssh login to JunOS

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!

Cisco ASA Firewalls and IP Ranges in ACLS

I’ve google’d and I cannot find a way of creating a firewall range style object in an ASA, you know the kind of thing whereby you want to allow IP addresses 192.168.1.10 thru 192.168.1.20 in an ACL.

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!

Continue reading

Cisco ASA – First steps to a Check Point Style Policy

I’ve just spotted this in the Cisco ASA 8.3 release notes

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!

Thoughts on Firewalling

Firewalls will always be a key ingredient to network security, but not all firewalls are equal. Recently I’ve been forced into documenting how I decide & think about firewall rules…

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 :-)

Cisco IOS Zone Based Firewall Example

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 :cool:

Checkpoint Nokia, How to enable SSH thru the default filter.

I had lost this bookmark, saved here so I don’t loose it again :)

  • 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!

Strange ASA ARP Replying Behavior

I’ve been implementing a few Cisco ASA’s recently, and I blogged about this strange behavior; well I came across another one yesterday.

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.
:cool:

Cisco ASA and 7905 IP Phone Weirdness

I came accross something odd the other day, I had some Cisco IP Phones on a DMZ interface and the Call Manager was behind the inside interface. If you made a call from a 7940 to a 7940 everything worked fine, if you made a call from a 7905 to a 7940 it failled!

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!

Backup Interface on Cisco ASA Firewall

I tweeted a little while ago about Nokia recently supporting interface failover within IPSO, well it looks like Cisco’s ASA Version 8 software can do it now too!

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

Cisco Pix Firewall in front of a Playstation 3.

If you saw this tweet, you’ll see that a little while ago I had some fun with Playstation 3 online gaming; it’s probably my own fault because I’m possibly the only person with a version 6 Cisco Pix Firewall at home in front of their playstation.

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.