Yes, I've tried this, but have run into some troubles. My ruleset is below,
and here's the setup. Box A is Windows XP behind the NAT with IP of
192.168.0.5 plugged into Hub A. Box B is the FreeBSD pf/NAT box, int_if is
192.168.0.1 plugged into Hub A, ext_if is 10.12.4.61 plugged into Hub B.
Box C is FreeBSD box running p0f and netcat with IP of 10.12.4.66 plugged
into Hub B.
So my test is to run netcat on Box C (nc -l -p 23), and try to telnet from
Box A to Box C. The synproxy rule below is the only one I've gotten to work
to do this. (I commented the NAT rule out to be sure it didn't interfere
with what I was trying to do.) Box A (Windows) seems to open a telnet
session, but nothing I type goes though to Box C, and vice versa.
(Everything I type does get though if I set up Box B as regular NAT, though)
Interesting to note, p0f on Box C shows that IP address 192.168.0.5 is
connecting to it, *not* 10.12.4.61.
I'm sure it's something I've done wrong. Can anyone explain?
Thanks!
Aaron
# Variables
ext_if="xl0"
int_if="fxp0"
internal_net="192.168.0.0/16"
#Options
set block-policy return
#Scrub rules
scrub all random-id reassemble tcp
#NAT or rdr rules
#nat on $ext_if from $internal_net to any -> ($ext_if)
# Filtering
block log all
#Allow permitted icmp
pass in log inet proto icmp all icmp-type echoreq keep state label "$nr"
#Allow inbound on int_if for NAT
#pass in log on $int_if from $int_if:network to any keep state label "$nr"
#Allow all outbound
pass out log on $ext_if proto tcp from any to any modulate state flags S/SA
label "$nr"
pass out log on $ext_if proto { udp, icmp } from any to any keep state label
"$nr"
#Synproxy test
pass in log on $int_if proto tcp from any to any port 23 synproxy state
flags S/SA label "synproxy"
> > Is there a way with pf to "wash" these ambiguities (window size, syn
packet
> > size, etc) away so that all outgoing TCP packets look the same? Maybe
even
> > set them to user-defined variables, as we already can with 'max-mss' and
> > 'min-ttl'?
>
> Use the syn-proxy. It crafts all of the SYN's by hand. It is still
> possible to fingerprint based on things like the retransmission timers
> but that is much harder and they'd be better off looking at HTTP
> User-Agent discrepancies.
>
> .mike
