Bekijk Volledige Versie : Kernel limits?
Jan 9 22:06:00 bt1 /kernel: Limiting closed port RST response from 284 to 200 p
ackets per second
Jan 9 22:06:01 bt1 /kernel: Limiting closed port RST response from 274 to 200 p
ackets per second
Hier heb ik er vrij veel van, alles werkt inmiddels wel goed (heb geen downtime kunnen vinden)
Ik ben heel benieuwd wat het is, ik heb dit sinds zaterdag avond en ben de enige niet hoorde ik al.
netvictory
10/01/05, 00:28
Klinkt meer als een hack poging of DOS attack ... wat voor poort was dit op ? Blijkbaar staat je kernel ingesteld niet meer dan 200 RST per sec te sturen....
Ik zal het beter zeggen;
Vrijdag avond zag ik een site offline gaan en heb ik via msn dat direct gemeld. De hoster in kwesie is direct gaan kijken en er was weinig te redden. Na een reboot werkte alles weer perfect.
Dag later, ik had had zelfde. Mijn machine was daarbij nog wél bereikbaar alleen HTTP was geheel dood. Ook apache restarten had geen nut meer, na een reboot van de machine was alles in orde.
Tijdens de aanval had ik een piek verkeer van 8 mbit, ik kan dit niet geheel geloven (stats zijn wel vaker niet geheel accuraat) maar het wijst in elk geval op iets aparts.
Http logs bieden géén uitkomst, dit is op het hele systeem het enige vindbare. Rikhunter ook geen dingen.
--edit
Normaal had ik (volgens SNMP stats) een gemiddelde load van 0.5 tot 0.8. Dit lijkt me vrij accuraat. Sinds de aanval heb ik loads van 0.03-0.05. Iets wat niet zou kunnen als ik het met mijn logische verstand probeer te begrijpen. Alle services draaien wél in orde.
Lijkt me dat mbufs ofzo vol zitten.
Doe eens als zo een probleem optreed netstat -am
Origineel geplaatst door luser
Lijkt me dat mbufs ofzo vol zitten.
Doe eens als zo een probleem optreed netstat -am
Top, geen hoge load en niets geks.
Netstat, geen extra connecties (althans, niets geks)
Het is echt iets heel raars maar ben inmiddels samen met 2 andere in dit probleem.
Probeer eens met tcpdump te kijken wat voor een verkeer er allemaal binnen komt.
Ik heb precies hetzelfde gehad, machine was te pingen en daar bleef het bij. Alle services waren ook ineens festopt. Machine booten en het werkte weer, logs gaven helaas weer niks weer.
Dus niemand met een oplossing?
hoe doe ik een TCP dump, geen idee van dat soort dingen geloof ik.
Voor de duidelijkheid; Alle services draaide prima alleen httpd was genokt. De service (httpd) draaide nog prima zonder hoge load maar was onbereikbaar.
Origineel geplaatst door yourforum
Top, geen hoge load en niets geks.
Netstat, geen extra connecties (althans, niets geks)
Het is echt iets heel raars maar ben inmiddels samen met 2 andere in dit probleem.
netstat -am toont wat anders dan dan alleen connecties.
Ik heb het ook voorgehad bij een bridge firewall hier...
Origineel geplaatst door Mikey
Ik heb precies hetzelfde gehad, machine was te pingen en daar bleef het bij. Alle services waren ook ineens festopt. Machine booten en het werkte weer, logs gaven helaas weer niks weer.
Had precies hetzelfde probleem met 1 server van het weekend, hele rare kwestie!
ik zal de namen van de andere niet noemen, staat slecht maar je bent nu de 4e of 5e die dit meld..
--edit
Kan het een aanval zijn tegen bepaalde hosters en/of het gebruik maken van een exploit?
Het lijkt inderdaad heel erg op een exploit... Vergelijk eens de kernel versies?
Origineel geplaatst door yourforum
ik zal de namen van de andere niet noemen, staat slecht maar je bent nu de 4e of 5e die dit meld..
--edit
Kan het een aanval zijn tegen bepaalde hosters en/of het gebruik maken van een exploit?
op dit moment (12.15) ondervinden we wéér deze aanval.
67/432/16192 mbufs in use (current/peak/max):
67 mbufs allocated to data
66/384/4048 mbuf clusters in use (current/peak/max)
876 Kbytes allocated to network (7% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
Dit keer is apache er helemaal uit geklapt, verder niets bijzonders kunnen vinden. Error log is ook (op 404 na) leeg.
Origineel geplaatst door Thijma.NL
Had precies hetzelfde probleem met 1 server van het weekend, hele rare kwestie!
fedora 1 ? 2199 ?
Freebsd 4.10 met apache 1.x hier.. (cpanel server)
Wij hadden dit probleem dus ook:
FC2, 2.6.9-1.6
Het lijkt me eerder een exploit in Apache 1.3.33 aangezien die er steeds als eerste uitklapt (en vaker dan de rest).
Ik neem eigenlijk aan dat jullie die ook draaien ?
//edit: typo in version ;p
Origineel geplaatst door PeterT
Wij hadden dit probleem dus ook:
FC2, 2.6.9-1.6
Het lijkt me eerder een exploit in Apache 1.33 aangezien die er steeds als eerste uitklapt (en vaker dan de rest).
Ik neem eigenlijk aan dat jullie die ook draaien ?
Klopt als een bus, cpanel stable.
Apache/1.3.33 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.10 FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7d
Opvallend:
http://lists.netsys.com/pipermail/full-disclosure/2004-October/028167.html
Heeft iemand dat al gereport aan de Apache Software Foundation?
er staat van wel, is ook uit 2004..
Limiting closed port RST response from 289 to 200 packets per second
Limiting closed port RST response from 284 to 200 packets per second
Limiting closed port RST response from 274 to 200 packets per second
Limiting closed port RST response from 278 to 200 packets per second
Limiting closed port RST response from 277 to 200 packets per second
Limiting closed port RST response from 278 to 200 packets per second
Limiting closed port RST response from 294 to 200 packets per second
Limiting closed port RST response from 238 to 200 packets per second
Limiting closed port RST response from 218 to 200 packets per second
Limiting closed port RST response from 250 to 200 packets per second
Limiting closed port RST response from 288 to 200 packets per second
Limiting closed port RST response from 276 to 200 packets per second
Limiting closed port RST response from 313 to 200 packets per second
pid 54970 (htpasswd), uid 1006: exited on signal 10 (core dumped)
pid 65253 (httpd), uid 0: exited on signal 11 (core dumped)
pid 65286 (httpd), uid 0: exited on signal 11 (core dumped)
pid 65385 (httpd), uid 0: exited on signal 11 (core dumped)
pid 66118 (httpd), uid 0: exited on signal 11 (core dumped)
Origineel geplaatst door yourforum
Klopt als een bus, cpanel stable.
Hier fc 1 2199, Server version: Apache/2.0.51
Origineel geplaatst door yourforum
Opvallend:
http://lists.netsys.com/pipermail/full-disclosure/2004-October/028167.html
Let op is een local exploit, en niet buitenaf.
Hmm... Apache 2.0.51
Dan zou het dus niet in 1.3.33 liggen - en dus misschien ook niet aan Apache
we hebben het op dit moment weer, machine is echt ongelovelijk van slag en we doen er alles aan het weer goed lopend te krijgen.
Heb inmiddels rkhunter en chkroot laten draaien, beide weinig resultaat.
Ik ben dus nu wel degelijk ten einde raad.
netstat -am
259/752/16192 mbufs in use (current/peak/max):
259 mbufs allocated to data
249/522/4048 mbuf clusters in use (current/peak/max)
1232 Kbytes allocated to network (10% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
Origineel geplaatst door yourforum
we hebben het op dit moment weer, machine is echt ongelovelijk van slag en we doen er alles aan het weer goed lopend te krijgen.
Heb inmiddels rkhunter en chkroot laten draaien, beide weinig resultaat.
Ik ben dus nu wel degelijk ten einde raad.
Anders zoek je even met google.
Op verschillende plekken worden afdoende suggesties gedaan. ;)
gedaan, schiet niet op. Alle exploits hebben we ook al nagelopen.
Origineel geplaatst door yourforum
gedaan, schiet niet op. Alle exploits hebben we ook al nagelopen.
Het heeft ook niets met exploits van doen, zoals je al kon zien na je google zoekopdracht.
Het heeft ook niets te doen met de daemons die je draait en er al dan niet als eerste uit klappen. ;)
Grappig genoeg is dit een "Frequently Asked Question", wat dus ook de reden is dat ik je doorverwees naar google. ;)
Ik denk dat je aan de volgende link misschien nog wel wat kunt hebben:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/networking.html#ICMP-RESPONSE-BW-LIMIT
dit gaat over een andere melding, is dit vergelijkbaar ?
Op google heb ik namelijk met de kernel warning gezocht maar niets gevonden waar daadwerkelijk een goed antwoord bij zat.
Origineel geplaatst door M-BahZ
Het heeft ook niets met exploits van doen, zoals je al kon zien na je google zoekopdracht.
Het heeft ook niets te doen met de daemons die je draait en er al dan niet als eerste uit klappen. ;)
Grappig genoeg is dit een "Frequently Asked Question", wat dus ook de reden is dat ik je doorverwees naar google. ;)
Ik denk dat je aan de volgende link misschien nog wel wat kunt hebben:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/networking.html#ICMP-RESPONSE-BW-LIMIT
Dat is voor FreeBSD, ik heb een linux machine met exact dezelfde symptomen, beetje vreemd of niet ?
Origineel geplaatst door yourforum
dit gaat over een andere melding, is dit vergelijkbaar ?
Het gaat over het zelfde probleem inderdaad.
Overigens wil ik wel even opmerken dat jouw server geflood wordt door iemand. ;)
Origineel geplaatst door Mikey
Dat is voor FreeBSD, ik heb een linux machine met exact dezelfde symptomen, beetje vreemd of niet ?
Waarom niet even lezen ? ;)
Wat voor proftpd gebruiken jullie, ik heb in elk geval een exploit daarvoor gevonden die bij ons inmiddels is opgelost.
Wij gebruiken PureFTPd :)
wat zegt dit:
# /usr/local/apache/bin/apachectl configtest
Syntax OK
Segmentation fault (core dumped)
#
Apache draait verder prima alleen met véél te hoge loads.. performance is optimaal.
Dat zegt meestal dat je geheugen of je HD brak is. Houdt eigenlijk in dat het programma iets doet wat hij niet zou mogen doen, wat meestal komt omdat instructies spontaan verandert zijn (door brakke HD of geheugen)
Lijkt me toch gek, alles draait namelijk perfect
hoe kom ik er achter of iets daadwerkelijk kapot is
Origineel geplaatst door M-BahZ
Waarom niet even lezen ? ;)
Ik had het gelezen, en daar staat oa. dat het een flood of bruteforce kan zijn. De server die bij mij op z`n gat ging had een average dataverkeer van 8kbit, en geen pieken, gewoon het standaard netwerk verkeer. Tevens liet snort ook niks zien, erg raar.
Origineel geplaatst door yourforum
Lijkt me toch gek, alles draait namelijk perfect
hoe kom ik er achter of iets daadwerkelijk kapot is
Alles draait perfect totdat je bij dat ene geheugenbitje komt wat kapot is en daar wat in zet ;)
Als je het alleen bij dit programma hebt zou ik apache is opnieuw installen.
Overigens kan zo'n segfault nog wel meer betekenen, zijn ook wel gevallen bekend waarbij dat een teken was dat de machine gehackt was :>
Mocht je het probleem bij meerdere programma's hebben, kijk dan of je de server even offline kan halen voor een memtest of verwissel het geheugen gewoon even voor de zekerheid.
nee het is alleen bij apache, de rest heb ik allemaal gecontroleerd.
Dat de machine gehacked is waren we al achter ;) naja hacken, gebruik gemaakt van een exploit.
Apache exploiten of root access krijgen zijn 2 verschillende dingen hè? ;)
die was een exploit in proftpd waardoor men root access kon krijgen. Heb alle files kunnen vinden en verwijderen maar ze zijn voor zover zichtbaar niet binnen gekomen.
Het lijkt me geen hardware probleem zoals sommige hier proberen duidelijk te maken. Er zijn meerdere mensen die op het zelfde moment last van hebben, is wel een beetje toevallig of niet?
inderdaad, ik begin nu echt sterk te twijfelen.
Origineel geplaatst door handy
Het lijkt me geen hardware probleem zoals sommige hier proberen duidelijk te maken. Er zijn meerdere mensen die op het zelfde moment last van hebben, is wel een beetje toevallig of niet?
Het probleem dat ondertussen wordt beschreven hebben wij in ieder geval niet.
Ik heb gister apache via cpanel opnieuw er op gezet, hierdoor is de load van 1.5 naar 0.5 gegaan dus daar heeft het wel iets mee te maken.
De melding (core dump oid) blijft helaas.
Hardware lijkt me niet echt eigelijk. Maar goed, het zou inderdaad kunnen.
neographikal
14/01/05, 22:37
Uhm controleren jullie wel de md5sums, een incompleet of veranderd bestand kan ook heel vreemde gevolgen hebben :)