Fail2ban egy VPN-átjárón: mit old meg és mit nem
A Fail2ban kitiltja azokat a forrásokat, amelyek meghiúsulnak a naplóidban, és ennyi. Hogy segít-e egy VPN-átjárón, a bejelentkezési felülettől és attól függ, ki osztozik egy címen.
Minden kitett szolgáltatás ugyanazt a tanácsot kapja: tedd rá a fail2bant. Egy VPN-átjáró esetében ez a tanács sem nem hibás, sem nem elégséges, és pont az, hogy ezt egy merevítési pipának tekintjük, vezet oda, hogy az emberek egy olyan börtönnel (jail) maradnak, amely semmi hasznosat nem blokkol. A Fail2ban elolvassa azokat a hiba rekordokat, amelyekre rámutatsz, és megkéri egy kényszerítő backendet, hogy tiltsa ki az egyező forrásokat. A teljes értéke attól függ, melyik hitelesítési felület állította elő a rekordot, hogy a benne lévő cím a valódi kliens-e, és hogy mi történik mindenki mással azon cím mögött.
Mi a fail2ban mechanikusan
Egy szűrő naplósorokat párosít, egy börtön forrásonként számolja az egyezéseket, és egy művelet egy tűzfal-backenden keresztül tiltást alkalmaz. Három mozgó alkatrész, és mindegyik önállóan hibás lehet.
Egyik sem nyúl a hitelesítési útvonalhoz: a fail2ban utólag reagál a bizonyítékokra, és soha nem maga ellenőriz egy hitelesítő adatot. A börtön tehát tisztán futhat, miközben a felület, amelyet megnevez, pontosan olyan nyitott marad, mint korábban.
Az alagút figyelője nem bejelentkezési űrlap
Egy OpenVPN-figyelő, amelyet tls-auth vagy tls-crypt véd, eldobja a vezérlőcsatorna-védelem nélküli csomagokat, mielőtt a szokásos TLS-feldolgozás elkezdődik. Egy szkenner, amelynek soha nincs kulcsa, semmit nem állít elő, amit a szűrőd megszámolhatna. A tanúsítványos hitelesítés még egy kaput ad hozzá, mert nincs kitalálható jelszó. A Fail2ban projekt egy általános, naplóvezérelt modellt dokumentál, és egy általános VPN-szűrő nem tesz egy hitelesítetlen csomagot értelmes hibaeseménnyé.
Ha az átjáró csak tanúsítványokat fogad el, előfordulhat, hogy a brute-force történet, amely ellen védekezel, egyáltalán nem létezik azon a porton.
Akkor melyik felületet védelmezed?
Ugyanaz a gazdagép gyakran három különböző dolgot tesz elérhetővé: az alagút figyelőjét, egy ügyfélprofil- vagy önkiszolgáló portált és egy adminisztrációs oldalt. A portálnak és az admin oldalnak jelszóűrlapjai vannak, és olyan naplósorokat állítanak elő, amelyeket egy szűrő meg tud számolni. Az alagút talán csak kézfogási hibákat állít elő, amelyek egészen mást jelentenek. A börtönt a felülethez illeszd, ne a termék nevéhez.
Egy rossz naplót figyelő börtön rosszabb a semminél, mert lefedettség nélkül teremt bizalmat. Irányíts egy bejelentkezési szűrőt az alagút kézfogási hibáira, és a számláló olyan szkennereken fog elsülni, amelyeknek soha nem volt kulcsuk, miközben a portál elleni jelszavas támadás számolatlan marad. Olvasd el a naplósort, amelyet a szűrő párosít, mielőtt megbízol a börtön számában.
A forrás-hozzárendelés a gyenge láncszem
Egy tiltás csak annyit ér, amennyit a célzott cím ér. Amikor a szolgáltatás egy helyi fordított proxy mögött ül, a naplóban szereplő ügyfélcím maga a proxy lehet, és annak kitiltása mindenkit eltávolít. Egy nem megbízható forrásból származó továbbított fejlécben bízni megadja a támadónak a képességet tetszőleges címek kitiltására. UDP-n a forráscímek hamisíthatók, ezért számolásuk nagyobb gondosságot érdemel, mint egy befejezett TCP-bejelentkezés számolása.
Rögzítsd a forrás-hozzárendelés módszerét a börtön README-jében, mert egy nem megbízható ugrásból származó továbbított fejléc fegyverré teszi a tiltást.
A mellékköltség más emberek
Több alkalmazott egy irodai NAT mögött osztozik egy címen, így egyetlen elavult mentett jelszó az egész irodát kizárhatja, amint a küszöbértéket átlépik. A napló egy forrást és egy fiókot mutat, amely meghiúsult, nem egy irodai szintű kiesést.
A rövid tiltások és a mérsékelt küszöbök csökkentik ezt, és egy dokumentált feloldási útvonal csökkenti a támogatási terhelést, amikor mégis megtörténik. A cím durva jelzés, nem identitás, és a jegyet nyitó személy a kiesést fogja leírni, nem a küszöböt.
Mikor vezessük be, és mikor javítsunk valami mást
Akkor vezesd be, ha egy általad ellenőrzött felületen valódi, hozzárendelhető, ismétlődő online bejelentkezési hiba van, és ha a kényszerítő backend valóban lefedi azt a felületet. Javíts valami mást, ha a probléma gyenge hitelesítőadat-politika, internetre kitett kezelőoldal, vagy olyan fiók, amely azért jelentkezik be sikeresen, mert kompromittálták. Egy tiltás egyiket sem tudja helyreállítani, és nem tudja elnyelni az olyan forgalmat, amely már telítette a feltöltési kapcsolatodat. Az utolsó probléma feljebb, a folyás irányában van, valakinél, aki a csomagok hozzád érkezése előtt tud szűrni.
Tartsd minden börtönt egy felülethez kötve, vizsgáld felül a téves riasztásokat, és a kitiltott címek száma helyett a megelőzött hitelesítési munkát mérd.