Veel willekeurige connecties naar apache

[PierreAronnax]

Ik heb sinds twee dagen het probleem dat naar mijn server vanaf veel verschillende hosts wordt verbonden met poort 80. Zo veel dat mijn apache er na een paar minuten mee ophoud. De verzoeken zijn naar volledig willekeurige URL's (zie eerste code blok).

Ik heb na mijn weten niks speciaals gedaan waardoor dit kan worden verklaart. Ik vraag mij dus nu af wat ik hier aan kan doen. De connecties komen vanaf willekeurige IP's, dus blocken op IP lijkt mij niet mogelijk.
Wat kan ik hier aan doen?

---

code: /var/log/apache2/access.log

222.93.155.189 - - [01/Nov/2007:20:19:18 +0100] "GET http://inbound.linktrust.com:80/redir.aspx?CID=3491&AFID=5633&SID= HTTP/1.1" 302 188 "http://www.leefound.info/search.php?keywords=sportsbetting" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
216.195.54.95 - - [01/Nov/2007:20:19:18 +0100] "GET http://sys119.3fn.net/XSpiderWEB/test.html HTTP/1.1" 200 10240 "-" "-"
222.93.155.189 - - [01/Nov/2007:20:19:19 +0100] "GET http://inbound.linktrust.com:80/redir.aspx?CID=1279&AFID=5633&SID= HTTP/1.1" 302 163 "http://www.leefound.info/search.php?keywords=sportsbetting" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
222.93.155.189 - - [01/Nov/2007:20:19:20 +0100] "GET http://login.tracking101.com:80/sw/47399/CD13425/ HTTP/1.1" 301 - "http://www.leefound.info/search.php?keywords=sportsbetting" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
222.93.155.189 - - [01/Nov/2007:20:19:21 +0100] "GET http://ekmas.com:80/ez/bvsgnqfgdvdy/&dp=0&l=0&p=0 HTTP/1.1" 302 316 "http://www.leefound.info/search.php?keywords=sportsbetting" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
59.56.109.245 - - [01/Nov/2007:20:19:21 +0100] "GET http://network.realmedia.com/RealMedia/ads/adstream_sx.ads/firstgames/160x600/ron/entgms/ss/a@x10 HTTP/1.0" 200 412 "http://www.wscj.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)"
84.16.252.79 - - [01/Nov/2007:20:19:22 +0100] "POST http://89.149.241.191/d3sUpER3fg.php HTTP/1.1" 200 4 "-" "-"
59.56.109.45 - - [01/Nov/2007:20:19:23 +0100] "GET http://64.191.218.21/RealMedia/ads/adstream_jx.ads/www.InternalTest.com/d2/1610786049@Bottom?x HTTP/1.0" 200 2107 "http://network.realmedia.com/RealMedia/ads/adstream_sx.ads/firstgames/728x90/ron/entgms/ss/a@Top1" "Mozilla/4.76 [en] (X11; U; SunOS 5.8 sun4u)"
222.93.155.189 - - [01/Nov/2007:20:19:24 +0100] "GET http://login.tracking101.com:80/ez/bvsgnqfgdvdy/&dp=0&l=0&p=0 HTTP/1.1" 200 822 "http://www.leefound.info/search.php?keywords=sportsbetting" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
59.56.109.45 - - [01/Nov/2007:20:19:25 +0100] "GET http://a248.e.akamai.net/m/800/1129/1176222143/oascentral-s.realmedia.com/RealMedia/ads/Creatives/OASTech/KGU_April2007_OAS_Disc/TFSMFlashWrapper201.js HTTP/1.0" 200 1934 "http://network.realmedia.com/RealMedia/ads/adstream_sx.ads/firstgames/728x90/ron/entgms/ss/a@Top1" "Mozilla/4.76 [en] (X11; U; SunOS 5.8 sun4u)"
81.57.24.236 - - [01/Nov/2007:20:19:25 +0100] "GET http://tracker.affistats.com/tag.php?id=a3552b11001c411276e2f2g5h378i7k8 HTTP/1.0" 200 254 "http://www.nets888.com/pompidou.htm" "mozilla/4.0 (compatible; msie 6.0; windows nt 5.1; sv1; funwebproducts)"
66.39.218.7 - - [01/Nov/2007:20:19:32 +0100] "GET http://www.ticketmaster.com/event/09003F119A7C4523?artistid=1149434&majorcatid=10001&minorcatid=1 HTTP/1.1" 200 21552 "-" "Opera/9.22 (Windows NT 5.1; U; en)"
66.39.218.7 - - [01/Nov/2007:20:19:34 +0100] "CONNECT www.ticketmaster.com:443 HTTP/1.1" 403 894 "-" "-"

Een selectie van netstat:

code: netstat

tcp        0      0 192.168.1.100:www       73.70.134.219.bro:20949 ESTABLISHED
tcp        0      0 192.168.1.100:www       73.70.134.219.bro:18581 TIME_WAIT
tcp        0      0 192.168.1.100:52876     63.215.91.200:1101      TIME_WAIT
tcp        0      0 192.168.1.100:www       208-74-100-10.arsa:1512 ESTABLISHED
tcp        0      0 192.168.1.100:52869     www.qksrv.net:www       TIME_WAIT
tcp        0      0 192.168.1.100:52867     58.48.21.72.static.:www TIME_WAIT
tcp        1      0 192.168.1.100:52875     yoomy.com:www           CLOSE_WAIT
tcp        0      0 192.168.1.100:52860     yoomy.com:www           TIME_WAIT
tcp        0      0 192.168.1.100:52879     207-67-0-188.static:www ESTABLISHED
tcp        0      0 192.168.1.100:www       ocr7.mtctickets.co:2619 FIN_WAIT2
tcp        0      0 192.168.1.100:52866     ug-in-f147.google.c:www TIME_WAIT
tcp        0      0 192.168.1.100:52859     ug-in-f147.google.c:www TIME_WAIT
tcp        0      0 192.168.1.100:www       cng204.neoplus.ads:1242 TIME_WAIT
tcp        0      0 192.168.1.100:www       208.177.78.6.ptr.u:4242 FIN_WAIT2
tcp        0      1 192.168.1.100:www       189.155.93.222.bro:1428 LAST_ACK
tcp        0      0 192.168.1.100:52873     208.74.174.162:www      TIME_WAIT
tcp        0      0 192.168.1.100:www       208.74.174.162:52877    TIME_WAIT

Een screenshot van iptraf:



De Linux versie is Debian 2.4.27
192.168.1.100 is mijn server, en 10.0.0.138 is mijn modem.

[deadinspace]

PierreAronnax schreef op donderdag 01 november 2007 @ 20:41:
Ik heb sinds twee dagen het probleem dat naar mijn server vanaf veel verschillende hosts wordt verbonden met poort 80. Zo veel dat mijn apache er na een paar minuten mee ophoud. De verzoeken zijn naar volledig willekeurige URL's (zie eerste code blok).

Wat mij opvalt is dat apache op al die requests (behalve die laatste https connectie) 200, 301, of 302 antwoordt. Dat wil zeggen dat je apache die gerequeste files kent of beweert te kennen. Gezien die uiteenlopende requests lijkt me dat vrij sterk, en vermoed ik dat je apache gebruikt wordt als proxy.

De Linux versie is Debian 2.4.27

Debian 2.4.27 bestaat niet, dus welke Debian versie draai je dan wel?

Ook interessant:

• Hield je de Debian security updates bij?
• Welke poorten van je server waren/zijn van buitenaf benaderbaar?
• Gebruik je op je server PHP of andere serverside content generation? Zo ja, waarvoor?

[Verwijderd]

Je zou iets als fail2ban kunnen configureren. Deze analyseert log files en blokkeert IP's die rare requests verzenden.

[Zwerver]

Verwijderd schreef op donderdag 01 november 2007 @ 21:53:
Je zou iets als fail2ban kunnen configureren. Deze analyseert log files en blokkeert IP's die rare requests verzenden.

Dat lost zijn probleem weliswaar op maar geeft niet aan wat de oorzaak is Symptoon-bestrijding is in dit geval denk ik niet de beste oplossing

Het lijkt erop dat zijn host/webserver i.d.d. als proxy gebruikt wordt, wat mij dan tot de vraag brengt: waarom

[ Voor 12% gewijzigd door Zwerver op 01-11-2007 22:04 ]

[PierreAronnax]

deadinspace schreef op donderdag 01 november 2007 @ 21:44:
[...]

Wat mij opvalt is dat apache op al die requests (behalve die laatste https connectie) 200, 301, of 302 antwoordt. Dat wil zeggen dat je apache die gerequeste files kent of beweert te kennen. Gezien die uiteenlopende requests lijkt me dat vrij sterk, en vermoed ik dat je apache gebruikt wordt als proxy.

Ik had inderdaad ter experiment op 1 subdomein een proxy draaien. Die heb nu uitgeschakeld. Blijkbaar was de proxy toch niet zo goed geconfigureerd (het was ten slotte een experiment), want nu geeft apache netjes een 404 terug.

Maar dit zal inderdaad de oorzaak zijn geweest. Op de een of andere manier zijn 'ze' er achter gekomen dat er een proxy draaide, en nu is het wachten totdat 'ze' er achter komen dat die weg is.

* PierreAronnax lesson learned

Debian 2.4.27 bestaat niet, dus welke Debian versie draai je dan wel?

Debian 3.1 Sarge met kernel 2.4.27-3-686-smp

Ook interessant:

• Hield je de Debian security updates bij?
• Welke poorten van je server waren/zijn van buitenaf benaderbaar?
• Gebruik je op je server PHP of andere serverside content generation? Zo ja, waarvoor?

• Ik moet eerlijk toegeven dat ik dat al een tijdje niet meer heb gedaan. Meteen maar even gedaan dus.
• Alleen poort 80 een 22.
• Het gaat hier om mijn development server, die draait PHP

Bedankt voor de hulp.

[Verwijderd]

PierreAronnax schreef op vrijdag 02 november 2007 @ 09:00:
[...]
Maar dit zal inderdaad de oorzaak zijn geweest. Op de een of andere manier zijn 'ze' er achter gekomen dat er een proxy draaide, en nu is het wachten totdat 'ze' er achter komen dat die weg is.
[...]

Zodra je op een lijst met open-proxies komt te staan (wat hier waarschijnlijk het geval is, wat is je externe ip adres?) is het vele malen eenvoudiger om een nieuw ip adres te krijgen dan dat het is om van die lijsten af te komen.

[deadinspace]

PierreAronnax schreef op vrijdag 02 november 2007 @ 09:00:
Ik had inderdaad ter experiment op 1 subdomein een proxy draaien. Die heb nu uitgeschakeld. Blijkbaar was de proxy toch niet zo goed geconfigureerd (het was ten slotte een experiment), want nu geeft apache netjes een 404 terug.

Maar dit zal inderdaad de oorzaak zijn geweest. Op de een of andere manier zijn 'ze' er achter gekomen dat er een proxy draaide, en nu is het wachten totdat 'ze' er achter komen dat die weg is.

* PierreAronnax lesson learned

Hehe, altijd goed oppassen met wat je open zet naar de buitenwereld

Debian 3.1 Sarge met kernel 2.4.27-3-686-smp

Ah, ok. Merk op dat Sarge oldstable is, en de security updates daarvoor waarschijnlijk rond april 2008 ophouden. Je wil dus waarschijnlijk ergens een keer naar Etch upgraden.

Ik moet eerlijk toegeven dat ik dat al een tijdje niet meer heb gedaan. Meteen maar even gedaan dus.

Het is wel belangrijk om die goed bij te houden, zeker als je extern toegankelijke services draait.

Ik gebruik daarvoor een klein scriptje dat dagelijks vanuit cron draait en een mailtje stuurt als er nieuwe updates zijn:

code:

#! /bin/sh

# Debian security updates script

TMP=$(mktemp /tmp/upgrade.XXXXXX)

(apt-get -qq update && apt-get -dqq upgrade && apt-get -sqq upgrade) > ${TMP} 2>&1

if [ -s ${TMP} ]; then
        mail -s "$(hostname): New security updates available" root < ${TMP}
fi

rm -f ${TMP}

(Bijvoorbeeld te plaatsen in /etc/cron.daily/local_upgrade. Niet vergeten executable te maken)

Er zijn ook packages beschikbaar, zoals cron-apt of apticron, die iets vergelijkbaars doen.

Het gaat hier om mijn development server, die draait PHP

Omdat je apache als proxy gebruikt werd vermoedde ik in eerste instantie dat je bak misschien gecrackt was, dus ik zocht naar vectors waarlangs dat gebeurd zou kunnen zijn. En onveilige PHP scripts zijn daar zeer populair voor, zeker in combinatie met verouderde frameworks of forumsoftware, vandaar

Verwijderd schreef op vrijdag 02 november 2007 @ 09:33:
Zodra je op een lijst met open-proxies komt te staan (wat hier waarschijnlijk het geval is, wat is je externe ip adres?) is het vele malen eenvoudiger om een nieuw ip adres te krijgen dan dat het is om van die lijsten af te komen.

Aangezien hij een proxy draaide op één subdomein (toch?) is het waarschijnlijk dat ze zijn apache via die hostname benaderen; anders ontbreekt het Host: veld in de HTTP headers, en weet Apache niet voor welk domein de request is.

Als dat het geval is dan is het waarschijnlijk het beste om de DNS records voor dat domein te verwijderen

[PierreAronnax]

Apache bezwijkt niet meer onder de requests, maar ze blijven nog wel steeds binnen komen.

Verwijderd schreef op vrijdag 02 november 2007 @ 09:33:
[...]

Zodra je op een lijst met open-proxies komt te staan (wat hier waarschijnlijk het geval is, wat is je externe ip adres?) is het vele malen eenvoudiger om een nieuw ip adres te krijgen dan dat het is om van die lijsten af te komen.

Helaas heb ik geen dynamisch IP, maar als dit zo doorgaat zal ik contact opnemen met m'n ISP.
Ik plaats liever niet mijn IP hier.

deadinspace schreef op vrijdag 02 november 2007 @ 16:21:
[...]
Aangezien hij een proxy draaide op één subdomein (toch?) is het waarschijnlijk dat ze zijn apache via die hostname benaderen; anders ontbreekt het Host: veld in de HTTP headers, en weet Apache niet voor welk domein de request is.

Als dat het geval is dan is het waarschijnlijk het beste om de DNS records voor dat domein te verwijderen

Dat was deels het probleem: het was door een fout níet op één subdomein. Als ik weet op welk subdomein de verzoeken binnenkomen kan ik inderdaad mijn DNS aanpassen. Het kan echter net zo goed rechtstreeks naar mijn IP gaan (of www.).

Na enige moeite heb ik de volledige headers kunnen achterhalen:

code:

GET http://melaba.antiville.fr/ HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-
excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwav
e-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705
; .NET CLR 1.1.4322)
Host: melaba.antiville.fr
Cookie: X-MV-Referer=; X-Ref-Ok=1
Proxy-Connection: keep-alive

GET http://www.ticketmaster.com/event/1C003EE38263589B HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20
070725 Firefox/2.0.0.6
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Host: www.ticketmaster.com
Proxy-Connection: Close

In de headers komen dus niet mijn eigen domein voor, dus ik heb geen idee naar welk subdomein de requests worden verstuurd.

Is er een (soort van) firewall die ín de headers kijkt, en kan filteren op Host? Op die manier bereikt het apache nooit, en ben ik een stap dichter bij een oplossing.

Momenteel is de access.log van de afgelopen 4 dagen 100MB groot.