Dotaz: Firewall a přesměrování

[camel1cz]

Zdravím místní guru a poprosím o radu s konfigurací.

Provozuji emailové a HTTP/HTTPS služby na platformě proxmox a chráním je před zneužitím následujícím způsobem:

• na všech serverech funguje detekování pokusů o pw cracking a všelijaké přetěžování,
• IP, která poruší pravidla se dostane na nějaký čas do IPsetu blacklist,
• všechny virtuály jsou nastavené tak, že provoz z blacklistovaného IPsetu ignorují (DROP),

Tohle funguje vcelku dobře, ale problém nastává, když se do blacklistu dostane IP za kterou jsou řádní uživatelé. Ti pak netuší co se děje, pro ně jsou služby mrtvé. Volají pak pro podporu a špatně se zjišťuje, že to je tento problém - musíme zjistit klientskou IP a kontrolovat ji v blacklistu.

---

Má otázka je, jak toto nejlépe řešit?

Nechci řešit blokování na aplikační úrovni, protože je to komplikované na správu, výkonově drahé a méně spolehlivé.

Byl bych rád, kdyby alespoň na HTTP požadavky systém odpovídal a odesílal jednoduchou informaci a kontakty. Tady je problém s HTTPS, které někdy browser podsouvá a i uživatelé jsou zvyklí jej na webmailu používat.

---

Co mě napadlo: umím si představit, že bych na serveru s webmailem nezakazoval firewallem 80 a 443 a přístup řešil na aplikační úrovni. Ten server by pak mohl sloužit jako informační pro všechny služby. Nicméně nadávek kvůli špatné doméně z HTTPS bych se asi těžko zbavoval a správně by to fungovalo jen na webmailu. Ale je to největší část požadavků na podporu, tak i to je fajn.

Aby to nebylo tak jednoduché, tak proxmox neumí ve firewallu nic jiného než IN/OUT pravidla. Ta post/pre pravidla na která to míří by se mu musela nějak podstrčit a navíc si ani nejsem jistý, jak přesně se to dělá a nerad bych to rozbil.

---

Co si o tom myslíte? Poradíte někdo? Moc děkuji!

Odpovědi

[Pavel 'TIGER' Růžička]

Nezjednodušilo by celou situaci dvoufaktorové ověření?

[camel1cz]

Nejsem si přesně jistý jak to myslíš - jedině snad, že by se uživatel mohl sám odblokovat. To je super, ale je to krok 2 :)

Teď řeším, jak se uživatel vůbec dozví, že je zablokovanej a není to problém s internetem, dostupností serveru atd.

[Pavel 'TIGER' Růžička]

Tady je otázkou, jestli není špatně, že je uživatel vůbec zablokován. Proto jsem psal o dvoufázovém přihlášení. Jakmile druhá fáze ověří uživatele, tak je jasné, že ho nemá blokovat, ale přihlásit.

[camel1cz]

Aha, chápu... no o ten problém úspěšného přihlášení na cizí/ukradený účet jde jen okrajově. Vlastně se to neděje a je to hlídané jinak.

Co se děje a co se snažím řešit tím firewallem je přetěžování služeb a konzumace systémových prostředků. Např. teď je server výkonově na cca. 30%, ale bez těchto opatření jen těžko stíhal. Navíc se docela pravidelně několikrát v týdnu někdo začal organizovaný útok několika až několika desítek IP a to pak server jde do kytek a na odpověď se skoro nedá dočkat.

Příjde mi, že zablokování na úrovni FW v tomto případě je jediné účinné řešení.

[MP]

2FA je v tomto kontextu spatne pouzitelne, pokud se blokuje na urovni ip adresy.

Reseni je nasadit ipv6.

A pro uzivatele za natem na ipv4 - pro ne neni jednoduche a levne reseni. Maximalne to muzete usnadnit supportu tim, ze bude mit viditelne blokace k dispozici na jednom miste.

Anebo prestante blokovat podle ip adres.

[camel1cz]

Ach ta věčná IPv6 :)

Ale možná sem se vyjádřil blbě a nasměroval vás mimo jádro problému. Jde mi o to, že potřebuju účinně odstínit "škodiče" od serveru (a jiné než firewall řešení mě nenapadá) a zároveň blokované informovat co se děje a proč "to nejde".

Proto mě napadl nějaký přepis paketů na úrovni firewallu, který by přesměroval požadavky na jeden server, který by byl na to připravený, kontrolovatl blacklisty na aplikační úrovni a informoval uživatele.

Nevím no.

[Bugsa]

No jasně, ale proč to blokuje i legitimní uživatele? Nemáš ta pravidla moc přísná?

[camel1cz]

No dokud tam ta ochrana bude, tak do ní budou padat i legitimní uživatelé - ať už svou vinou nebo kvůli sdílené IP.

Myslím, že polevit tak, aby se to nestávalo je už hodně blízko tomu, to rovnou vypnout.

[Max]

A důvod, proč tam padají, je jaký? Používáš třeba fail2ban, analyzuješ logy a když vidíš opětovné neúspěšné přihlášení, tak dáš ban do iptables? Pokud máš třeba jen uživatele z CZ a SK, možná by jsi mohl vytvořit geograficky oddělená pravidla. Přísná aplikovat na uživatele z ciziny, mírnější na uživatele z CZ/SK.
Každopádně jakmile do firewallu padají regulérní uživatelé, je to špatně, k takové věci by nemělo vůbec docházet, obzvláště né za regulérního provozu.
Zdar Max

[camel1cz]

Jojo, je to model fail2ban... každá služba má pravidla pro detekci úkonů, které jsou závadné a při opakování se IP vkládá do blacklistu na 10 minut až 48 hodin.

Nikdo koukám nevzal za svůj ten nápad s driblováním s pakety HTTP, tak vás poslechnu a zkusím lépe zacílit blokování. Služby poskytujeme převážně vnitrostátně, takže ta detekce státu je docela dobrý nápad a IP z ČR/SR je dobrý důvod, proč být výrazně benevolentnější.

Díky!

[Jendа]

No dokud tam ta ochrana bude, tak do ní budou padat i legitimní uživatelé - ať už svou vinou

Tak to máš asi ty limity dost nesmyslně nízké.

nebo kvůli sdílené IP

To je za stejnou adresou současně botnet, který zrovna tebe bruteforcuje? To je podle mě extrémně nepravděpodobné. Kolik adres takhle blokuješ?

[Jendа]

problém nastává, když se do blacklistu dostane IP za kterou jsou řádní uživatelé

A jak se to stane?

[camel1cz]

Pochopil jsem tu radu a i ji akceptoval... jak se to děje? Poměrně běžně někdo zkouší hesla z českých IP, poměrně běžně uživatel nastaví špatný heslo a nechá ho v klientovy, který to zkouší a vyčerpá počet špatných přihlášení, méně často, ale pořád dost je více lidí za stejnou IP a chyby se sčítají... a poměrně často naopak botnet nebo podobná potvora zkouší hesla tak, že nepřekračuje "normální" limity per IP, ale v součtu zúčastněných strojů je to nepříjemné.

Jak říkám - měl jsem nápad jaký jsem měl a teď teda implementuji to co jsem napsal - uvidíme. Akorát je tu stále to tiché zakazování, buť bude méně pravděpodobné, že do toho někdo spadne. Já chtěl řešit primárně to ticho a ladění pravidel až jako druhý sled, protože ta informace by řešila 100% případů (každý se podívá na webmail, když mu blbne klient a tam si přečte, co se stalo a snadno se to řeší na podpoře).