freebsd-pf Digest, Vol 263, Issue 3

[Simon Haller]

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/