I have a question regarding this very subject. When I first used m0n0wall (yes, I know this is not m0n0wall, but just listen) I tested it with a bunch of those firewall testing sites, I passed all of them, but this one said that my firewall did a "counter-probe" or something that sounds similar. Basically it described it as even though the firewall was "stealthed" (it blocked all packets), it attempted to gain information on the intruder. The tester assumed it was some kind of tracerouter and suggested that it be turned off for added security. Since pfSense is based on m0n0wall, I was wondering if it had the same problem? I was also curious as to what the heck that tester was talking about. So, if this longwinded and vague description reminds you of something that you know of, please let me know. Thanks.
----- Original Message ----- From: "Chris Buechler" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, September 23, 2005 12:23 PM Subject: Re: [pfSense-discussion] block vs reject? > Matthew Lenz wrote: > > >Just had a situation where a backend job was hanging because it couldn't > >get to an ip. the tcp connect just kinda hung and this particular > >software module had a really long timeout set. Is there a reason why > >for example there is a global block in pfsense as opposed to a global > >reject (which seems to fail attempts immediately)? sorry I'm a fw > >noob :) > > > > > > block essentially leaves the firewall "invisible" on the Internet, so > that's the default. With block and no open ports and no permitted > traffic, your firewall's WAN IP looks no different from an unused IP on > the Internet, sometimes referred to as "stealth". Granted it's far from > fool proof, but that's the default stance any firewall should take, IMO. > > Reject sends an ICMP unreachable back to the requesting host, which > would let an attacker know that there is actually a host there. Also OS > fingerprinting can be done on how a machine rejects certain packets, so > that's another good reason to block vs. reject. It's all obscurity, but > obscurity when combined with other layers of protection is a good thing > (never rely on it for anything, but it's never bad to have). > > -cmb >
