Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Oct 2009 22:17:15 +0200 (CEST)
From:      Nico De Dobbeleer <nico@elico-it.be>
To:        Simon Haller <simon.haller@gmx.net>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: freebsd-pf Digest, Vol 263, Issue 3
Message-ID:  <32213363.66501254946635517.JavaMail.root@zimbra-store>
In-Reply-To: <25442608.66481254946506174.JavaMail.root@zimbra-store>

next in thread | previous in thread | raw e-mail | index | archive | help
Hey,=20

Ok It's true, I need to provide you all with more info. This is the situati=
on:=20
My firewall has 3 networkcards 2 off them are in bridge (em0 and em1), 1 is=
 used for administration (rl0). The goal is to use the bridge to filter all=
 traffic to my servers behind the firewall. BUT the server behind the firew=
all must have a public ip-address hence the setup with the bridge because N=
AT is out of the question.=20

The range of my severs is 62.213.196.60/28. In the config file you will see=
 10.0.0.0/8 addresses but that's just for testing purposes at home.=20

@home there is a 10.0.0.50 ubuntu connected to a router and the router into=
 the bridge of the FW. The admin NC has 10.0.0.200. This will all change in=
to the 62.213.196.160/28 range once I put it in production.=20

Hereby my config file I'm still testing so here and there you will see unco=
mmented options):=20

___________________________________________________________________________=
_=20
#######################=20
# Tables=20
#######################=20

table <all_public_ips> { 10.0.0.0/8, 62.213.196.160/28 }=20
table <customer_ips> { 10.0.0.50, 62.213.196.174, 62.213.196.173, 62.213.19=
6.172, 62.213.196.171, 62.213.196.170 }=20
table <admin_ips> { 10.0.0.200, 62.213.196.166, 62.213.196.167, 62.213.196.=
168, 62.213.196.169 }=20
table <power_ips> { 62.213.196.164, 62.213.196.165 }=20

###########################################################################=
#=20
# Normalization rules:=20
###########################################################################=
#=20
#set block-policy drop=20
set fingerprints "/etc/pf.os"=20
set block-policy return=20

# scrub incoming packets=20

scrub in on { $ext_if, $int_if } all fragment reassemble min-ttl 15 max-mss=
 1400=20
scrub in on { $ext_if, $int_if } all no-df=20
scrub on { $ext_if, $int_if } all reassemble tcp=20

# Don't filter on the loopback interface=20
set skip on $loop_if=20

# this should block OS fingerprints??=20
block in log quick proto tcp flags FUP/WEUAPRSF=20
block in log quick proto tcp flags WEUAPRSF/WEUAPRSF=20
block in log quick proto tcp flags SRAFU/WEUAPRSF=20
block in log quick proto tcp flags /WEUAPRSF=20
block in log quick proto tcp flags SR/SR=20
block in log quick proto tcp flags SF/SF=20

block drop in on em0 all=20
block drop out on em0 all=20
block drop in on em1 all=20
block drop out on em1 all=20
block drop in on rl0 all=20
block drop out on rl0 all=20


# thwart nmap scans=20
block in log quick on { $ext_if, $int_if, $mng_if } proto tcp all flags FUP=
/FUP=20
block out log quick on { $ext_if, $int_if, $mng_if } proto tcp all flags FU=
P/FUP=20



###########################################################################=
#=20
# Filter rules:=20
###########################################################################=
#=20

# Allow public services to customers IP=20
pass in quick on { $ext_if, $int_if } inet proto { tcp, udp } from any to <=
customer_ips> port $public_services=20
pass out quick on { $ext_if, $int_if } inet proto { tcp, udp } from any to =
<customer_ips> port $public_services=20


# Allow admin services to admin servers=20
pass in quick on { $ext_if, $int_if, $mng_if } inet proto tcp from any to <=
admin_ips> port $admin_services=20
pass out quick on { $ext_if, $int_if, $mng_if } inet proto tcp from any to =
<admin_ips> port $admin_services=20

# Allow access to powerboots=20
pass in quick on { $ext_if, $int_if } inet proto tcp from any to <power_ips=
> port $power_services=20
pass out quick on { $ext_if, $int_if } inet proto tcp from any to <power_ip=
s> port $power_services=20
___________________________________________________________________________=
_________________=20

I hope you have more info now?=20

Nico=20

----- Oorspronkelijk bericht -----=20
Van: "Simon Haller" <simon.haller@gmx.net>=20
Aan: "Nico De Dobbeleer" <nico@elico-it.be>, "=E6=96=87=E9=B3=A5" <bunchou@=
googlemail.com>=20
Cc: freebsd-pf@freebsd.org=20
Verzonden: Woensdag 7 oktober 2009 20:35:58=20
Onderwerp: Re: freebsd-pf Digest, Vol 263, Issue 3=20

just to add my two cents (some of it already mentioned):=20

the default nmap-scan, depending on how initial tcp-handshake (SYN packet)=
=20
with a particular port is carried out, displays=20
1.) "open" if a TCP SYN-packet is answered by a TCP SYN/ACK packet.=20
2.) "closed" if a TCP SYN-packet is answered by TCP RST packet.=20
3.) "filtered" if either no response is received (after retransmission of=
=20
the TCP SYN-packet) or it is answered by a ICMP type 3 packet (unreachable=
=20
error).=20

so actually there is a difference between "closed" and "filtered" ports...=
=20

*) "stealth-mode" a.k.a. "block-policy drop;" will let the firewall ignore=
=20
TCP SYN requests to open ports (the port will appear as "filtered"), while=
=20
*) "block-policy return;" will let the firewall return a TCP RST packet=20
(the port will appear as "closed"), if a "TCP SYN" packet is sent to a=20
blocked port.=20

the OS-detection of nmap is based on different response tests using=20
different types of packets to different ports (by default nmap scans the=20
1000 most common ports):=20
all the above mentioned packets "TCP SYN/ACK", "TCP RST" and "ICMP type 3"=
=20
give away information about the operating system.=20
also responses to UDP packets and ICMP request give away information about=
=20
the OS.=20
without knowledge of the firewall and network setup it is not possible to=
=20
say if it is possible and how to prevent the os detecting in the mentioned=
=20
case...=20

BR, simon haller=20


Am 07.10.2009, 17:48 Uhr, schrieb =E6=96=87=E9=B3=A5 <bunchou@googlemail.co=
m>:=20

>> Already many thanks for the info. I'v added already the "set=20
>> block-policy drop". I'v done an nmap and it's apparently able to find=20
>> out the setting below of my pf FW:=20
>>=20
>> MAC Address: 00:0E:2E:xx:xx:xx (Edimax Technology Co.)=20
>> Warning: OSScan results may be unreliable because we could not find=20
>> at least 1 open and 1 closed port Device type: general purpose=20
>> Running: FreeBSD 7.X=20
>> OS details: FreeBSD 7.1-PRERELEASE=20
>> Uptime guess: 0.000 days (since Wed Oct 07 16:02:00 2009)=20
>> Network Distance: 1 hop=20
>> TCP Sequence Prediction: Difficulty=3D260 (Good luck!)=20
>> IP ID Sequence Generation: Incremental=20
>> Service Info: OS: FreeBSD=20
>>=20
>>=20
>> Is there a way to block this info?=20
>=20
> Possible, but may be disruptive to your networking, depending on=20
> your network environment and what you block. As I know nothing about=20
> your setup or pf.conf, and thus cannot tell you anything more specific,=
=20
> I will just explain what you can do to investigate and reduce the flow=20
> of data, but from there on you're on your own.=20
>=20
> First of all, check what ICMP messages come through and consider=20
> blocking these (take a look at the relevant RFCs first, though).=20
>=20
> Secondly, you can capture the data that nmap sends and the other=20
> end's replies using tcpdump, wireshark, whatever. Of interest are the=20
> responses you actually get from the scanned host. Find out what=20
> protocols those responses belong to (google, etc.), decide=20
> whether it is worthwile to block that data and, finally, check 'man=20
> pf.conf' to see how to do just that.=20
>=20
> BTW: please limit the amount of text you quote.=20
> _______________________________________________=20
> freebsd-pf@freebsd.org mailing list=20
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf=20
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"=20


--=20
Erstellt mit Operas revolution=C3=A4rem E-Mail-Modul: http://www.opera.com/=
mail/=20



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32213363.66501254946635517.JavaMail.root>