[ILUG] port scanning.. continued.

[Smelly Pooh]

In reply to Paul Jakma's flatulent wordings, 
> On Tue, 14 Mar 2000, Smelly Pooh wrote:
> 
> > In reply to Breathnach, Proinnsias (Dublin)'s flatulent wordings, 
> > > Quick hint I picked up some time ago ... set ipfwadm to 'reject' as opposed
> > > to deny, that way the box doesn't 'look' like a *nix box, but a Win'9x one
> > > ... (Win'9x can't deny connections, rather it rejects them with no "reason",
> > > "deny" sends back a message saying "You're not allowed in", reject just
> > > looks like a black-hole ... it might help ...
> > 
> 
> > Or at a
> > lower level, reject should send a tcp reset packet back which is normal if
> > there's no server running on that port.
> 
> that'd be an IP ICMP reject packet then, wouldn't it? TCP has no
> business getting involved in the details of IP.

Well I was referring to a port, icmp messages are used with UDP ports, TCP
resets are used with TCP ports, but there's no such thing as a strictly IP
port.

> AFAIK TCP RST is for resetting /TCP/ connections when needs be (OS
> confused, multiple packets.. etc) Of course there might be some dodgy
> firewalls that reply with TCP RST's, but that would be very dodgy..
> 
> (you could RST a SYN - but that's not a reject - that's an error
> condition).

It's not an error condition, if you make a TCP connection to a port and
there's nothing listening there, then the OS replies with a RST (you hardly
think a non-listening process does that do you?)

> surely you mean ICMP reject rather than TCP RST? 

Yet again I was talking about TCP connections

> > unless it can ping it first, so incoming ICMP requests might be worth
> > dropping aswell.
> 
> some part scanners are even cleverer. Rather sending an icmp echo
> request or trying to establish a tcp connection, both of which are
> easily picked up Sentry/firewall type stuff, they will instead
> "half-connect", ie 

Please do read my post when you reply, I did say by default many port scanners
ping first, scan later, by "default".

> send a syn
> wait for syn/ack
> if one arrives they know that port is open but don't ack. 

A lot of firewalls are built to drop the SYN, or log it.  Anyway, it's funny
how you keep talking about SYN/ACKs, a TCP construct, but when I talk about
them you start going on about ICMP?

> ie they know the port is open without having established a tcp
> connection. a sort of stealth port scan, and most firewalls/sentries
> won't pick it up. (i suspect linux ipfwadm/ipchains won't detect
> half-connect scans - needs checking out).

I suspect they would, but that's a configuration issue, firewalls if they're
blocking/dropping TCP connections look for the initial SYN, not the ACK to the
SYN ACK.