Bwhaha! Can someone tell me what I wrote to set this off? I can't! :)
Was it the "Tebrgwrf" that triggered "Dirty Words\Dr Holden"? :) > From: System Attendant <[EMAIL PROTECTED]> > To: 'Mikael Olsson' <[EMAIL PROTECTED]> > Subject: ScanMail Message: To Sender, sensitive content found and action taken. > Date: Mon, 15 Apr 2002 06:44:01 -0500 > X-Mailer: Internet Mail Service (5.5.2653.19) > > Trend SMEX Content Filter has detected sensitive content. > > Place = Diederik Schouten; Firewalls List; > Sender = Mikael Olsson > Subject = Re: Bridging vs. Routing Firewalls. > Delivery Time = April 15, 2002 (Monday) 06:44:00 > Policy = Dirty Words\Dr Holden > Action on this mail = Quarantine message > > Warning message from administrator: > Sender, Content filter has detected a sensitive e-mail. Mikael Olsson wrote: > > Diederik Schouten wrote: > > > > Still, why would my firewall respond to you? It only needs to > > respond to the management server's address. > > True. Also true of a routing firewall that has its management access > table applied on L3/4 rather than (or "in addition to") L7 only. > > > You can even select a management address that is not in the same > > network range as the routers/management network around it. > > Also true for (some, although not very many I suppose :P) routing > firewalls. > > > 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. > > All good and well. Although I must say that, in general, I think > people that design firewalls that can't do anything else than > the classical ext/int/dmz needs to have a wire brush applied to > select parts of their anatomy. (No, not necessarily the weenie home > gateways. They're usually so b0rken anyway so it doesn't matter ;)) > > > > 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? > > Nah, that's no fun. Strictly speaking, the LAN gets DOSed before > the firewall (about .01us before :)), so that doesn't count. > > I was more thinking along the lines of the firewall forgetting to > wipe any unused space up to the 60 bytes minimum (and hence possibly > leaking data from the aforementioned admin interface, although I'll > give you that that is an issue with any firewall with careless coders), > or going up in flames when someone sends it IP options with invalid > lengths or somesuch. (Come to think of it, I've only ever seen that > particular thing happen to proxy firewalls, but let's not start that > thread up again :)) > > > 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 $bridging_firewall gets confused by units proxy-arping the > wrong range, I definately see why you don't like proxy arp ;) > > Here's a point on flexibility: To my mind, it is fairly common > to do filtering on IP addresses. Now, how does this combine? > - Either, you need to write something very similar to a > routing table, to avoid spoofing issues. > - Or, you _always_ need to specify, per rule, interface/IP pairs, > which is essentially weaving the routing table into the ruleset, > with added complexity. > - OR, you don't give a flying fuck about filtering per IP or IP > spoofing, which I assume isn't the case for you :) > > So, where's the flexibility? > (No, I still don't get it :)) > > Tebrgwrf > /Mike -- 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
