On Sat, Apr 13, 2002 at 12:28:12AM +0200, Mikael Olsson wrote:
>
> Yes, I'm in a sarcastic mood. I get that way when I see
> uninformed assertions. You've been warned.
>
> Diederik Schouten wrote:
> >
> > Bridged firewalls do not need subnet based address assignment on
> > their interfaces, you can have 10 interfaces with technically
> > overlapping IP address ranges on all.
> >
> > When you have to add the firewall to an already existing network,
> > you do not need to reconfigure any other device on the network,
> > your addressing schemes and routing stays exactly the same, the
> > only downtime you will have is due to the fact that you have to
> > connect the cabels
>
> This is impossible with a routing firewall?
> Dzang, I must have only dreamed us doing that for all these years.
> [And all the other boxes doing that I don't remember right now]
>
> > Similar situations will require vast/intelligent routing on
> > a routed firewall
>
> Iface Destination
> ----- -----------
> eth0 10.0.0.0/8
> eth1 10.0.0.5-10.0.0.8
> eth2 10.0.1.0/24, -10.0.1.88
> vlan5 10.0.0.15, 10.0.0.18, 10.0.0.20-10.0.0.25
>
> Yeah, in our case, we needed to implement half an AI to get that
> to work. Took all of about an afternoon.
Seems like your routed firewall is not just routing isn't it?
Your devices on eth0 are able to reach the hosts on eth1 I suppose?
That makes it a combined routing/bridging virewall...
Can I ask which one you are using?
> > Link redundance without session loss is also extremely easy to
> > setup using a bridged firewall
>
> Hm I must also have been dreaming when I added those HA slaves
> with <1 second failover time. Using non-bridging firewalls.
> With less than five minutes of work per cluster (sans hardware
> install time, of course).
I wasn't talking about redundant firewall, I meant redundant
ports/data paths through your firewall.
> > It will not show up as a gateway anyware.
>
> Hm. Enable proxy arp on the internal interface for the entire
> default route. Problem solved -- it'll look like an L4 switch.
Proxy arp... is different from promiscuous mode.
But I guess you already know that ;)
> > Traceroutes won't show it is there etc.
>
> Blocking traceroute isn't exactly rocket science.
> A determined firewall aims at blocking _firewalking_, plus
> variations thereof, by default. Are you suggesting that
> this won't stop that measly traceroute?
I'm not talking about blocking a protocol.
When the firewall is not a hop, it doesn't show up.
> > Unless you know it's IP address already you will not be able
> > to find it.
>
> Nmap will tell me it is there in about 10 seconds. I betcha its
> signature sticks out like a sore thumb too.
I betcha it won't.
What ports would NMAP check to see if it's there?
How to decide what/where a device is when it does not respond to anything?
> > Putting multiple firewalls in series to create for example more
> > ports becomes very easy, although for example with the Lucent BRICK
> > this is not necesary since it supports VLAN tagging and with a VLAN
> > capable switch you can create virtually any number of "virtual"
> > firewalls you might need, and give them all their own ruleset.
> > No need for recabling and expensive upgrades
>
> Jeez. I was wrong about VLAN support in routing firewalls too.
I'm not saying the bridged firewall are the only ones that can support
it...
I'm not claiming these are only bridged firewall features.
> And only using VLANs must be a SUPERIOR way of adding more interfaces.
> Especially given the "VLANs and security" thread going on right now.
Sure... many ways to turn a VLAN capable switch into a nice HUB, but that
kidna show the lazyness of sys admins doesn't it?
So, VLAN security is a switch issue and not a firewall issue.
And still... where would the "intruder" need to be to break you VLAN
security? At least his trojan needs to be located on the same LAN...
How to protect a banks money when the fire has started within the safe?
> > a purpose build firewall does not depend on the operating system of
> > the router/platform it is running at, lowering the chance of being
> > penetrated due to bugs in code other than for the firewall
>
> Although I agree 100% with what you are saying here, I cannot
> for the life of me grasp how this constitutes a "pro" for a bridged
> firewall over a routing firewall.
Is not pro for bridged or routing, works for both :)
> In summary: you haven't convinced me in any way that a bridging
> firewall has a single security advantage (or even a management
> advantage) over a routing firewall.
Implementation wise, the bump in the cable way, is more easy than changing
the routing policy of an already existing network.
I'm not sure if your firewall is doing proxy arp, but I suppose so, I prefer
layer2 bridging over proxy arp any time.
I'll be able to find your firewalls MAC addres when I'm located on the same
LAN, you wont be able to find mine.
When looking for firealls, if I were a hacker I would first go for the
devices on the edge of a network, and that's where the routed firewalls
would be, the bridged ones won't be there, they might be, but that would
defeat the "invisibility".
More improtant than bridged vs routed is how secure the firewall really is.
That's all... I'm just as happy installing Netscreen, Cisco, Nokia or Lucent
devices, as long as it'll do the job I need it to do.
Greetings,
Diederik
> --
> Mikael Olsson, Clavister AB
> Storgatan 12, Box 393, SE-891 28 �RNSK�LDSVIK, Sweden
> Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05
> Fax: +46 (0)660 122 50 WWW: http://www.clavister.com
> _______________________________________________
> Firewalls mailing list
> [EMAIL PROTECTED]
> http://lists.gnac.net/mailman/listinfo/firewalls
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
