You can't avoid a syn scan - what do you think you are
talking about? Here, look. :->
syn scan: (nmap -sS)
<- syn ack
tcp connect full: (nmap -sT)
<- syn ack
notice that the first two packets exchanged DO NOT
CHANGE. You send an SYN to a port - if it is open
then you get a SYN-ACK. Your kernel mods can't change
this behavior or you lose TCP connectivity.
If you meant something else, then you made a typo
("..but it eliminates all of the TCP scans from
finding open ports except TCP connect..").
On Wed, 9 Feb 2000, Simple Nomad wrote:
Well, I think that if all networked systems used
state tables you would
eliminate almost everything. Unfortunately pretty
much all systems do not
use the built in state tables. This is actually one
of the first
modifications I make on a new system via kernel
patching -- so it really
only applies to open sourced operating systems --
but it eliminates all of
the TCP scans from finding open ports except TCP
connect, which can be
controlled any number of ways.
- Simple Nomad - No rest for the
- thegnome () nmrc org -
- thegnome () razor bindview com -
On Wed, 9 Feb 2000, Reinoud Koornstra wrote:
And..... are there any suggestions for this:
Assume i have a machine running ipf which deals
with the traffic from
Behind that machine is an entire netwerk using
Now some one uses nmap on me to see what is open
and what isnt.
Now, ipf notices a packet... (fyn scan) does
nothing with it but redirects
it to another machine on the network on which the
port is closed.
Then nmap will think the port on the firewalled
machine is closed while
nmap really got the results from another machine
without knowing it.
A friend of mine deals this way with this kind of
scans and fooling nmap
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.