Kubernetes fail2ban alternativa

 ( kiuka | 2019. január 18., péntek - 22:09 )

Sziasztok,

egy ideje agyalok azon a kerdesen, hogy mikent tudnam a fail2ban altal elvegzett feladatot kubernetesbe atvinni.

Adott egy nginx container, ami lenyegeben egy loadbalancer, ez osztja tovabb a bejovo forgalmat httpd node-oknak. Jelenleg ez egy VS, amin fail2ban parseolja a logot es szur ki klienseket bizonyos tevekenysegekuk alapjan. Ezt szeretnem kubernetesbe rakni.

Jelenleg ket megoldast latok:
- a containeren belul futtatok fail2ban-t es nginxet is, ez szamomra nem igazan illik a konterizalt vilagkepbe, hisz egy container egy alkalmazas kene legyen
- kozberakok egy masik containert, ami hozzafer a logokhoz (az hogy db-bol, vagy egyeb modon mar mindegy), es ez iptables-el tovabbitja a forgalmat az nginxes containerek service-e fele

Ti hogy oldanatok meg, van erre valami best practice?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Első gondolat ami eszembe jutott (nem teszteltem): Sidecar containert definiálsz a POD-ban, amibe belerakod az rsyslogot meg a fail2ban-t. Az nginx-es logokat a "távoli" rsyslog-ba küldöd be (azonos network namespace alatt vannak, nem kell semmit expose-olni), majd itt feldolgozod fail2ban-al.
Ez egyetlen trükk, hogy a sidecar containernek a securityContext-jébe definiálni kell a NET_ADMIN és a NET_RAW capabilities-t, hogy a ban host szinten legyen érvényes (container szinten semmi értelme).
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

+1

ez utóbbiról nem tudtam, köszi hogy felhívtad rá a figyelmem, így már valóban egyszerűbb lesz talán megoldani:) köszi!

"a ban host szinten legyen érvényes" meg ugye az sem teljes koru, mert beeshet a keres egy masik nodera. Nezegettem, es Istio nem tud ilyet. mindenfele dolog alapjan lehet routolni a trafikot. Mondjuk eleg gyanus, hogy a fail2ban kubernetes szavakra a goggle 3dikkent listazza ezt a topicot :) En megneznem Istioval, vagy mas service meshhel ossze lehet-e kotni, mert az egy elosztott megoldas.

-
First impressions of the new Cloud Native programming language Ballerina

Igen, az elosztottságon én is erősen filóztam, de nem jutott eszembe olyan megoldás, amely cluster szinten érvényesítené a beállításokat: A fenti esetben egy host / container logjaira támaszkodnánk, viszont ahogy skálázunk ki egyre több container lesz, és az azokból kinyert adatot sehol sem tudjuk összegezni, hogy azt esetleg cluster szinten tudjuk használni.
Innen is látszik, hogy a fail2ban host szintű feladatokra van kitalálva, nem pedig elosztott rendszerekhez.
Ami alternatíva eszembe jutott az viszont eléggé hákolásnak érződik: egress-nek van ipBlock paramétere, amivel lehet IP-t, vagy komplett CIDR-t tiltani.
Na most ha minden ilyen container 1 központi helyre logolna (sidecar innentől kizárva) és azt a logot etetnénk meg a fail2ban-al, akkor az így kinyert tiltó listával elvileg egyszerűen lehetne megpatchelni az EgressNetworkPolicy-t, ami innentől viszont már cluster szintű tiltást eredményezne..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ilyesmit lehetne igen, de ez eleg sok mernokoles, es az uzembiztossaga is megkerdojelezheto.

-
First impressions of the new Cloud Native programming language Ballerina

Nem véletlenül hívtam én is hákolásnak :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

fail2bannak meg lehet adni sajat action scriptet, ami aztan a tiltando ipt berakja valami db-be (redis, vagy etcd, barmit), a hostokon meg egy masik script ez alapjan hozzaigazitja a iptables tiltasokat. igy a kozponti fail2ban is futhat HA-ban (tobb helyen), nem lesz ugyanaz az ip tobbszor kitiltva.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A jelenlegi "szerencsés" helyzet, hogy nem fogom skálázni, nincs szükség rá, viszont emiatt is gondolkodtam én is olyan megoldásban, ami skálázható, tehát hogy átfolyatni egy másik szolgáltatáson a forgalmat, ami csak továbbküldi a skálázott szolgáltatásnak, ami akár külső forrásban lévő logot is tud elemezni, nem muszáj közvetlen kapja.

Fura amúgy hogy ennyire nincs erre gyakorlat, ennyire ördögtől való a logelemzés alapú tűzfalazás cloud környezetben?

Nem a cloud környezetben, hanem úgy általában: A log alapú elemzéssel több baj is van:
- A logok helyet foglalnak: Ha valaki rájön arra, hogy ilyen van a háttérben sima DDOS-al akkora mennyiségű logot tud generálni, hogy nincs az I/O iszonyat nagy lenne (amit általában nincs értelme fenntartani)
- A log elemzés erőforrás igényes: Még ha az I/O-t tudod is biztosítani a logok számára, azok kiértékelése DDOS helyzetben megint csak költséges: Simán bezabálhat több blade-et / frame-et egy ilyen támadás, úgy hogy azok a gépek közben sokkal hasznosabb dolgokat is csinálhatnának
- A megnövekedett hálózati forgalom így is, úgy is átmegy: Az egész mindenségnek a rákfenéje az, hogy ahhoz, hogy bármiféle intézkedést hozz 1x be kell engednek a hálózatodba a forgalmat (ami már itt erősen sávszél igényes), át kell azt folyatnod az infrádon, bele egy csomó szervered hálókártyájába (ami hálózata is innentől terhelve lesz), majd azokat agyonhajtani csak azért, mert valami hülyegyerek kitalálta, hogy vesz egy fél-egy órás támadást ellened az eggyik DDaaS szolgáltatónál.

Ezért is van az, hogy az ilyen problémákat a komolyabb cégek nem host szinten (OS) tiltják, hanem már a hálózati belépési pontnál be se engedik az adott csomagot (amikor még L2 szinten "olcsón" megfoghatóak), vagy épp átroute-olják valami blackhole-ba, hogy a mögöttes infrát ne terhelje agyon 1-1 ilyen támadás..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Na jó, de te DDOS-ról beszélsz, arra természetesen van szolgáltatói oldalról megoldás és védelem, tehát azzal részemről nem kell szerencsére foglalkozzak (lehetőségem sincs rá, nincs olyan hw és sáv amivel tudnám hárítani).

Amire ezt az egészet használni szeretném, az a botok / scannerek és egyéb elszabadult kliensek kiszűrése, nagyon egyszerű példa: ha valaki elkezdi próbálgatni bruteforce a wordpressen a jelszavakat, akkor én azt nem szeretném hagyni, mert felesleges cpu zabálás. Ezt viszont kizárólag akkor tudom megtenni, ha már beengedtem és látom mit csinál, de ezek jellemzően nem is akarnak floodolni, mert nem érdekük.

Mindenesetre a logolással kapcsolatos részt nem teljesen értem, el tudsz olyan webszervert képzelni, ahol nincs logolás?:)

El, de csak homokozós környezetben, és véletlenül se production-ben (ennyire nem élénk a fantáziám :D ).
Amúgy nem a logolást kifogásoltam, hanem a logolás alapú elemzést DDOS elleni védekezésre.
Normal workload mellett ez persze teljesen más (bár a logok ott is meg tudnak enni egy csomó tárhelyet és I/O-t), de ettől még nem szabad figyelmen kívül hagyni, hogy ez is támadási vektor ami ellen esetenként ugyan úgy védekezni kell, különben az SLA bánhatja.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Igazabol a DOS tamadast is eszre kene venni a szolgaltatonak. Sot azt egyszerubb is detektelni mint a DDOS-t. Es a pw bruteforce az jo esellyel DOS tamadas formajaban erkezik. Maskulonben jo sokaig tart a porgetes. Amugy a konkret tamadast egyszerubben is ki lehet vedeni, pl el lehet tolni a login paget valahova mashova, valamint lehet korlatozni a probalkozasok szamat is. Mindket dologra van plugin.

-
First impressions of the new Cloud Native programming language Ballerina

A Kubernetes alapból tud load Balancing-ot. Én arra felé nézelődnék. Ingress Controller a kulcsszó. Pont azt csinálja,amit az Nginx-es Load Balancer, csak ez be van építve.

Pont nemrég találkoztam vele egy udemy-s videóban.
https://www.udemy.com/learn-devops-the-complete-kubernetes-course/

Section 3, Topics 52-53

A logolásra központi logolást vezetnék be,amihez a fail2ban hozzáfér. Így a fail2ban is mehet konténerbe és szebben is nézne ki megvalósítás szempontjából.
Remélem ezek segítenek.

köszi, ez nem teljesen releváns jelen helyzetben:) az ingress valóban tud loadbalancing, de inkább a kubernetesben lévő skálázott node-ok fele. az nginx teljesen más jellegű szolgáltatásokat tud nyújtani - attól függetlenül hogy amúgy a kubernetesben is egy nginx látja ezt el.

"nem igazan illik a konterizalt vilagkepbe, hisz egy container egy alkalmazas kene legyen" kubernetesen viszont pod-ok vannak. es egy podban lehet tobb kontener is. Van init kontener, lehetnek sidecar containerek. 1.12 Kubernetes ota meg a process namespacet is meg lehet osztani, szoval jo esellyel meg lehet oldani egy sidecar containerrel.

"es ez iptables-el tovabbitja a forgalmat az nginxes containerek service-e fele" nekem nem szimpatikus megkerul a Kubernetest, igy is eleg bonyolult a network.

-
First impressions of the new Cloud Native programming language Ballerina

Az 1. számú best practice, hogy akkora rendszert, amihez k8s illik, nem üzemeltetünk központi loggyűjtés nélkül (mondjuk monitoring nélkül sem, de az itt nem annyira releváns).

Mivel a hálózati belépési pontokon illik szűrni (az pedig véletlenül sem a szolgáltatás konténere lesz), szerintem a fail2ban annyira nem lesz jól használható, vagy legalábbis nagyon sokat kell majd hákolni, hogy a megfelelő pontokon tudja érvényre juttatni a szűrést - igazából össze lehetne dobni valami adatbázisos/git repós mókát is akár.

A központi loggyűjtésre amúgy sem ártana logelemzésre alkalmas komponenst is ültetni (pl. graylog), én biztos, hogy inkább azzal oldanám meg.

Nem mondtam hogy nincs központi logtárolás, van, elasticsearchbe kerül be a log. De azt nem tartanám túl jó megoldásnak ha kubernetes hoston tiltanám azt aki tiltandó.