On 9/10/05, Randy B <[EMAIL PROTECTED]> wrote:
Bill Marquette wrote:
> I have nearly zero idea what you're asking for, but I suspect you want
> something like PF's dup-to functionality.
>
>      /dup-to/
>            The /dup-to/ option creates a duplicate of the packet and routes it
>            like /route-to/.  The original packet gets routed as it normally
>            would.
>
>
> Amy I close?

Well, I'm not sure what *Amy* has to do with anything, but...

Typo :)
 

That sounds close, but the key would be mangling both the source &
destination fields AND keeping state.  Then for just cream on the top,
go invisible by incrementing one's TTL.

Example:

ICMP ping comes in from 192.168.0.1, a scanning host.  The firewall,
masquerading host B at 192.168.0.2, rewrites the destination as
192.168.0.3 (host A) and the source as itself (192.168.0.2) and marks a
state.  When (if) a return packet comes from 192.168.0.3, it matches the
state, source gets mangled again to 192.168.0.2, destination as
192.168.0.1, and is forwarded on to 192.168.0.1.  That way, all the
specifics of host B that can be determined from stateless network scans
would for all intents and purposes look precisely like host A.


Yeah, that can be done with NAT and RDR.


On top of that, statefully incrementing TTL by 1 each time a packet is
masqueraded would prevent even the most scrutinizing scan from
discerning that host B exists - the firewall IP would just look like
another NIC on host A.  Host A, of course, would have to be complicit -
if the scan came from host A, all would be revealed and lost.


That can't currently be done with PF.  You can enforce a minimum TTL, but not set it to not decrement.  Besides, not decrementing the TTL probably violates some RFC.

 --Bill

Reply via email to