> First out, I must say I am impressed that you didn't just
> flame me right back, considering my mood at the time :)
I guess everybody has been there.
Can't say I don't love to flame people, but hey, we're all professionals ;)
> > 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?
>
> Definately.
>
> > That makes it a combined routing/bridging virewall...
>
> No, it makes it a proxy-ARPing firewall.
Ok, got me there... proxy-ARP ouch!
> > Can I ask which one you are using?
>
> Ours? :)
> <Ouch damnit, I did it again, didn't I? Just flame me, mkay?>
Sorry, hadn't checked you mail address...
Never seen it before, added to favorites ;)
> > [on traceroute]
> > I'm not talking about blocking a protocol.
> > When the firewall is not a hop, it doesn't show up.
>
> True, but you usually want to block all inbound traceroutes
> (firewalks) through a firewall?
> (Also see stuff about local firewall vulnerabilities below.)
Yeps... I agree, I do block traceroute everywhere, others might not agree.
> > > 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?
>
> All, if I told it to :)
Still, why would my firewall respond to you? It only needs to respond to
teh management server's address.
> > How to decide what/where a device is when it does not
> > respond to anything?
>
> It doesn't respond to ARPs for its management IP? *boggle* :)
>
> (Yes, I'm assuming management IP living on connected networks.
> If not, I can counter with routing firewalls having a separate
> management interface.)
Technically speaking it does not have to.
You can even select a management address that is not in the same network range
as the routers/management network around it.
As long as the traffic passes through the device it can capture it and use it.
The router on the other side that should normally be the default gateway will
respond to the arp, that is bridged by the firewall, traffic starts flowing and
will just never leave the firewall.
Bridged firewalls can have a management interface to, for example with the BRICK
you can use any of the interfaces for whatever you want. No set DMZ etc.
> > [on VLANs]
> > 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...
>
> I was sort of thinking of a trunk between the firewall out to
> a switch which has hard-coded VLAN tagging/untagging per port,
> which, to my mind, is the most common use for VLANs in a
> firewalled environment. On the (erronous?) assumption that
> your VLANs will be enough to separate different security
> zones. But this belongs in the "VLANs and security" thread :)
Let's leave it in the VLAN and security thread...
> > I'm not sure if your firewall is doing proxy arp, but I suppose
> > so, I prefer layer2 bridging over proxy arp any time.
>
> Why? (Sans the "I can see your MAC address" argument. See below)
No further comment :)
> > More improtant than bridged vs routed is how secure the firewall really is.
>
> I agree.
>
> The added obscurity of a bridged firewall _MAY_ add a tiny bit
> of security if the firewall itself is susceptible to attack.
> (Read: built on top of general-purpose OS, or sucks in general)
>
> But considering the case of a well-built routing firewall, where
> "access to the firewall itself" translates roughly to
> if destip==local_mgmtip
> if is_allowed_manager_srciface(srciface)
> if is_allowed_manager_ip(srcip)
> pass_to_mgmt_subroutines;
> at some point well past the ruleset lookup, I really don't see
> where the difference is.
I got to completely agree with that, I'm still waiting for the proxy/promiscuous
issue though...
> Here's something for you to chew on: If one can't trust the
> firewall's packet processing, isn't it possible to argue that
> bridged firewalls are even WORSE off than routing ones, given
> that they pick up every single packet on the LAN? I don't even
> have to _know_ where the firewall is in order to fire at it! :)
You can fire at will, but what are you trying to achieve?
fill a 100Mbit pipe, and basicly DOS the uplink?
You can do that with any device.
DOS a firewall? As you described, the way a firewall figures out if supposedly
management traffic is realy management traffic will take care of that.
Your management processes and filtering/packet forwarding processes are separated
so even if you block the management link, traffic will continue anyway.
And of course, that is the same for both routing and bridged mode.
If you cannot trust the packet handling, ehm... they pickup the packets and then
what? push it out on the wrong interface? copy packets? sure, depending on the
environment that would be, ehm... unfortunate :)
But you still need a device responding to the ARP's on the "wrong" interface
to get the traffic to leave the firewall, and that is very unlikely.
Except maybe when you have something proxy-arping for the wrong range? ;)
If all fails... all fails.
What if a routed firewall starts making the wrong routing decisions...
But since that is the core of a bridged firewall, I'd suspect it's also the most
controlled... bug stested, etc.
Greetings,
Diederik
> /Mike, looking to spark some new debate after having had Paul
> run rough-shod over him
>
> --
> 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
