Server is listening, maar connectie timed out

[Olaf van der Spek]

Ik heb een zelfgeschreven server draaien op Linux gs1061 2.6.1 #4 SMP Tue Jan 27 15:19:24 CET 2004 i686 GNU/Linux
De server luistert op de TCP poorten 4000, 4005 en 4007.
Maar naar poort 4000 kan ik ineens niet meer connecten, terwijl dat vroeger (gisteren) wel gewerkt heeft. De server is niet eens herstart.

code:

$ netstat -anp
tcp        0      0 0.0.0.0:4000            0.0.0.0:*               LISTEN     500/xwis
tcp        0      0 0.0.0.0:4005            0.0.0.0:*               LISTEN     500/xwis           
tcp        0      0 0.0.0.0:4007            0.0.0.0:*               LISTEN     500/xwis     

$ telnet localhost 4000
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection timed out

$ telnet localhost 4005
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Alle poorten hebben precies dezelfde functie en worden door de code gelijk behandelt.
Weet iemand hoe dit kan?

[silentsnake]

Maar wat voor service luisterd er dan op poort 4000? Wellicht een idee om die service te herstarten?

[Olaf van der Spek]

Het gaat om een enkele service (XWIS) die luistert op drie poorten, 4000, 4005 en 4007. Een restart levert geen verbetering op.

[bkor]

Voor bedrijf? Je collega heeft met iptables zitten spelen.
Persoonlijk? Je had veel alcohol op en hebt met iptables zitten spelen.

4000 is dacht ik ICQ.. waarschijnlijk de bedoeling om ICQ uitgaand te blokkeren maar geen interface gespecificeerd (van je internetverbinding).

[Olaf van der Spek]

Het is een dedicated server, niemand die daar ICQ op gebruikt.
En ik heb echt niet met iptables lopen spelen.

[Gondor]

* Gondor doet een gooi:
Hoe heb je de laatste keer de verbinding verbroken? Als dat niet is gegaan zoals het moest, is misschien het socket oid nog open/geblokkeerd op die poort ofzo?

Ik heb niet echt een idee hoe je daar achter kan komen maar een reboot zal het zeker oplossen als dat het probleem is. En anders kan je kijken of je progje fout meldingen geeft/krijgt over/richting poort 4000.

[Olaf van der Spek]

Mijn kern.log staat ook vol met regels als:

code:

Apr 25 13:43:50 gs1061 kernel: NET: 2196 messages suppressed.
Apr 25 13:43:45 gs1061 kernel: TCP: drop open request from #.#.#.#/1182

Zou dit er iets mee te maken kunnen hebben?
En waarom staat er niet om welke local port het gaat?

[Verwijderd]

Wat gebeurt er als je maar 1 proces van XWIS laat draaien die alleen naar port 4000 (en niet die andere twee) luistert?

[DAMAGE]

probeer anders eens met nmap ofzo. vind ik persoonlijk wat beter als netstat. nmap localhost check op tcp en udp.

eventueel al de processen killen van die service, en dan opnieuw opstarten, kijken of hij dan wel reageert?

Had ik eerst ook met mijn dns, draaide hij wel al op poort 53, deed ik /etc/init.d/pdns stop, en toen zei hij dat hij stopte. schijnbaar niet dus want poort 53 was nog inuse. even checken wat op die poortjes draaien enventueel al de services killen op die poort, en dan eens opnieuw starten, maybe dat hij dan wel draait?

ps aux | grep servicenaam kun je altijd even kijken hoeveel instanses er draaien.

Kun je ook telnetten op die poort oid?

[ Voor 4% gewijzigd door DAMAGE op 01-05-2004 15:40 ]

[Olaf van der Spek]

Het is mogelijk een DoS attack op port 4000.

code:

$ netstat -s
Tcp:
    3769 active connections openings
    1330672 passive connection openings
    406599729 failed connection attempts
    12285 connection resets received
    52 connections established
    505911241 segments received
    101360670 segments send out
    99424 segments retransmited
    34701679 bad segments received.
    29572198 resets sent
$ top
top - 16:41:20 up 9 days,  5:05

Ik heb nu syn cookies aangezet en ik ga morgen kijken of het weer werkt.

[Verwijderd]

Of iemand loopt je zelf geschreven programma te testen of je hebt last van de witty worm die een vulnerability uitbuit in ISS producten (realsecure en blackice). De vulnerability zit namelijk in de ICQ protocol module van die produkten en die verwekt al het verkeer op poort 4000.

Als het de worm is dan is het alsnog vreemd dat jouw programma er ook door crashed/vastloopt/instabiel wordt, maar je kan in ieder geval beginnen met een andere poort te gebruiken dan 4000. Deze poort staat namelijk vrij algemeen bekend als een poort die gebruikt wordt door ICQ.

En wat je eigen daemon betreft, ik hoop dat je die een beetje secure geprogrammeerd hebt met het oog op buffer overflows enzo.

[update]
Crap lees nu net dat het TCP connecties zijn in jouw geval en de witty worm maakt gebruik van UDP. Anyway mijn opmerking over veilig programmeren blijft wel staan.

[ Voor 12% gewijzigd door Verwijderd op 01-05-2004 18:52 ]

[Olaf van der Spek]

Verwijderd schreef op 01 mei 2004 @ 18:49:
En wat je eigen daemon betreft, ik hoop dat je die een beetje secure geprogrammeerd hebt met het oog op buffer overflows enzo.

[update]
Crap lees nu net dat het TCP connecties zijn in jouw geval en de witty worm maakt gebruik van UDP. Anyway mijn opmerking over veilig programmeren blijft wel staan.

Ik hoop het ook. Maar volgens mij zit er minstens een bug in (;->), want de daemon is een paar keer vlak achter elkaar gecrashed. Daarvoor had die weken met 250+ open connecties gedraaid, dus het kan bijna geen toeval zijn.
De bug zelf vinden is echter wat lastig.

Van port veranderen kan niet (echt), want er is een client die hard-coded port nummers gebruikt.

[ Voor 8% gewijzigd door Olaf van der Spek op 01-05-2004 19:07 ]

[zeroxcool]

Wat doet een:

code:

lsof -i tcp:4000
lsof -i tcp:4005
lsof -i tcp:4007

?

[ Voor 6% gewijzigd door zeroxcool op 01-05-2004 20:32 . Reden: typo ]

[Verwijderd]

OlafvdSpek schreef op 01 mei 2004 @ 19:07:
Ik hoop het ook. Maar volgens mij zit er minstens een bug in (;->), want de daemon is een paar keer vlak achter elkaar gecrashed. Daarvoor had die weken met 250+ open connecties gedraaid, dus het kan bijna geen toeval zijn.
De bug zelf vinden is echter wat lastig.

Normalerwijze lingert een socket in de background na een close() (of een crash); als je server automatisch restart kan hij vervolgens niet onmiddelijk opnieuw die poort binden tenzij de SO_REUSEADDR socketoption gezet is; als de server niet voldoende errorchecking op bind() en listen() doet merk je dus niet dat je op een ongebonden socket zit te werken.

Ik weet niet of dit het geval is, maar in dat geval krijg je de symptomen die jij beschrijft: netstat geeft (een tijd lang) een geopende poort maar er is geen server listening terwijl het serverproces wel draait.

[Olaf van der Spek]

De daemon restart niet automatisch en zelfs na een restart van de complete server bleef het probleem bestaan. Error checking doe ik wel in deze daemon start niet als bind of listen failed.
netstat -lnp geeft dan wel aan dat er geen proces meer luistert (lijkt me).