blocking nmap scans

[Afra, Ziad (London)]

Hello all

I hope everyone is well. I`m looking at the various rules required to block
an nmap scan from other hosts to show my ports being open. I applied the
following rule but I am still able to scan using the latest version of nmap
on redhat9.

block in log quick on $ext_if inet proto tcp from any to any flags FUP/FUP
block in log quick on $ext_if inet proto tcp from any to any flags SF/SFRA
block in log quick on $ext_if inet proto tcp from any to any flags /SFRA


One other thing I would like to ask is ... when an nmap report is conducted
on some internal firewalled machines I receive a state of "filtered" on
them. What does this mean exactly and how can one apply it to one`s config?

Thanks

Ziad

[Tiago Pierezan Camargo]

Post by Afra, Ziad (London)
block in log quick on $ext_if inet proto tcp from any to any flags FUP/FUP
block in log quick on $ext_if inet proto tcp from any to any flags SF/SFRA
block in log quick on $ext_if inet proto tcp from any to any flags /SFRA

Those rules only block FIN, Xmas and NULL scans. TCP connect() and SYN scans work as usual.

[Afra, Ziad (London)]

So whats the syntax to block TCP connect() and SYN?

Thanks

Z

-----Original Message-----
From: Tiago Pierezan Camargo [mailto:***@matrix.com.br]
Sent: 17 December 2003 09:47
To: ***@benzedrine.cx
Subject: Re: blocking nmap scans

Post by Afra, Ziad (London)
block in log quick on $ext_if inet proto tcp from any to any flags FUP/FUP
block in log quick on $ext_if inet proto tcp from any to any flags SF/SFRA
block in log quick on $ext_if inet proto tcp from any to any flags /SFRA

Those rules only block FIN, Xmas and NULL scans. TCP connect() and
SYN scans work as usual.

[Dom De Vitto]

shutdown

:-)

Check the nmap documentation, then the pf.conf manual page.
You need to understand why what you are asking for isn't possible.
Also all the syntax is covered by "man pf.conf".

Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. [phone]
http://www.devitto.com mailto:***@devitto.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-----Original Message-----
From: owner-***@benzedrine.cx [mailto:owner-***@benzedrine.cx] On Behalf Of
Afra, Ziad (London)
Sent: Wednesday, December 17, 2003 12:32 PM
To: ***@benzedrine.cx
Subject: RE: blocking nmap scans

So whats the syntax to block TCP connect() and SYN?

Thanks

Z

-----Original Message-----
From: Tiago Pierezan Camargo [mailto:***@matrix.com.br]
Sent: 17 December 2003 09:47
To: ***@benzedrine.cx
Subject: Re: blocking nmap scans

Post by Afra, Ziad (London)
block in log quick on $ext_if inet proto tcp from any to any flags FUP/FUP
block in log quick on $ext_if inet proto tcp from any to any flags SF/SFRA
block in log quick on $ext_if inet proto tcp from any to any flags /SFRA

Those rules only block FIN, Xmas and NULL scans. TCP connect() and
SYN scans work as usual.

--
Tiago Pierezan Camargo <elessar at matrix.com.br>

(o_.' The boozy penguin says:
//\c{} "VI VI VI The editor of the beast."
V__)_

[Max Laier]

Post by Afra, Ziad (London)
So whats the syntax to block TCP connect() and SYN?

Okay, let's try to be a bit more polite ;)

If a service should be available to the internet, then you must not block a
(legal) TCP connect() to the port associated with this service, hence you can
not "block" a scanner using connect(). However, those scans will show up in
your logs. Additionally you can try to block portscanner by timeing, esp. the
new source tracking will assist you with that.

Post by Afra, Ziad (London)
Interesting that you say that given the fact that when I scan a linux redhat
machine running iptables it doesn't report any ports open (when there are
services running on ports < 1024).

No, iptables can not block portscanner and allow regular traffic at the same
time ...

And yes, building a firewall w/o (at least) basic knowledge of IP, TCP and
friends won't work - as long as you need something more then clicking "enable
firewall" in a fancy redhat or microsoft configuration tool, that is.

[Dom De Vitto]

Thanks Max, saved me some keystrokes.
I would say that for *host* Firewalling, like XP's builtin FW,
could be easily done with PF.

In fact writing such a tool is a pretty trivial, but very useful
idea....e.g.
- block outbound echo-reply, unreachable and some other icmp.
- block outbound TCP RST packets ('closed port')
- allow outbound everything else, keeping state.
- allow inbound everything else, keeping state.

(this sounds back-to-front, but I this means that active ftp, and
other dirty protocol work fine, but portscanning is sloooooooow).

Does anyone know is TCP RST rate limiting (like ICMP) is possible
with 'stock' OpenBSD?

Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. [phone]
http://www.devitto.com mailto:***@devitto.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-----Original Message-----
From: owner-***@benzedrine.cx [mailto:owner-***@benzedrine.cx] On Behalf Of
Max Laier
Sent: Wednesday, December 17, 2003 3:42 PM
To: Afra, Ziad (London)
Cc: ***@benzedrine.cx
Subject: Re: blocking nmap scans

Post by Afra, Ziad (London)
So whats the syntax to block TCP connect() and SYN?

Okay, let's try to be a bit more polite ;)

If a service should be available to the internet, then you must not block a
(legal) TCP connect() to the port associated with this service, hence you
can not "block" a scanner using connect(). However, those scans will show up
in your logs. Additionally you can try to block portscanner by timeing, esp.
the new source tracking will assist you with that.

Post by Afra, Ziad (London)
Interesting that you say that given the fact that when I scan a linux
redhat machine running iptables it doesn't report any ports open (when
there are services running on ports < 1024).

No, iptables can not block portscanner and allow regular traffic at the same
time ...

And yes, building a firewall w/o (at least) basic knowledge of IP, TCP and
friends won't work - as long as you need something more then clicking
"enable firewall" in a fancy redhat or microsoft configuration tool, that
is.

[Afra, Ziad (London)]

Hmm

Interesting that you say that given the fact that when I scan a linux redhat
machine running iptables it doesn't report any ports open (when there are
services running on ports < 1024).

-----Original Message-----
From: Dom De Vitto [mailto:***@DeVitto.com]
Sent: 17 December 2003 14:46
To: ***@benzedrine.cx
Subject: RE: blocking nmap scans

shutdown

:-)

Check the nmap documentation, then the pf.conf manual page.
You need to understand why what you are asking for isn't possible.
Also all the syntax is covered by "man pf.conf".

Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. [phone]
http://www.devitto.com mailto:***@devitto.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-----Original Message-----
From: owner-***@benzedrine.cx [mailto:owner-***@benzedrine.cx] On Behalf Of
Afra, Ziad (London)
Sent: Wednesday, December 17, 2003 12:32 PM
To: ***@benzedrine.cx
Subject: RE: blocking nmap scans

So whats the syntax to block TCP connect() and SYN?

Thanks

Z

-----Original Message-----
From: Tiago Pierezan Camargo [mailto:***@matrix.com.br]
Sent: 17 December 2003 09:47
To: ***@benzedrine.cx
Subject: Re: blocking nmap scans

Post by Afra, Ziad (London)
block in log quick on $ext_if inet proto tcp from any to any flags
FUP/FUP
block in log quick on $ext_if inet proto tcp from any to any flags
SF/SFRA
block in log quick on $ext_if inet proto tcp from any to any flags
/SFRA

Those rules only block FIN, Xmas and NULL scans. TCP connect() and
SYN scans work as usual.

--
Tiago Pierezan Camargo <elessar at matrix.com.br>

(o_.' The boozy penguin says:
//\c{} "VI VI VI The editor of the beast."
V__)_

[Roger Gregory]

Post by Afra, Ziad (London)
Interesting that you say that given the fact that when I scan a
linux redhat machine running iptables it doesn't report any ports
open (when there are services running on ports < 1024).

Not really. Chances are that machine has been configured to return a
proper response for a 'non-listening' port as opposed to dropping the
packet to the floor.

See man (5) pf.conf, specific the OPTIONS section, "set block-policy",
or assign a proper response in your specific ruleset instead of
dropping the packet to the floor..

NMAP happily shows such drops as 'filtered' as it's obvious a packet
filter is active.

Cheers-

-r