RE: Dynamic routing on a firewall

["Dawes, Rogan (ZA - Johannesburg)" <rdawes () deloitte co za>]

Hi all,

Thanks for the responses. This was my initial thought as well - my flesh
also crawled ;-)

The reason I asked is that I am thinking of writing a tool to assist in
analysing Pix firewall rules. One thing that can be tricky from an audit
perspective is working out where a destination IP address actually is, and
which interface it would be routed through.

In a complex rulebase, with numerous access-lists, it would be handy to be
able to say "this IP address would be routed out through this router, which
is on this interface", rather than having to work it out manually each time.
I have done a quick hack to extract the static routes, and add those to the
networks defined in the interface lines, in order to establish how to get to
each network, but I just wanted to get an idea of how likely it was that
this would be broadly usable.

Obviously, if the firewall is using dynamic routing, there would be no
routes to check, and often no way of knowing (without a network diagram
obtained separately) exactly where a particular IP address resides.

What I am kind of visualising is, given a stripped config like this:

nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 DMZ1 security10
ip address outside xxx.xxx.xxx.1 255.255.255.240
ip address inside 10.1.1.1 255.255.255.255
ip address DMZ1 192.168.1.1 255.255.255.0
access-list inside permit tcp 10.0.0.0 255.0.0.0 host 192.168.2.7 port 22
access-group out in interface outside
access-group in in interface inside
access-group DMZ1 in interface DMZ1
route outside 0.0.0.0 0.0.0.0 xxx.xxx.xxx.2 1
route inside 10.3.0.0 255.255.0.0 10.1.1.254 1
route DMZ1 192.168.2.0 255.255.255.0 192.168.1.254 1

Being able to say:

(inside => DMZ1) permit tcp 10.0.0.0 255.0.0.0 host 192.168.2.7 port 22

Obviously, if the destination is covered by more than one route, it becomes
difficult. Then one might show both possibilities (harder), or show ( inside
=> ?? ), and let the human check on that specific rule.

This is obviously most relevant from an external auditor perspective, where
one is not so familiar with the networks being reviewed.

This tool will also include highlighting basic good practice, such as "no
rules allow large ranges of services", "no rules allow large networks",
"telnet is disabled", "ssh is limited to few management stations",
"access-lists actually have been applied to an interface", "snmp does not
use 'public'", "snmp polling is restricted to certain stations", "syslog is
enabled", etc. 

If anyone wants to tell me their favourite foulups seen on a Pix, I will
attempt to include checks for those issues in the tool. Obviously I am
mainly interested in things that can be checked for by a tool.

The intention is to release it under an open source license when it becomes
usable.

Thoughts? Suggestions?

Rogan

> -----Original Message-----
> From: Ben Nagy [mailto:ben () iagu net] 
> Sent: 28 November 2003 05:47 PM
> To: 'Dawes, Rogan (ZA - Johannesburg)'; 
> firewall-wizards () honor icsalabs com
> Subject: RE: [fw-wiz] Dynamic routing on a firewall
>
>
> My quick 0.02.
>
> It's a bad idea. 
>
> The PIX is a terrible router, for a start, but even so the 
> idea makes my
> flesh creep. For your scenario, how about using statics with different
> metrics, or an external load balancing solution (which is the 
> 'standard' way
> of handling the problem on the Internet interface).
>
> If you do decide to do it, then you can use route filtering 
> per interface to
> restrict what networks you will allow updates for - this is 
> how it's done in
> WANs and the Internet (or how it _should_ be done ;)
>
> Cheers,
>
> ben 
>
> > -----Original Message-----
> > From: firewall-wizards-admin () honor icsalabs com 
> > [mailto:firewall-wizards-admin () honor icsalabs com] On Behalf 
> > Of Dawes, Rogan (ZA - Johannesburg)
> > Sent: Friday, November 28, 2003 10:39 AM
> > To: firewall-wizards () honor icsalabs com
> > Subject: [fw-wiz] Dynamic routing on a firewall
> >
> > Hi,
> >
> > I just wanted to pick the list's brain with regards to 
> > dynamic routing on a firewall.
> >
> > Is it a good idea to allow a firewall to participate in 
> > dynamic routing? My first thoughts are that it sounds like a 
> > really dangerous thing  - you certainly don't want to have 
> > routes changing so that a DMZ moves from one interface to a 
> > different one, for instance.
> >
> > But if the routing can be controlled so that traffic always 
> > goes through the right interface (but possibly to a different 
> > upstream router), that should be OK, I would think.
> >
> > What mechanisms do the various firewalls (mostly interested 
> > in Pix and FW-1) have to sanity-check routing updates that 
> > they receive?
> >
> > A (simplistic) scenario that could illustrate my concerns:
> >
> > You have a firewall controlling access to third parties 
> > (competitors) which provide services to your company. Each 
> > party is in their own DMZ. You have dynamic routing enabled 
> > on the firewall, since there are two redundant routers for 
> > each party in each parties DMZ, and you need to be able to 
> > fail over from one to the other.
> >
> > Party A sends a routing update to say that party B is now 
> > reachable via Party A's networks. Any packets that you try to 
> > send to party B end up going to Party A, where they can be 
> > captured, etc.
> >
> > Leaving out the question of how A gets the packets to B 
> > eventually, to complete the connection, is this a realistic 
> > scenario? How can one protect against something like this, 
> > using the abovementioned firewalls, if one still chooses to 
> > use dynamic routing?
> >
> > Rogan
> > --
> > "Using encryption on the Internet is the equivalent of 
> > arranging an armored car to deliver credit card information 
> > from someone living in a cardboard box to someone living on a 
> > park bench."
> >   - Gene Spafford
> > --
> > Deloitte & Touche Security Services Group
> > Tel: +27(11)806-6216     Fax: +27(11)806-5202     Cell: 
> > +27(82)784-9498
> > -- 
> >
> > Important Notice: This email is subject to important 
> > restrictions, qualifications and disclaimers ("the 
> > Disclaimer") that must be accessed and read by clicking here 
> > or by copying and pasting the following address into your 
> > Internet browser's address bar: 
> > http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed 
> > to form part of the content of this email in terms of Section 
> > 11 of the Electronic Communications and Transactions Act, 25 
> > of 2002. If you cannot access the Disclaimer, please obtain a 
> > copy thereof from us by sending an email to 
> > ClientServiceCentre () Deloitte co za.
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards () honor icsalabs com
> > http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

Important Notice: This email is subject to important restrictions, qualifications and disclaimers ("the Disclaimer") 
that must be accessed and read by clicking here or by copying and pasting the following address into your Internet 
browser's address bar: http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed to form part of the content of this 
email in terms of Section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you cannot access 
the Disclaimer, please obtain a copy thereof from us by sending an email to ClientServiceCentre () Deloitte co za.
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards