Hozzászólások
- Bejegyzés
Bár a ModSecurity hibájára a megoldást nem tudom, azért egy primitív lua scriptet írtam, ami blokkolja a wp-logineket VirtualHost környezetben is. Mivel a neten nem találtam normális megoldást, leírom, hátha hasznos lesz valakinek, akár csak kiindulópontként is.A ModSecurity-ben elhelyezendő kód (elég egy helyen, globálisan elhelyezni):
Code:Ha jól látom, ez a fail2ban a logok alapján tudja eldönteni, melyik kérelem sikertelen, és úgy tud számolni. A WordPress sikertelen belépés sajnos a logban nem hagy egyértelmű nyomot. Csak egy 200-as válasz, míg a sikeres belépés egy 302-es. De a 302 lehet sikertelen belépés eredménye is.
Egy-egy támadási csomag jön egy-egy IP címről. Amúgy váltakoznak az IP címek.A WordPress-be nem én lépek be, így azt nem tudom módosítani.Közben annyit haladtam előre, hogy már tudom reprodukálni a betörést. A trükk az, hogy 1 IP címről felváltva egyszerre 2 külön domain-t kell támadni.A ModSecurity erre azt csinálja, hogy az első kérelemnél az IP cím számlálóját 1-re állítja, majd a második kérelemnél, mivel arra a domainra az az első kérelem, ismét egyre állítja. Ezek után meglepő módon az első domainra érkező új kérelem esetén a számlálót ismét egyre állítja, mivel új kérelem. ...Ha én küldöm két domainra a kérelmeimet, azt sem tudja számolni, bár egy domainre tökéletesen működik 🙁Hát, egyelőre itt állok ... tanácstalan ...
Enyém a szerver, csak azt gondolom, nem script függő a jelenség, tehát egy hibás script sem tudna ilyent csinálni.Igen, ez pedig ugyanúgy jelent meg, mint a hibás symlink, csak ? volt a ! jel helyén.
Mindezzel egyetértek, csak azzal nem, hogy “Ismétlem: nem tudom. Te futtatod a szervert, te tudod, mik futnak rajta.”Az, hogy egy fájlrendszerben mi tud ilyen csinálni, szerintem nem tőlem függ.Nem symlink volt, azt megnéztem. És ha most kellene ilyen fájlt csinálni, nem tudnék. Akkor szűkítsük le a kérdést így:Hogyan állíthatnék elő egy ilyen fájlt?
Igen, értem, de a scriptjeim évek óta futnak, és ez egy mentést végző szerver, tehát nem túl szofisztikáltak. Másrészt ebből az irányból úgysem tudom már kideríteni, mi történt, ezért én a másik oldalról közelítetem meg.Ez egy nagy mentési terület n. almappájában egy fájl volt. Elég minimális a valószínűsége, hogy véletlen eredményeként épp ennek a fájlnak a neve jött volna ki valamelyik scriptben, vagy valami hiba okán.Másodszor: tény, hogy piros volt a fájl az mc-ben, ?-es, és 0 méretű valamint attribútumú. Az immutable flag nem csinál ilyent egy fájllal.Azt is kérdezhetném akkor, hogy milyen tevékenység képes ezt végezni egy fájllal úgy, hogy nincs valós esélye, hogy ezt a fájlt az rsync másolása után bárki is érintette volna?Nekem itt a sok minimális esély közül mégis az ext4 hibája a legvalószínűbb.Főleg úgy, hogy egy ext3 hibát már sikerült átélnem: mikor nagy csindadrattával bevezették az ext3-at, és kifejtették, hogy a naplózás miatt csak a még ki nem írt fájlok és adataik veszhetnek el, akkor egy egészséges áramszünet után úgy omlott össze az egész ext3 fájlrendszerem, ahogy volt. És nem csak néhány fájl sérült meg ... Azóta kissé tartok a tesztelt fájlrendszerektől.
Lehetséges olyan scriptet írni, ami inkonzisztenssé tesz egy fájlrendszert? Ha igen, akkor számomra ez is elég nagy meglepetés. Nálam csak perl és bash scriptek futnak, alap io kezeléssel. Semmi bináris matatás. Főleg nem a mentési területeken.A szinkronizálás közbeni hibát is kisebb valószínűségűnek látom, hisz ha az rsync valamit nem tud lemásolni, akkor gondolom, nem másolja le. Ha jól tudom, másolás közben ideiglenes állományban tárolja az adatokat, és csak a sikeres átérkezés után helyezi el azt a végleges nevén. Ettől persze ez a folyamat is lehet hibás, de hogy az ext4- vagy az rsync-e a teszteltebb, azt nem tudnám megtippelni.
legutóbbi hsz