Brute-Force támadás? - MuieBlackCat

Szerintem baromi óvatosan kell erre a miaumacskára (és általában hasonlókra) keresni!!!

IMO:

1. A Google serp-en mielőtt rákattintasz valamelyik találatra, győződj meg róla, hogy jóhiszemű felhasználók által létrehozott fórum beszélgetésről van szó (amely ezt a témát taglalja) → ez eszköze lehet a tájékozódásodnak az ügyben.
2. De ha a Google-val "nagy ügyesen" megtalálsz "meghekkelt" helyeket, (a miaumacska támadással ugyanilyen nevű könyvtárak és page titlek jönnek létre ("muieblackcat")) akkor kifejezetten kiteszed a gépedet fölösleges kockázatnak. Szóval jobb okosan élni.
3. Ezt írja egy olyan ember, aki sajnos nekilátott felderíteni a helyzetet, és a végén mindenféle nagyon érdekes események hatása alatt a "poorman's firewall" alkalmazásánál kötött ki (hálózati kábel kiránt a desktopból (konnektor kapcsolójával áramtalanítottam a gépet), de izibe)

Persze, nem értek hozzá, valószínűleg ez nem ilyen módon terjed, mit szövegelek már megint, de akkor is, nem kell a baj (a hálózati tápot akkor szakítottam meg, amikor egy ilyen fertőzött webhely (macskás) megnyitásakor valamilyen antivírus szolgáltatás (az-e valóban?) tájékoztatott, hogy akkor egy biztonsági scanra lesz szükségem a gépen egy meginduló státusjelző társaságában, erre a Chrome dobott valami figyelmeztetést hogy ártó szándékú valami is lehet valahol, konnektor áramtalanít!)

For your information.

-------

Annyit tudtam meg, hogy azért keres a robot a meuimacskára, mert előtte már elvileg járt ott (a haverja?) aki létrehozott egy ilyen könyvtárat. Ha találni ilyet, az annak az indikátora, hogy az adott webhelynek megvan a sebezhető pontja, lehet, hogy ehhez van kötve egy második lépcső a támadásban...

Persze, csak ha helyesen értelmezem (amire nincs garancia) :)

Olyan fórumot még nem találtam, ahol nekünk Drupalosoknak megfelelő megközelítést taglaltak volna.

Részemről engem megnyugtatna egy olyan megoldás kísérlet - mondjuk akár Drupal modul - ami vizsgálná az azonos ip-címek számára egyhuzamban visszaadott 404-eket (időintervallumon belül?), és kb. a 10.-nél aszondaná, hogy akkor barátom ez CAPTCHA lesz, és ha háromból az se jön össze, akkor ip block automatában...

(CAPTCHA azért kéne, mert hátha mégis én vagyok, csak részeg, és akkor utána mehetnék az internetkaféba, hogy egy másik ip címről belépve reszetelhessem ezt a modult (hogy otthonról is megint beengedjen), szóval a saját hozzáférésem védelmében kéne azért a CAPTCHA)

Ezután már csak arra kéne kitalálni valamit, hogy a Google meg Yahoo robotjai azért továbbra is próbálkozhassanak potyára is :)

(bár nekem - kicsi webhellyel - a Google biztos nem tud 10db 404-est egyhuzamban előcsalni, mert közben biztos talál olyan URL-t is ami 200 OK; de "tartalmasabb" webhelyek esetén, ha sok tartalom egyszerre vissza van vonva, akkor nem tudom mi történne)

A rendszeresen frissített és karbantartott Drupal oldalakkal nincs gond. Mondom ezt úgy, hogy több olyan oldallal is volt dolgom mostanság, ami Drupal 4.6 vagy 4.7 alatt működött, hibátlanul. A dolog titka annyi volt nekik, hogy letiltották a regisztrációt. :)
Itt jön a lényeg, az egyik legfontosabb védelmi vonal! Mert beszéltek szerverről, tárhelyről, de nem említitek a jogosultságokat! Mit tud egy bejelentkezés nélkül felhasználó elérni, megtenni az oldalon? És abból biztosan minden kell neki? Különösen igaz ez olyan pontokon, ahol adatbevitel van: tartalmak, hozzászólások, keresés, kapcsolat űrlap, stb.
A regisztrációt védi valami? A Mollom nagyon sokat segít, de amúgy is elég sok CAPTCHA megoldás érhető a Drupalhoz.
A szükséges hozzáférések megfontolása után érdemes végigmenni a jogosultság-oldalon és megvonni az egyes szerepköröktől (különös tekintettel a bejelentkezés nélküli látogatókra) azokat a jogosultságokat, amelyek nem szükségesek a tevékenységükhöz. Új modul bekapcsolásakor pedig megnézni, hogy milyen új jogosultásokat hozott a rendszerbe és azokról is dönteni. Ajánlatos követni a "whitelist" elvet, vagyis alapértelmezetten mindent tiltunk, és csak a szükséges szerepkörnek engedélyezzük a kívánt jogosultságot, lehetőleg minél szűkebben értelmezve.
Következő kör a modulok: Milyen modulok vannak használatban az oldalon? És azokból minden kell? Pl. ha fent már a Views, akkor azzal és egy kis kattintgatással nem lehet kiváltani valamit? Ha egy modult fejlesztésnél használunk, biztosan kell az az éles oldalra is? Találkoztam már éles oldalon bekapcsolva felejtett Devel modullal és főoldalra kitett PHP beviteli formmal is… Modulválasztásnál érdemes megnézni, hogy mikor volt az utolsó kommit a modulban, hány oldalon használják és milyen státusz van megjelölve, mennyi hibajegy van hozzá, abból mennyi a nyitott. Ebből fel tudod mérni, hogy mennyire „él” az adott fejlesztés és aszerint alapozhatsz rá.
Érdemes lehet megfontolni biztonsági modulok pl. Sentry Client használatát is.

Aztán ott van az a rész, ami a Drupalon túl mutat: nyilvánosan elérhető phpMyAdmin, Total Commanderbe elmentett FTP-jelszó, stb. Ezeket a támadási kísérleteket botok végzik, jól felparaméterezve. Sok sebezhetőség a phpMyAdminra épít, ezért a Drupaltól független külső szolgáltatásokat érdemes alaposan megszűrni, elpakolni az alapértelmezett útvonalról és levédeni htpasswd-vel.