Apache proxy miatt DDOS alá kerültem. Mi lehet a megoldás?

Fórumok

Rosszul, hiányosan konfigoltuk a Windows-os Apacheunkat (2.4) http_proxy-val: az egyik aldomainre (ceg.exmaple.com) rálógattunk egy háttérszolgáltatást, ami a 40001-es porton lóg, de kívülről az aldomain alatt látszik. Két hete megy is.

Mivel hiányos volt a config (?), a proxy (most már tudjuk) a beérkező fals kéréseket kiszolgálja: ha befut hozzánk egy GET google.com/?query=vacak HTTP/1.1, akkor a szerverünk elmegy a google szerverre, végrehajtja a lekérdezést és visszaadja. Normálisan nem jutna el a szerverünkre a google.com kérés, de hamis (?) DNS-ek által el tud.

A jelenlegi állapot az, hogy a világ különböző gépein megjelenő reklámdobozok (xy.ad.baidu.com, stb.) kérései hozzánk futnak be, ezzel teljesen leterhelve a szerverünket. Nem igazi DDOS, de nekünk az, mert az apache füstöl.

Amiben a segítségeteket kérném:
- Mit tudunk tenni, hogy a sok beérkező kéréstől megszabaduljunk? URI, QueryParams, Referrer alapján való szűrés (HTTP réteg) ugyanúgy megeszi az apache-ot. Jelenleg 301-et küldünk a nem valós kérésekre, de ezt is az apache szűri.
- Mi az indítéka annak (csak hogy tanuljunk ma is valamit), hogy egy másik szerver kérése hozzánk fut be? Miért irányítják át, amikor minket közbeékelve ugyanaz a szerver fogja a kérést kiszolgálni, csak közben elfüstöl a gép?
- Miként lehet a http_proxy-t rendesen használni?

Köszönöm, ha a tapasztalataitokat megosztjátok!

Hozzászólások

"Mivel hiányos volt a config (?)"

Szarul állítottátok be, nincs mese, ezt a békát le kell nyelnetek. Bár a többi fejtegetésből egyértelműen látszik hogy nem hozzáértőek vagytok.

"de hamis (?) DNS-ek által el tud."

Nem biztos, lehet csak szimplán proxy-ként használnak (keress rá google-ban a szervered ip címére)

"Amiben a segítségeteket kérném:
- Mit tudunk tenni, hogy a sok beérkező kéréstől megszabaduljunk? URI, QueryParams, Referrer alapján való szűrés (HTTP réteg) ugyanúgy megeszi az apache-ot. Jelenleg 301-et küldünk a nem valós kérésekre, de ezt is az apache szűri."

Az apache elé egy haproxy, melyben a hostolt domainekre leszűröd a kéréseket, a többit eldobod. Nem tudom hány kérés van / sec, lehet egy nginx is elbírja, viszont egy haproxy-nál strapabíróbb dolgot nehezen találsz.

"- Mi az indítéka annak (csak hogy tanuljunk ma is valamit), hogy egy másik szerver kérése hozzánk fut be? Miért irányítják át, amikor minket közbeékelve ugyanaz a szerver fogja a kérést kiszolgálni, csak közben elfüstöl a gép?"

Semmi indoka nincs azon kívül, hogy egy open proxy-t nyitottál a világnak és használják boldogan. Cserébe nem tudhatod, hogy hány gépet törtek meg a tiéden keresztül, vagy spammelték le a fél világot:) Megfontolnám az IP cím váltás lehetőségét is

"- Miként lehet a http_proxy-t rendesen használni?"

Rendesen beállítod

// Happy debugging, suckers
#define true (rand() > 10)

A "hiányos volt a config" valóban egyenlő a szar beállítással, az infók hiányával. Idealista világot képzelek magam köré :)

Csak proxy-k vagyunk, de ezt is meg kell oldani. Egyelőre NGINX kerül az Apache elé 444-es hibakóddal, meglátjuk mennyire bírja.

Köszönöm a segítséget és az őszinte véleménynyilvánítást is :)

A "hiányos volt a config" valóban egyenlő a szar beállítással, az infók hiányával. Idealista világot képzelek magam köré :)

na az ilyenektol mentse meg az eg a net normalisabb felet. Csak kb. annyira vagy kozveszelyes, mint aki becsukott szemmel hajt a korforgalomba...

--
"Tudom én hogy nem biztonságos, de le van szarva az egész [...] A WoW jelszavam maradjon titokban csak az a lényeg!" (BlinTux)

Köszönöm. Tanultunk is belőle. Nginx-szel megfogjuk a jelenlegi plusz forgalmat, az intézi a proxy-t is a jövőben. Így a CPU-k 1%-on mennek, pedig dől(ne) be a forgalom.

És köszönöm az ekézést is, mert nyomatékosítja a tévedésünket, hibánkat. De ahogy a közmondás is tartja: ha nem hibázol, akkor kevés feladatot raktak rád :)