freebsd-pf Digest, Vol 263, Issue 3
Nico De Dobbeleer
nico at elico-it.be
Wed Oct 7 20:17:22 UTC 2009
Hey,
Ok It's true, I need to provide you all with more info. This is the situation:
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 firewall must have a public ip-address hence the setup with the bridge because NAT is out of the question.
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.
@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 into the 62.213.196.160/28 range once I put it in production.
Hereby my config file I'm still testing so here and there you will see uncommented options):
____________________________________________________________________________
#######################
# Tables
#######################
table <all_public_ips> { 10.0.0.0/8, 62.213.196.160/28 }
table <customer_ips> { 10.0.0.50, 62.213.196.174, 62.213.196.173, 62.213.196.172, 62.213.196.171, 62.213.196.170 }
table <admin_ips> { 10.0.0.200, 62.213.196.166, 62.213.196.167, 62.213.196.168, 62.213.196.169 }
table <power_ips> { 62.213.196.164, 62.213.196.165 }
############################################################################
# Normalization rules:
############################################################################
#set block-policy drop
set fingerprints "/etc/pf.os"
set block-policy return
# scrub incoming packets
scrub in on { $ext_if, $int_if } all fragment reassemble min-ttl 15 max-mss 1400
scrub in on { $ext_if, $int_if } all no-df
scrub on { $ext_if, $int_if } all reassemble tcp
# Don't filter on the loopback interface
set skip on $loop_if
# this should block OS fingerprints??
block in log quick proto tcp flags FUP/WEUAPRSF
block in log quick proto tcp flags WEUAPRSF/WEUAPRSF
block in log quick proto tcp flags SRAFU/WEUAPRSF
block in log quick proto tcp flags /WEUAPRSF
block in log quick proto tcp flags SR/SR
block in log quick proto tcp flags SF/SF
block drop in on em0 all
block drop out on em0 all
block drop in on em1 all
block drop out on em1 all
block drop in on rl0 all
block drop out on rl0 all
# thwart nmap scans
block in log quick on { $ext_if, $int_if, $mng_if } proto tcp all flags FUP/FUP
block out log quick on { $ext_if, $int_if, $mng_if } proto tcp all flags FUP/FUP
############################################################################
# Filter rules:
############################################################################
# Allow public services to customers IP
pass in quick on { $ext_if, $int_if } inet proto { tcp, udp } from any to <customer_ips> port $public_services
pass out quick on { $ext_if, $int_if } inet proto { tcp, udp } from any to <customer_ips> port $public_services
# Allow admin services to admin servers
pass in quick on { $ext_if, $int_if, $mng_if } inet proto tcp from any to <admin_ips> port $admin_services
pass out quick on { $ext_if, $int_if, $mng_if } inet proto tcp from any to <admin_ips> port $admin_services
# Allow access to powerboots
pass in quick on { $ext_if, $int_if } inet proto tcp from any to <power_ips> port $power_services
pass out quick on { $ext_if, $int_if } inet proto tcp from any to <power_ips> port $power_services
____________________________________________________________________________________________
I hope you have more info now?
Nico
----- Oorspronkelijk bericht -----
Van: "Simon Haller" <simon.haller at gmx.net>
Aan: "Nico De Dobbeleer" <nico at elico-it.be>, "文鳥" <bunchou at googlemail.com>
Cc: freebsd-pf at freebsd.org
Verzonden: Woensdag 7 oktober 2009 20:35:58
Onderwerp: Re: freebsd-pf Digest, Vol 263, Issue 3
just to add my two cents (some of it already mentioned):
the default nmap-scan, depending on how initial tcp-handshake (SYN packet)
with a particular port is carried out, displays
1.) "open" if a TCP SYN-packet is answered by a TCP SYN/ACK packet.
2.) "closed" if a TCP SYN-packet is answered by TCP RST packet.
3.) "filtered" if either no response is received (after retransmission of
the TCP SYN-packet) or it is answered by a ICMP type 3 packet (unreachable
error).
so actually there is a difference between "closed" and "filtered" ports...
*) "stealth-mode" a.k.a. "block-policy drop;" will let the firewall ignore
TCP SYN requests to open ports (the port will appear as "filtered"), while
*) "block-policy return;" will let the firewall return a TCP RST packet
(the port will appear as "closed"), if a "TCP SYN" packet is sent to a
blocked port.
the OS-detection of nmap is based on different response tests using
different types of packets to different ports (by default nmap scans the
1000 most common ports):
all the above mentioned packets "TCP SYN/ACK", "TCP RST" and "ICMP type 3"
give away information about the operating system.
also responses to UDP packets and ICMP request give away information about
the OS.
without knowledge of the firewall and network setup it is not possible to
say if it is possible and how to prevent the os detecting in the mentioned
case...
BR, simon haller
Am 07.10.2009, 17:48 Uhr, schrieb 文鳥 <bunchou at googlemail.com>:
>> Already many thanks for the info. I'v added already the "set
>> block-policy drop". I'v done an nmap and it's apparently able to find
>> out the setting below of my pf FW:
>>
>> MAC Address: 00:0E:2E:xx:xx:xx (Edimax Technology Co.)
>> Warning: OSScan results may be unreliable because we could not find
>> at least 1 open and 1 closed port Device type: general purpose
>> Running: FreeBSD 7.X
>> OS details: FreeBSD 7.1-PRERELEASE
>> Uptime guess: 0.000 days (since Wed Oct 07 16:02:00 2009)
>> Network Distance: 1 hop
>> TCP Sequence Prediction: Difficulty=260 (Good luck!)
>> IP ID Sequence Generation: Incremental
>> Service Info: OS: FreeBSD
>>
>>
>> Is there a way to block this info?
>
> Possible, but may be disruptive to your networking, depending on
> your network environment and what you block. As I know nothing about
> your setup or pf.conf, and thus cannot tell you anything more specific,
> I will just explain what you can do to investigate and reduce the flow
> of data, but from there on you're on your own.
>
> First of all, check what ICMP messages come through and consider
> blocking these (take a look at the relevant RFCs first, though).
>
> Secondly, you can capture the data that nmap sends and the other
> end's replies using tcpdump, wireshark, whatever. Of interest are the
> responses you actually get from the scanned host. Find out what
> protocols those responses belong to (google, etc.), decide
> whether it is worthwile to block that data and, finally, check 'man
> pf.conf' to see how to do just that.
>
> BTW: please limit the amount of text you quote.
> _______________________________________________
> freebsd-pf at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
More information about the freebsd-pf
mailing list