> > I'm not talking about blocking a protocol. > > When the firewall is not a hop, it doesn't show up. > > s/doesn't show up/sometimes doesn't show up/
s/sometimes doesn't show up/most often doesn't show up/ remember, only for management traffic. If that is on a management interface, on a separate network it will NOT show up unless the intruder is already active on your management LAN. If you use remote management depending if it has been setup as pass-through management or strictly routed, it shows up from time to time in routed mode only. > > 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? > > If it modifies the packets in any way (see ISN discussion on proxy vs. > stateful thread), or behaves differently than a host behind it that's > reachable, then it's possible that it's detectable. Perhaps even with > NMAP's OS guess feature. If it simply drops or accepts packets, then it's > more difficult to detect, but less protective. Why is a device that simply drops or accepts packet les protective? Don't tell me you are happy with a firewall creating ICMP replies for all connections that are not allowed through? > > 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... > > These days that's a trivial bar for a targeted attack, and that's without > even looking at Code Red, or Nimda[1]. Sure... but with a smart trojan, you'd realy need to find the trojan and wipe it, or block all services on you firewall. in and outgoing. Trojan control can be incorporated in any protocol, they can probe the firewall from the inside without giving away which host is realy infected. Based on the outcome modular trojans will either pulldown or get updates pushed from the controller, and then what are you going to do? Sure, we can never say the internal lan poses no threat to the firewall, and the the strength of your security is completely depending on the admins enforcing/designing the policy (not just the firewall rulesets). > > How to protect a banks money when the fire has started within the safe? > > FM-200 suppression system in the safe, if banks kept more than trivial > ammounts of money in safes anymore. Exactly my point. Next to a firewall you need intrusion detection etc. etc. > > I'm not sure if your firewall is doing proxy arp, but I suppose so, I prefer > > layer2 bridging over proxy arp any time. > > A layer 2 bridge has to look at a lot more packets (all of them) than a > proxy ARPing firewall. This is true depending on the implementation. You can still tell a bridged firewall what IP addresses it should pass the ARP's for. There is no need to just accept all packets and pass them through you rulesets on all interfaces. The BRICK will not just accept all packets and copy them in its packet processing process unless sombody sticks to using wildcards in the config :) > You have to expose the MAC address of anything beyond the firewall, that's > sometimes a worse evil, especially if there are several things in the > network immediately on the other side of the firewall. Don't see why you should not, the MAC is needed for communicating anyway, if there are devices that should not be reachable from the outside, then the ARP's do not need to be bridged unless the session is established from the inside. But again, that means the intruder is on you local LAN. What does he want to do with the MAC info? confuse a switch? Worse case the firewall will notice this and ignore the spoofed MAC. > If you wanted to add some complexity, you could always have the proxy ARPing > firewall ARP with the "real" MAC address from the other side and listen on > that MAC on the near interface. I'm not sure the gain is worth the > additional code, but it's not precluded by architectural impossibility. If the device where you are proxy-arping for is down, your firewall might still proxy arp for it, a bridge won't since the ARP is generated by the host itself. > > 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". > > Depends on your target. These days people pass enough bad stuff that > going after a "protected" client is probably the best endgame in most > situations (unless your target is a DB system on a service network to one > side of the firewall.) Indeed. Hence me reasoning that just a firewall is not enough. Without active monitoring you'll only know your security net has been penetrated months after teh incident happened. Diederik. _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
