three-way TCP

[Andreas Ericsson]

Sébastien Cantos wrote:
>>Sébastien Cantos wrote:
>>
>>>Hi,
>>>
>>>You can check if a service (tcp port) is responding just by 
>>
>>completing 2
>>
>>>parts of the 3 way handshake.
>>>
>>>1/ Client send a Syn to the server
>>>2/ Server respond with a Syn/Ack
>>>
>>
>>This is quite obviously not the case with the nagios plugins, for a 
>>number of reasons.
> 
> 
> 
> I'm agree that Nagios is a monitoring tool and that it can do full TCP
> connexions to check the availability of a service.
> I think that you have not seen my answer in the right context. I was just
> trying to find out why he was asking this question.
> 

I'm glad that you agree.

> 
> 
> <Out of context>
> 
> I don't understand why you waste your time with the next comments ... Maybe
> you feel the need to demonstrate your knowown ... Do you feel frustated ? :)
> 
> 
> So I'll also waste some of my time to comment your comments :
> 
> 
>>1. It generally causes some distress for the targeted servers 
>>(handles 
>>left open pending timeout), which Nagios checks wouldn't do.
> 
> 
> Right, but as you're just sending one Syn every check period (5 mn for
> example), the SYN_RECV state will timeout on the server. We are not dealing
> here with Synflood attacks. 
> 

Enter the case of a failed service/host check. Host-checks are executed 
in serial, so a host with a max check attempt of 10 would leave 10 
sockets waiting with all sorts of resources clanged down.

> 
> 
>>2. SYN scanning requires access to raw sockets, which isn't 
>>permitted to 
>>regular users on any unix system I'm aware of. The plugins 
>>doesn't run 
>>as root, so they wouldn't be able to obtain a raw socket (also, raw 
>>sockets are very much more difficult to handle programmatically and 
>>since they're not needed, it's just plain dumb to use them). 
>>There are 
>>exceptions ofcourse (check_icmp and check_dhcp for instance, for 
>>protocol reasons) but the source is freely available so you 
>>can easily 
>>vet the relevant plugins.
> 
> 
> You said it! there are exeptions.

For programs that require access to raw sockets because of the protocol 
involved in doing the checking. TCP checking does not. ICMP, however, does.

> What about if you have to check a service
> which is behind some firewall which doesn't allow full TCP connexion
> establishment ? Just to demonstrate that it could be usefull.
> 

If you have firewalls that let everything but RST through, you've either 
been swindled by your dealer, or you're completely incompetent and 
should be flogged with ethernet cables. Simple as that.

> 
> 
>>3. Checks are written to mimic client behaviour. Proper 
>>clients don't go 
>>out of their way to stir up mischief. Unproper ones might, but the 
>>checks aren't designed to be pen-testing apps, but rather tests of 
>>proper standards-compliant functionality.
> 
> 
> Sometimes you cannot be in the *real* client side to do the checks, so you
> have to adapt the checks.
> 

True, but I can't think of any one single occasion where that would 
include not completing the three way handshake.

> 
> 
>>>This is called *stealh* scanning.
>>>
>>
>>No, it's called SYN scanning. Probing with FIN, FIN(URG|PUSH) 
>>and empty 
>>(NULL) packets is called stealth scanning (although lots of 
>>tools have 
>>been developed to detect those too since nmap became a fairly 
>>standard 
>>tool). Try to read more than one script-kiddie hacking page 
>>every once 
>>in a while. If nothing else, it should keep you occupied with 
>>something 
>>legal.
> 
> 
> Stealth scanning is used for every scan method that doesn't acomplish full
> tcp connexion (SYN, FIN etc ...). So if you want to be more acurate we can
> say Syn scanning or better Half open scanning.

A connection initiation attempt is not stealth. Most servers log the 
failure to complete an initiated three way handshake, while most also 
skip logging of FIN and empty packets.

> If you have ever read this: http://www.phrack.org/show.php?p=51&a=11 you
> surely know that SYN scanning or half open scanning is also called syn
> *stealth* scanning.
> Do you mean Phrack is a script-kiddie hacking page ? :) 
> 

Yes. It was a long time since anything was published there that's not a 
  clean rip-off from bugtraq or equivalent. Read the linenoise and 
you'll know what I mean. I'm sure you'll find your name there somewhere.

> <out of context/>
> 
> Regards,
> --
> /*  truff <truff at projet7.org>
>  *  http://www.projet7.org (Security Researchs)
>  *  gpg: http://www.projet7.org/gpgkeys/truff.asc
>  */
> 
> 

I'm sure your mother acted properly impressed by the awesome C skills 
required to put a comment in your .sig. I'm equally sure we don't need 
another l337 web-page containing nothing but papers and code written by 
others.

Cheers, wee one.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null