[C#] Testen van een TCP port

[Lethalis]

Beste tweakers,

Ik ben bezig met een component dat op een gestandaardiseerde manier computers moet testen op hun veiligheid. Het idee is om in een netwerk te scannen voor bepaalde poorten en hiervan een volledig rapport te maken, wat dan vervolgens gebruikt kan worden om snel en effectief een netwerk dicht te timmeren.

Nu zit ik met het volgende probleem: als ik met een TcpClient naar een bepaalde port wil connecten die niet reageert, dan krijg ik een time-out. Hoe zou ik deze time-out kunnen verkleinen op een nette manier?

Voorbeeld code:

code:

try
{
    TcpClient client = new TcpClient();
    client.Connect(host, port);
    client.Close();

    // Found one!
    FoundPort(host, port);
}
catch {}

Deze code wordt al in aparte threads uitgevoerd, dus wat dat betreft is de performance redelijk te noemen Het bestuderen van de framework documentatie leverde mij het volgende op:
- ReceiveTimeout
- SendTimeout

Maar beide schijnen helaas geen effect op de timeout tijdens het verbinden te hebben.

Help!

[Exirion]

Ben je nou gewoon voor de lol iets aan het maken? Anders kun je beter nmap gebruiken. Dat doet precies wat je aan het maken bent.

[ Voor 4% gewijzigd door Exirion op 25-11-2005 09:56 ]

[Lethalis]

Exirion schreef op vrijdag 25 november 2005 @ 09:56:
Ben je nou gewoon voor de lol iets aan het maken? Anders kun je beter nmap gebruiken. Dat doet precies wat je aan het maken bent.

Programma's als nmap ben ik mee bekend, maar het idee is juist dat ik het zelf programmeer en daarnaast wil ik het volledig gaan integreren in een systeem waar ik mee bezig ben. Het moet dus uiteindelijk veel meer kunnen dan alleen portscannertje spelen

[whoami]

Weet je wat ik echt ugly vind ?

code:

catch{}

da's gewoon een struisvogel-techniek.

Ben je wel zeker dat er een time-out bestaat voor het connecten ? Is het niet zo dat het het gooien van de exceptie is, die zo lang duurt ? (excepties throwen is duur).

[curry684]

Je zit met TcpClient op een veel te hoog niveau te werken, namelijk op de plek waar een connectie gewoon 'werkt of niet werkt' en je er gewoon data over wil stampen. Voor dit soort specialere dingen moet je direct met System.Net.Sockets.Socket aan de gang, de directe wrapper om de Berkeley interface. Een obvious methode is vervolgens om met BeginConnect een asynchronous connect uit te zetten, deze kun je dan zelf nuken wanneer het je uitkomt, bijvoorbeeld na een korte sleep

[Lethalis]

whoami schreef op vrijdag 25 november 2005 @ 09:59:
Weet je wat ik echt ugly vind ?

code:

catch{}

da's gewoon een struisvogel-techniek.

Ben je wel zeker dat er een time-out bestaat voor het connecten ? Is het niet zo dat het het gooien van de exceptie is, die zo lang duurt ? (excepties throwen is duur).

Het throwen van een exception is an sich wel duur, maar niet zo duur dat het meer dan 5 seconden duurt.

Maar enlighten me, hoe zou jij het aanpakken?

[Lethalis]

curry684 schreef op vrijdag 25 november 2005 @ 10:01:
Een obvious methode is vervolgens om met BeginConnect een asynchronous connect uit te zetten, deze kun je dan zelf nuken wanneer het je uitkomt, bijvoorbeeld na een korte sleep

Dank u. Ik zal het eens gaan onderzoeken

[pjvandesande]

Je kunt de socket die proberen te connecten toch in een list donderen en hier doorheen lopen, zit de socket er te lang in, dan trek je hem er uit.

Een voorbeeld hiervan vind je hier.

[joopv]

Is dit vanaf een windows machine?
Hou er rekening mee dat je in een XPSP2 systeem niet meer dan 10 sessies in opbouw (syn sent) kunt hebben staan. Als je snel een groot aantal poorten wilt scannen zal dat een limiet geven.

[Lethalis]

joopv schreef op vrijdag 25 november 2005 @ 10:23:
Is dit vanaf een windows machine?
Hou er rekening mee dat je in een XPSP2 systeem niet meer dan 10 sessies in opbouw (syn sent) kunt hebben staan. Als je snel een groot aantal poorten wilt scannen zal dat een limiet geven.

Is dit te omzeilen? Door bijvoorbeeld een setting in Windows te wijzigen?

In ieder geval bedankt voor de waarschuwing.

[curry684]

quote: http://www.tamos.com/htmlhelp/nettools/portscan.htm

Windows XP Service Pack 2 limits the number of simultaneous incomplete outbound TCP connections to 10 per application. Upon reaching this limit, subsequent connection attempts are placed in a queue eventually to be resolved at a fixed rate. This may significantly slow down an application that makes a large number of connection attempts. An example of such application is Essential NetTools in port scanning mode (the PortScan tool).

Presently, no legitimate, official workarounds are available for this problem. There is, however, an unofficial patch that modifies the system files and removes this limitation. If you are running Windows XP Service Pack 2 and are dissatisfied with the PortScan speed or results quality (i.e. many open ports may remain undetected), you may try to install one of the unofficial patches available at http://www.lvllord.de/ . Warning: This patch can only be applied to Windows XP Service Pack 2. This patch is not supported by Microsoft.

[Lethalis]

curry684 schreef op vrijdag 25 november 2005 @ 10:34:
[...]
(handige info)

Gelukkig werk ik nog met Windows 2000

Ik vind het op zich goed dat zo'n beveiliging in XP zit, maar wel bijzonder idioot dat het niet mogelijk is om het uit te zetten

[pjvandesande]

Lethalis schreef op vrijdag 25 november 2005 @ 10:41:
[...]

Ik vind het op zich goed dat zo'n beveiliging in XP zit, maar wel bijzonder idioot dat het niet mogelijk is om het uit te zetten

Anders heeft de beveiliging geen nut, een Exclude zou wel handig zijn, dat de gebruiker een specifiek process kan excluden van deze beveiliging. Nadeel is weer wel dat bijna elke gebruiker gewoon yes klikt bij warnings.

[Lethalis]

@curry684:
Works like a charm

questa schreef op vrijdag 25 november 2005 @ 10:44:
[...]
Anders heeft de beveiliging geen nut, een Exclude zou wel handig zijn, dat de gebruiker een specifiek process kan excluden van deze beveiliging. Nadeel is weer wel dat bijna elke gebruiker gewoon yes klikt bij warnings.

Ik zou het gewoon aan een user role hangen. Alleen Power Users and Administrators. Gewone gebruikers niet.

Ben je af van het hele gedoe.