PDA

Bekijk Volledige Versie : Ontzettend vaag Apache probleem



vaplu
10/12/03, 15:24
Ik heb het volgende ontzettend vage apache probleem:

Om het xx aantal weken/dagen (lijkt totaal @random) stopt apache met het serveren van webpages. De apache deamon draait nog gewoon en de system idle is 99/100%. Een "kill -HUP" is nodig om apache te stoppen een weer draaiende te krijgen. Een graceful restart levert het volgend op:

/var/www/bin/apachectl graceful: httpd not running, trying to start
/var/www/bin/apachectl graceful: httpd started

[Wed Dec 10 11:44:46 2003] [crit] (98)Address already in use: make_sock: could not bind to port 80

Tijdens de periode dat pagina's niet meer geladen kunnen worden wanneer een site wordt bezocht, logt apache nog wel vrolijk door. In de log files van apache/syslog is niks terug te vinden dat niet normaal is.

Ik heb nu ff totaaaaal geen id waar het aan zou kunnen liggen en zoeken in newsgroepen en google heeft me ook al niets opgeleverd.

Nog wat info van de debian server:
[Wed Dec 10 11:47:46 2003] [notice] Apache/1.3.29 (Unix) mod_macro/1.1.2 AuthMySQL/2.20 PHP/4.3.4 mod_ssl/2.8.16 OpenSSL/0.9.6c configured -- resuming normal operations


Ik heb op grond van wat logfiles het volgende te constateren: Het komt meestal voor rond 10:00 's ochtends, de laatste 2x was op de 10e van de maand....

iemand suggesties?

McRox
10/12/03, 22:16
Heeft u gekeken of het door een cron veroorzaakt is, aangezien het volgens u in regelmaat gebeurt?

vaplu
10/12/03, 23:15
Ja dat had ik idd nog even moeten vermelden... er draait absoluut niet iets significants in de cron... vooral niet om de tijdstippen wanneer het probleem zich voor doet.

McRox
11/12/03, 00:27
Heeft u in de error logs gekeken?

vaplu
11/12/03, 01:45
Origineel geplaatst door PlexTeam
Heeft u in de error logs gekeken?

"In de log files van apache/syslog is niks terug te vinden dat niet normaal is."

Het antwoord is ja :)

Deimos
11/12/03, 11:29
Probeer eens te telnetten naar poort 80 wanneer de Apache niks meer toont en bekijk of je via telnet nog wel output krijgt. Eventueel even de optie server-status aanzetten in de httpd.conf om te bekijken wat de laatste processen waren (even uitgaande dat die ze daar niet meer verder logt). Ook kan je daar zien hoeveel threads er van apache draaien.

vaplu
11/12/03, 13:16
Origineel geplaatst door Deimos
Probeer eens te telnetten naar poort 80 wanneer de Apache niks meer toont en bekijk of je via telnet nog wel output krijgt. Eventueel even de optie server-status aanzetten in de httpd.conf om te bekijken wat de laatste processen waren (even uitgaande dat die ze daar niet meer verder logt). Ook kan je daar zien hoeveel threads er van apache draaien.

Omdat ik de sites die op de server draaien zsm weer online wilde hebben, heb ik geen tijd gehad om te telnetten naar poort 80 of traffic te sniffen ... dit zal ik de eerst volgende keer dat het probleem voorkomt meteen doen... Ik zal ook even kijken of lynx op de server zelf de poot nog kan openen.

Ik zal ook de server-status optie aan zetten, ben benieuwd wat dat op gaat leveren... thnx voor de tips !!

vaplu
11/12/03, 15:27
Server-status staat nu aan.... maar tis niet alsof de server het druk heeft, maar ik log nu om de minuut de pagina in 1 file (per dag):


Server Version: Apache/1.3.29 (Unix) PHP/4.3.4
Server Built: Nov 11 2003 00:51:41

--------------------------------------------------------------------------------
Current Time: Thursday, 11-Dec-2003 14:19:01 CET
Restart Time: Wednesday, 10-Dec-2003 16:03:14 CET
Parent Server Generation: 6
Server uptime: 22 hours 15 minutes 47 seconds
2 requests currently being processed, 9 idle servers
_GW________....................................... ..............
.................................................. ..............
.................................................. ..............
.................................................. ..............

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"L" Logging, "G" Gracefully finishing, "." Open slot with no current process

PID Key:


3226 in state: _ , 12166 in state: G , 14017 in state: W
12739 in state: _ , 21654 in state: _ , 29946 in state: _
28711 in state: _ , 7890 in state: _ , 1095 in state: _
19925 in state: _ , 23129 in state: _ ,

vaplu
12/12/03, 14:49
Het is wel duidelijk dat dit een vaag probleem is.... mijn vraag om suggesties/help heeft ook nix geholpen in de apache nieuwsgroepen of op GOT ...

Wellicht dat ik nog een oplossing vind of de veroorzaker kan aanwijzen... ik zal het tegen die tijd ook even melden :)

thnx voor de suggesties iig.

mihosnet
12/12/03, 17:19
tijdelijke oplossing:

netstat -lep
kill alle https verbindingen

Hier heb ik het probleem opgelost door een andere firewall te gebruiken, welke firewall gebruik je?

vaplu
12/12/03, 17:27
Origineel geplaatst door mihosnet
tijdelijke oplossing:

netstat -lep
kill alle https verbindingen

Hier heb ik het probleem opgelost door een andere firewall te gebruiken, welke firewall gebruik je?

Openssl gebruik ik voor nu even niet meer.. dus https verbindingen killen lijkt me niet meer nodig :)

Ik gebruik iptables v1.2.7a nix bijzonders dus... welke firewall gebruikte je en ben je gaan gebruiken?

Norman
13/12/03, 12:58
misschien iets doms ....
kan het zijn dat er mensen apache exploits proberen waardoor die zo "vastloopt" ??

vaplu
13/12/03, 16:55
Origineel geplaatst door Norman
misschien iets doms ....
kan het zijn dat er mensen apache exploits proberen waardoor die zo "vastloopt" ??

Nou, ik vind jou gedachte kronkel nog niet zo gek... ik heb er ook al aangedacht dat iemand een 'fout' script draait (php dan waarschijnlijk, maar met uitzonder cgi)... maar aangezien er best veel websites op die server staan, heb ik niet veel zin om elk script te gaan uitpluizen.. enig idee hoe ik er achter kan komen of er 'foute' scripts draaien? (scripts die bagger zijn geschreven of juist express lekken proberen)...

ik heb de logs hier al op na gekeken en ik kon zelfs niets vinden.... in de access.log staan wel regelmatig probeersels om ISS te exploiten.. maarja :) geloof niet dat ik me daar druk over moet maken :D

zal de logs nog eenmaal bekijken zodra ik weer tijd heb..bedankt voor je suggestie !

mihosnet
14/12/03, 23:57
Kijk eens of je bent geinfecteerd;
http://www.chkrootkit.org/

Dat kan ook de reden zijn..

vaplu
15/12/03, 01:27
Lijkt me uitgesloten, de boel zit flink dicht getimmerd met grsec.

nickpick
20/12/03, 23:54
Weet je zeker dat er niet ergens een script op je server draait dat vatbaar is voor een zgn "File Injection Exploit" of zo?
Een voorbeeld is de exploit in My_eGallery voor bv PostNuke en PHP Nuke.

Doe eens "ps ax" en kijk of er geen rare programmaatjes draaien (bijvoorbeeld r0nin, of cgi-txt). Die troep veroorzaakt namelijk soorgelijk gedrag (apache down en niet herstartbaar). Vooral die r0nin is de laatste tijd erg aktief in Nederlandse IP-ranges.
Je kan ze ook vinden door te kijken in je /tmp
Daarin zie je duidelijk deze bestandjes staan met als owner apache.

Zie ook: Zie ook: http://www.nukecops.com/article-1015-nested-0-0.html

vaplu
21/12/03, 12:07
Origineel geplaatst door nickpick
Weet je zeker dat er niet ergens een script op je server draait dat vatbaar is voor een zgn "File Injection Exploit" of zo?
Een voorbeeld is de exploit in My_eGallery voor bv PostNuke en PHP Nuke.


Ik zal eens rond kijken of iemand dergelijk software draait.



Doe eens "ps ax" en kijk of er geen rare programmaatjes draaien (bijvoorbeeld r0nin, of cgi-txt). Die troep veroorzaakt namelijk soorgelijk gedrag (apache down en niet herstartbaar). Vooral die r0nin is de laatste tijd erg aktief in Nederlandse IP-ranges.
Je kan ze ook vinden door te kijken in je /tmp
Daarin zie je duidelijk deze bestandjes staan met als owner apache.


"ps ax" levert geen onbekende processen op, de /tmp dir ziet er netjes uit zonder enige verdachte files. Ik ga het natuurlijk wel in de gaten houden.

Wat is "r0nin"? (een gebrek aan tijd om dit uit te zoeken doet mij deze vraag stellen)

mihosnet
21/12/03, 16:45
Via bijv. eGallery kan r0nin worden uitgevoerd, hiermee kunnen ze root toegang krijgen.

Probeer chkrootkit, deze kan r0nin detecteren..

vaplu
21/12/03, 21:58
Origineel geplaatst door mihosnet
Probeer chkrootkit, deze kan r0nin detecteren..

Ik heb chkrootkit-0.42b gedraaid, maar het kwam zo'n beetje hier op neer: "nothing found/not infected" :)

Dus die "r0nin" (wat een worm ik neem ik aan) kan het niet zijn.

mihosnet
22/12/03, 19:20
En je ziet 'm ook niet in de /tmp map?

vaplu
22/12/03, 21:35
Origineel geplaatst door mihosnet
En je ziet 'm ook niet in de /tmp map?

Nee hoor /tmp ziet er netjes uit... ook andere temp dirs (ivm openbasedir restrictie) zien er prima uit.

mihosnet
23/12/03, 00:11
het kan ook onder de naam 'friends' zijn verstopt in de map /tmp

vaplu
23/12/03, 01:03
Origineel geplaatst door mihosnet
het kan ook onder de naam 'friends' zijn verstopt in de map /tmp

Nee hoor :) daar staat alleen een hele zooi session files enzo.. nix van dat... maar ik wil het zelf ook wel even uitzoeken, heb je misschien een link met meer info?