Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Řešení dotazu:
iptables -L -n iptables -t nat -L -nJinak pokud jsi s linuxem nikdy nepracoval a nejses si jisty co delas, mas dve moznosti. Bud se to naucis, nebo to nabidnes napriklad jako brigadu(ale urcite ne tady..).
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW,ESTABLISHED recent: SET name: SSH side: source LOG tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source LOG flags 0 level 4 prefix "SSH_brute_force" DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 172.17.16.0/20 0.0.0.0/0 state NEW ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/0 172.17.30.10 tcp dpt:5000 Chain OUTPUT (policy ACCEPT) target prot opt source destination
Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8010 to:172.17.18.90:8010 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8100 to:172.17.18.90:8100 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:9200 to:172.17.30.11:9200 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:9000 to:172.17.30.11:9000 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:7500 to:172.17.30.11:7500 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5443 to:172.17.30.5:5443 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5022 to:172.17.30.10:5022 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3390 to:172.17.18.60:3390 Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0
16.12.2014 09:47
pavlix | skóre: 54
| blog: pavlix
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
iptables-save :).
sudo ufw enable (aktivuje firewall),
sudo ufw disable (deaktivuje firewall),
sudo ufw allow a_port_co_potřebuješ (sudo ufw allow 80) (otevře daný port),
sudo ufw deny a_port_co_potřebuješ (sudo ufw deny 80) (zavře daný port),
sudo ufw delete deny a_port_co_potřebuješ (sudo ufw delete deny 80) (zavře daný port a mázne pravidla portu)
31.12.2014 14:50
Migi | skóre: 59
| blog: Mig_Alley
13.12.2014 12:56
multi | skóre: 38
| blog: JaNejsemOdsut
dostal na starosti server Ubuntu 12.04. Bohuzel jsem s linuxem nikdy nepracoval
16.12.2014 09:48
pavlix | skóre: 54
| blog: pavlix
16.12.2014 13:55
Pavel 'TIGER' Růžička | skóre: 53
16.12.2014 23:26
pavlix | skóre: 54
| blog: pavlix
iptables -P INPUT ACCEPT iptables -F INPUT iptables -P OUTPUT ACCEPT iptables -F OUTPUT iptables -P FORWARD ACCEPT iptables -F FORWARD iptables -P PREROUTING ACCEPT iptables -F PREROUTING iptables -P POSTROUTING ACCEPT iptables -F POSTROUTINGPrvní sada příkazů nastaví do výchozí hodnoty pro firewall, druhá pro běžně používané NAT tabulky - tj. smažou všechna pravidla. Znamená to, že server nebude blokovat žádný provoz a nebude nic NATovat. Stejného výsledku dosáhnete, když v
rc.local ty příkazy iptables smažete a server restartujete, navíc se pak už nebude na firewallu nic nastavovat při příštím spuštění.
Všechny ty serverové služby pak budou fungovat, zkontrolujte si ale, že je máte v aktuálních distribučních verzích, a že tam nemáte spuštěné žádné služby, které se nevyužívají.
Firewall se nastavuje jenom tehdy, pokud za ním máte nějaká zařízení nebo služby, které mají nějaké chyby a ochránit je můžete jedině tím, že k nim určitý provoz nepustíte. Případně pokud chcete firewall jako druhou linii obrany, tj. třeba k databázovému serveru nakonfigurujete přístup jen z vnitřní sítě, ale pak ještě pro jistotu zakážete přístup z veku i na firewallu, pro případ, že by třeba někdo chybně změnil konfiguraci toho databázového serveru. Jinak ale firewall není potřeba a neexistuje žádné jeho univerzální nastavení. Pokud už někdo chce nastavit firewall, musí to dělat se znalostí síťování a se znalostí toho, jak vypadá ta konkrétní síť, jak má fungovat a co tam má být povolené a co zakázané. A pak ten firewall také musí průběžně aktualizovat podle toho, jak se mění podmínky v síti.
# Internet a NAT iptables -A FORWARD -i eth0 -o eth1 -s 172.17.18.2/20 -m state --state NEW -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A POSTROUTING -t nat -j MASQUERADE # SSH iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -m recent --set --name SSH -j ACCEPT iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix SSH_brute_force iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP # RDP iptables -t nat -I PREROUTING -p tcp --dport 3390 -j DNAT --to-dest 172.17.18.60:3390 # porty pro novy IS a kamery iptables -A FORWARD -i eth0 -o eth1 -p tcp -d 172.17.30.10 --dport 5000 -j ACCEPT iptables -t nat -I PREROUTING -p tcp --dport 5022 -j DNAT --to-dest 172.17.30.10:5022 iptables -t nat -I PREROUTING -p tcp --dport 5443 -j DNAT --to-dest 172.17.30.5:5443 iptables -t nat -I PREROUTING -p tcp --dport 7500 -j DNAT --to-dest 172.17.30.11:7500 iptables -t nat -I PREROUTING -p tcp --dport 9000 -j DNAT --to-dest 172.17.30.11:9000 iptables -t nat -I PREROUTING -p tcp --dport 9200 -j DNAT --to-dest 172.17.30.11:9200 iptables -t nat -I PREROUTING -p tcp --dport 8100 -j DNAT --to-dest 172.17.18.90:8100 iptables -t nat -I PREROUTING -p tcp --dport 8010 -j DNAT --to-dest 172.17.18.90:8010
16.12.2014 23:28
pavlix | skóre: 54
| blog: pavlix
cela zjevne je to jejich GW do netu, a davat na policy accept, muze leda trotl.Já osobně nechávám policy ACCEPT u všeho, takže díky.
17.12.2014 23:54
pavlix | skóre: 54
| blog: pavlix
17.12.2014 23:50
pavlix | skóre: 54
| blog: pavlix
-j ACCEPT s defaultem na DROP.
-j ACCEPT s defaultem na ACCEPT (jako je ten zděděný "firewall" tazatele).
18.12.2014 11:25
pavlix | skóre: 54
| blog: pavlix
30.12.2014 15:38
pavlix | skóre: 54
| blog: pavlix
A protoze zakazy stejne musis resit, treba jenom trochu jinak povazuju to cele za akademickou diskusi. Tedy spoustu plevelu v diskusi s konkretnim dotazem.Pokud si dobře pamatuju, tak jsi tu akademickou diskuzi začal, takže mně si nestěžuj. Já jsem se předtím pouze vyjádřil k příspěvku, ve kterým byli uživatelé politiky ACCEPT označeni za trotly, to mi snad vyčítat nebudeš.
at naplánovat za pár minut iptables-restore, který obnoví původní stav. Buď úpravy uděláte správně, ověříte je a naplánovanou úlohu zrušíte, nebo se odříznete a původní stav se za chvíli vrátí automaticky. Taková je zkušenost z doby, kdy na levných serverech žádné KVM over IP nebylo a odříznout si SSH znamenalo udělat si výlet do datacentra. (Slyšel jsem také o hardwarovém řešení – v datacentru měl dotyčný dva servery umístěné proti sobě, a když k jednomu z nich ztratil přístup, vysunul na tom druhém šuplík CD mechaniky, který byl přesně proti tlačítku reset.)
Pokud ta služba běží na tom serveru, kam nedostane přístup kvůli tomu samému firewallu, tak jak to udělá?Jaká služba? Na ten server se dostane způsob, který firewall povoluje - z počítače, který na ten server má přístup, protokolem, který má povolen přístup...
Mimochodem útočníkovi to nejspíš moc vadit nebude – na to zařízení nebo protokol se dostane z jiného počítače v síti myslíte vážně? Spravoval jste už někdy nějakou síť? Přišlo vám normální, že vám v ní lezou cizí lidé?To vy jste psal o tom, že správce na něco zapomněl, nějaká komunikace je pak blokována vlastně náhodou (nebo blokována není - inu náhoda) a správce o ní ani neví. Jinak síť jsem spravoval. Připadalo mi normální, že v ní lezou cizí lidé, obyčejně se jim říká uživatelé. Pak tam byli ještě další cizí lidé, kteří nebyli uživatelé, a ti v té síti nelezli. Postavil jsem to na tom, principu, že vím, jak to má v té síti fungovat, a podle toho vše správně nakonfiguruju. Pravda je, že to nebylo tak dobrodružné, jako náhodně blokovat nějaký provoz a doufat, že zrovna to zastaví útočníka - ale zase to fungovalo a se sítí nikdy žádné problémy nebyly.
Jaká služba? Na ten server se dostane způsob, který firewall povoluje - z počítače, který na ten server má přístup, protokolem, který má povolen přístup...Ta, kterou jsem uvedl o úroveň výš. Znovu se tedy ptám, jak se na ten server dostane, když daný protokol není ve firewallu vůbec zmíněn a výchozí politika je DROP?
To vy jste psal o tom, že správce na něco zapomněl, nějaká komunikace je pak blokována vlastně náhodou (nebo blokována není - inu náhoda) a správce o ní ani neví.No rozhodně není náhodou povolena, jako by byla ve vašem případě.
Připadalo mi normální, že v ní lezou cizí lidé, obyčejně se jim říká uživatelé.Uživatelé té sítě nejsou cizí lidé, jsou to lidé, kteří mají přístup k té síti. Cizí lidé jsou ti, kteří ten přístup mít nemají.
Postavil jsem to na tom, principu, že vím, jak to má v té síti fungovat, a podle toho vše správně nakonfiguruju. Pravda je, že to nebylo tak dobrodružné, jako náhodně blokovat nějaký provoz a doufat, že zrovna to zastaví útočníka - ale zase to fungovalo a se sítí nikdy žádné problémy nebyly.Bohužel ne všichni jsou tak dokonalí jako vy, aby si mohli být jisti, že nedělají chyby. A pak se samozřejmě zamýšlejí nad tím, jak zneužití takové chyby udělat složitější. Btw. jste si jist, že tam nelezli, nebo jste na to jen nepřišel?
Znovu se tedy ptám, jak se na ten server dostane, když daný protokol není ve firewallu vůbec zmíněn a výchozí politika je DROP?Jak jsem psal - z jiného počítače nebo jiným protokolem.
No rozhodně není náhodou povolena, jako by byla ve vašem případě.Pokud je náhodou blokována, může stejně tak být náhodou povolena. Rozdíl je jen v tom, že vy bezdůvodně spoléháte na to, že vás ta výchozí politika před něčím zachrání. Nezachrání.
Bohužel ne všichni jsou tak dokonalí jako vy, aby si mohli být jisti, že nedělají chyby. A pak se samozřejmě zamýšlejí nad tím, jak zneužití takové chyby udělat složitější.Já netvrdím, že nedělám chyby. Naopak, snažím se, abych na případné chyby přišel. A snažím se udělat taková opatření, abych případnou díru na jedné úrovni zachytil na jiné úrovni. Což se ale dělá úplně jinak, než náhodnou blokací něčeho.
Btw. jste si jist, že tam nelezli, nebo jste na to jen nepřišel?Jsem si jist. Problém s bezpečností nastal jednou, když si jeden uživatel nainstaloval vira, který se pokoušel rozesílat spoustu e-mailů. Což zastavily a ohlásily limity na poštovním serveru.
Jak jsem psal - z jiného počítače nebo jiným protokolem.Takže uznáváte, že to brání zneužít takovou díru?
Pokud je náhodou blokována, může stejně tak být náhodou povolena. Rozdíl je jen v tom, že vy bezdůvodně spoléháte na to, že vás ta výchozí politika před něčím zachrání. Nezachrání.Nemůže být náhodou povolena, musela by být explicitně povolena. Náhodně povolena může být jen u policy ACCEPT.
Já netvrdím, že nedělám chyby. Naopak, snažím se, abych na případné chyby přišel. A snažím se udělat taková opatření, abych případnou díru na jedné úrovni zachytil na jiné úrovni. Což se ale dělá úplně jinak, než náhodnou blokací něčeho.To by mě zajímalo jak. To, že jsem udělal chybu, si všimnu snadno, protože mi uživatelé nahlásí, že služba nefunguje. To, že jste udělal chybu vy, si všimnete těžko, protože služba funguje přesně podle očekávání. Jen se k ní dostane kdokoliv. Samozřejmě se zabezpečení dělá víceúrovňově. A jedna z těch úrovní (a to poměrně zásadní) je ta, že všechno, co není explicitně povoleno, je zakázáno.
Jsem si jist. Problém s bezpečností nastal jednou, když si jeden uživatel nainstaloval vira, který se pokoušel rozesílat spoustu e-mailů. Což zastavily a ohlásily limity na poštovním serveru.Aha, tak to o vaší znalosti bezpečnosti hodně vypovídá. Nikdy si nemůžete být jist, to, že jste odhalil jen jeden problém, neznamená, že jich tam není dalších sto, o kterých nevíte.
Takže uznáváte, že to brání zneužít takovou díru?Pokud někdo má možnost zneužít takovou díru, neřekl bych, že tomu něco brání.
Nemůže být náhodou povolena, musela by být explicitně povolena. Náhodně povolena může být jen u policy ACCEPT.Názorná ukázka mého tvrzení, že tahle "opatření" pouze vyvolávají ve správci falešný pocit bezpečí. Samozřejmě, že může být náhodou povolena. Například tak, že příslušná komunikace vyhoví jinému pravidlu s cílem
ACCEPT. Nebo tak, že útočník komunikuje s cílovým serverem jinak, než přes tenhle firewall.
To, že jsem udělal chybu, si všimnu snadno, protože mi uživatelé nahlásí, že služba nefunguje.To, že jste udělal chybu, se vůbec nemusí projevit tak, že nějaká služba nefunguje.
To, že jste udělal chybu vy, si všimnete těžko, protože služba funguje přesně podle očekávání.Je síť nekonfiguruju tak, že bych něco náhodně nastavoval tak dlouho, dokud nějaká služba nezačne fungovat. Existují mnohem lepší metody. Třeba mít seznam služeb a nakonfigurovat síť přesně pro tyhle služby. Nebo monitorování provozu.
A jedna z těch úrovní (a to poměrně zásadní) je ta, že všechno, co není explicitně povoleno, je zakázáno.Je to jedna z možností. Ale není zásadní, a pokud ji někdo používá špatně, způsobuje víc problémů než užitku - za prvé vytváří ve správci sítě falešný pocit bezpečí, za druhé skrývá chyby v konfiguraci. Konkrétní příklady jste tu už popsal.
Aha, tak to o vaší znalosti bezpečnosti hodně vypovídá. Nikdy si nemůžete být jist, to, že jste odhalil jen jeden problém, neznamená, že jich tam není dalších sto, o kterých nevíte.Stoprocentně jist si opravdu nemůžu být nikdy. Ale když tu síť znám, monitoruju její provoz, a vše bez problémů několik let funguje, můžu si být docela jist, že se tam nikdo neoprávněně nedostal. Samozřejmě, že by se tam nějaké problémy daly najít, jako všude - je to jen otázka motivace. Já jsem se ale snažil případným problémům předcházet, nebo abych se o těch problémech alespoň co nejdřív dozvěděl. Nespoléhal jsem na to, že všechny problémy odstraní všemocná politika
DROP.
Pokud někdo má možnost zneužít takovou díru, neřekl bych, že tomu něco brání.Pro úplně blbé tedy ještě potřetí: jak můžete zneužít díru, když zapomenete ve firewallu uvést protokol, na kterém naslouchá služba, a výchozí politika není ACCEPT?
Názorná ukázka mého tvrzení, že tahle "opatření" pouze vyvolávají ve správci falešný pocit bezpečí. Samozřejmě, že může být náhodou povolena. Například tak, že příslušná komunikace vyhoví jinému pravidlu s cílem ACCEPT.To jako že když nejsem Jirsák, tak nevím, co jednotlivá pravidla povolují?
Nebo tak, že útočník komunikuje s cílovým serverem jinak, než přes tenhle firewall.Což nemá s nastavením firewallu nic společného.
Je síť nekonfiguruju tak, že bych něco náhodně nastavoval tak dlouho, dokud nějaká služba nezačne fungovat.Ne, vy ji konfigurujete tak, že něco náhodně nastavujete tak dlouho, dokud nějaká služba nepřestane fungovat. (Nedělejte z ostatních blbce.)
Třeba mít seznam služeb a nakonfigurovat síť přesně pro tyhle služby.Opravdu ten seznam služeb obsahuje všechny služby? Opravdu ho budete aktualizovat při každé změně? Budou to tak dělat i všichni ostatní admini? Nebudou ty služby zpřístupňovat přes svoje počítače uživatelé? Osobně tipuju, že máte na konci INPUT a FORWARD chainů DROP pro všechno, co nevyhoví předchozím pravidlům, takže máte totéž jako výchozí politiku DROP, a jenom si tu honíte ego, jak jste super admin, že používáte jako výchozí politku ACCEPT.
Je to jedna z možností. Ale není zásadní, a pokud ji někdo používá špatně, způsobuje víc problémů než užitku - za prvé vytváří ve správci sítě falešný pocit bezpečí, za druhé skrývá chyby v konfiguraci. Konkrétní příklady jste tu už popsal.Je zásadní (konkrétně:
Allow only those activities that you expressly permit). Zjistit díru z monitoringu je pozdě. Navíc ten monitoring na to také nemusí přijít nebo může být přes tu díru ovládnut útočníkem. Popsal jsem tu pouze příklady, kdy problémy (bezpečnostní díry) způsobuje ACCEPT. Chyby v konfiguraci skrývá hlavně politika ACCEPT, to jsem tu ovšem psal také a i zdůvodnil.
Nespoléhal jsem na to, že všechny problémy odstraní všemocná politika DROP.Ne, evidentně jste spoléhal na to, že všechny problémy odstraní všemocný monitoring. (Nedělejte z ostatních blbce.)
Pro úplně blbé tedy ještě potřetí: jak můžete zneužít díru, když zapomenete ve firewallu uvést protokol, na kterém naslouchá služba, a výchozí politika není ACCEPT?Nevím, jestli to úplně blbému pomůže, když mu to napíšu potřetí: například komunikace příslušné služby vyhoví jinému pravidlu firewallu, nebo tím protokolem bude komunikovat jiný počítač v síti (mezi nímž a serverem není firewall), nebo se útočník na server dostane jiným protokolem.
To jako že když nejsem Jirsák, tak nevím, co jednotlivá pravidla povolují?Psal jste, že jste o nějaké komunikaci nevěděl. Když o té komunikaci nevíte, snadno můžete napsat pravidlo, kterému ta komunikace vyhoví, aniž by to byl záměr. Nebo prostě uděláte chybu - když můžete udělat chybu v tom, že o nějaké komunikaci nevíte, můžete udělat chybu i při psaní pravidla.
Ne, vy ji konfigurujete tak, že něco náhodně nastavujete tak dlouho, dokud nějaká služba nepřestane fungovat.Nekonfiguruju.
Nedělejte z ostatních blbce.Nedělám. To vy jste napsal, že spoléháte na to, že nastavením výchozí politiky jste trefil komunikaci, na kterou byste jinak zapomněl, a že když něco nakonfigurujete špatně a máte štěstí, že to uživatelé poznají, tak že vás uživatelé upozorní.
Opravdu ten seznam služeb obsahuje všechny služby? Opravdu ho budete aktualizovat při každé změně? Budou to tak dělat i všichni ostatní admini?Ano, to je základní povinností každého administrátora. Je to jediný způsob, jak zajistit bezpečnou síť - náhodné blokování to opravdu nezajistí.
Nebudou ty služby zpřístupňovat přes svoje počítače uživatelé?Pokud to mají povolené, ať si na svém počítači uživatelé zpřístupňují, co chtějí. V takovém případě jsou uživatelské počítače samozřejmě oddělené od bezpečné části sítě.
Osobně tipuju, že máte na konci INPUT a FORWARD chainů DROP pro všechno, co nevyhoví předchozím pravidlůmNemám.
INPUT nikdy, protože počítač, na kterém firewall běží, mám vždy zabezpečený, tj. běží tam pouze nutné služby a ty jsou aktualizované. Takže není, před čím by tam firewall chránil. Ve FORWARD jsem míval REJECT pro navázání komunikace z venku na stanice s Windows, protože tenkrát byly Windows známé tím, že tam běží spousta zbytečných služeb, které je zbytečně složité správně zlikvidovat. Ale nebyl důvod dávat to jako výchozí politiku, protože v síti byly i jiné počítače, které byly také zabezpečené, takže firewall před nimi by nic neřešil.
Allow only those activities that you expressly permitTo ovšem předpokládá nejprve mít vytvořený ten seznam služeb. Navíc to opravdu není jediná možnost, ve spoustě případů uživatelé mnohem víc ocení, pokud jim dovolíte cokoli, co nepoškozuje ostatní. Třeba v takovém hostingovém centru by uživatelé asi nebyli nadšení, kdyby ve výchozím stavu byl jejich server firewallem úplně odříznutý, a o povolení každé komunikace by museli extra žádat.
Zjistit díru z monitoringu je pozdě.Pořád je to mnohem dřív, než když vy ji nezjistíte nikdy.
Navíc ten monitoring na to také nemusí přijít nebo může být přes tu díru ovládnut útočníkem.Pokud útočník získá možnost měnit nastavení firewallu, může změnit tu vaši zázračnou politiku na
ACCEPT.
psal jsem tu pouze příklady, kdy problémy (bezpečnostní díry) způsobuje ACCEPT.Těch problémů jste popsal přesně 0.
Ne, evidentně jste spoléhal na to, že všechny problémy odstraní všemocný monitoring.Monitoring nikdy žádný problém neodstraní. Nanejvýš na něj může upozornit.
Nevím, jestli to úplně blbému pomůže, když mu to napíšu potřetí: například komunikace příslušné služby vyhoví jinému pravidlu firewallu, nebo tím protokolem bude komunikovat jiný počítač v síti (mezi nímž a serverem není firewall), nebo se útočník na server dostane jiným protokolem.Jakému jinému pravidlu? Buď jsem to pravidlo napsal a chci tam přístup, nebo nenapsal (zapomněl jsem na něj) a pak je tam výchozí DROP. Fakt si myslíte, že získání přístupu ke dvěma počítačům je stejně jednoduché jako získání přístupu k jednomu? Možná ve vaší síti…
Psal jste, že jste o nějaké komunikaci nevěděl. Když o té komunikaci nevíte, snadno můžete napsat pravidlo, kterému ta komunikace vyhoví, aniž by to byl záměr. Nebo prostě uděláte chybu - když můžete udělat chybu v tom, že o nějaké komunikaci nevíte, můžete udělat chybu i při psaní pravidla.Napsat chybné pravidlo je mnohem méně pravděpodobné než nenapsat pravidlo vůbec.
Nekonfiguruju.Chytrému napověz, … Tak tedy trkám: jen jsem parodoval vaše arogantní tvrzení, že firewall nastavuji nějak náhodně.
Nedělám. To vy jste napsal, že spoléháte na to, že nastavením výchozí politiky jste trefil komunikaci, na kterou byste jinak zapomněl, a že když něco nakonfigurujete špatně a máte štěstí, že to uživatelé poznají, tak že vás uživatelé upozorní.Nenapsal. Napsal jsem, že když zapomenu na nějakou službu, tak ta služba nebude fungovat nikomu (díky výchozí politice), čehož si všimnete mnohem snáze (např. že si budou stěžovat uživatelé), než když to funguje všem (to si totiž nikdo stěžovat nebude). Jmenuje se to least privilege principle. Možná jste o tom již slyšel.
Ano, to je základní povinností každého administrátora. Je to jediný způsob, jak zajistit bezpečnou síť - náhodné blokování to opravdu nezajistí.Tak ještě jednou: NEJDE O NÁHODNÉ BLOKOVÁNÍ, ALE O ÚMYSLNÉ BLOKOVÁNÍ! Chyby dělá každý. Typická chyba je, že něco zapomenete uvést. Ve vašem případě je to pak přístupné všem, v mém není. Je to tak jednoduché…
Pokud to mají povolené, ať si na svém počítači uživatelé zpřístupňují, co chtějí. V takovém případě jsou uživatelské počítače samozřejmě oddělené od bezpečné části sítě.Což vám nepomůže, když ta služba nemá být veřejně dostupná a uživatel má k té službě přístup.
INPUT nikdy, protože počítač, na kterém firewall běží, mám vždy zabezpečený, tj. běží tam pouze nutné služby a ty jsou aktualizované. Takže není, před čím by tam firewall chránil.Jak to zaručíte? Instaloval jste někdy aplikace třetích stran? Spravoval jste někdy síť, kde jste nebyl jediný administrátor?
Ve FORWARD jsem míval REJECT pro navázání komunikace z venku na stanice s Windows, protože tenkrát byly Windows známé tím, že tam běží spousta zbytečných služeb, které je zbytečně složité správně zlikvidovat.Aha, takže blokujete problémy, o kterých víte. A co ty problémy, o kterých nevíte?
Ale nebyl důvod dávat to jako výchozí politiku, protože v síti byly i jiné počítače, které byly také zabezpečené, takže firewall před nimi by nic neřešil.Samozřejmě mám firewall jak na bráně, tak na všech počítačích v síti. O multi-level security jste někdy slyšel?
To ovšem předpokládá nejprve mít vytvořený ten seznam služeb.To předpokládá mít vytvořený seznam služeb, které mají být zpřístupněné, ne seznam všech služeb, které v síti běží, jako vyžaduje váš přístup.
Navíc to opravdu není jediná možnost, ve spoustě případů uživatelé mnohem víc ocení, pokud jim dovolíte cokoli, co nepoškozuje ostatní.Ocení to nejen uživatelé, ale i útočníci. Hlavně útočníci, protože většina aplikací už je na least privilege připravena a bude fungovat i ve velmi restriktivní síti.
Třeba v takovém hostingovém centru by uživatelé asi nebyli nadšení, kdyby ve výchozím stavu byl jejich server firewallem úplně odříznutý, a o povolení každé komunikace by museli extra žádat.Pokud se firewall používá (zákazník požádá/zaplatí za HW firewall), tak přesně tak to funguje, zákazník žádá o povolení každé komunikace. Pokud se nepoužívá, tak jaksi nemá smysl se bavit o nějakých pravidlech.
Pořád je to mnohem dřív, než když vy ji nezjistíte nikdy.Samozřejmě monitoring používám také. Nejste jediný!
Pokud útočník získá možnost měnit nastavení firewallu, může změnit tu vaši zázračnou politiku na ACCEPT.A když na to ten monitoring nepřijde? Jak provádíte monitoring, že na nějakém portu nějakého počítače neběží služba, o které nevíte? V mém případě opomenutí způsobí, že je to blokováno před útočníkem i uživatelem. Ve vašem případě, že to není blokováno vůbec. Změnit nastavení služby, ke které se nedostanete, je trochu složitější než měnit nastavení služby, ke které se dostanete, nemyslíte?
Těch problémů jste popsal přesně 0.Tady je včetně zdůvodnění.
Monitoring nikdy žádný problém neodstraní. Nanejvýš na něj může upozornit.Opět to byla jen parodie vašeho arogantního tvrzení, že si snad myslím, že DROP vyřeší všechny problémy.
Jakému jinému pravidlu? Buď jsem to pravidlo napsal a chci tam přístup, nebo nenapsal (zapomněl jsem na něj) a pak je tam výchozí DROP.Nebo jste napsal pravidlo, které dělá něco jiného, než jste si myslel. Nebo jste napsal pravidlo, a neuvědomil jste si, že mu vyhovuje i jiná komunikace, než ta zamýšlená. Kdyby takové případy nenastávaly, tak přece veškerý provoz spadne pod některé z vámi zadaných pravidel, a na politiku nikdy nedojde. Jenže tady celou dobu obhajujete, že ta pravidla přece můžete mít špatně, proto používáte politiku
DROP. Rozdíl je jenom v tom, že vy si dovedete představit jedině takovou chybu, která je ve váš prospěch – tedy že pravidlo bude restriktivnější, než by mělo být, odříznete nějakou službu, uživatelé vás upozorní, vy to opravíte a všechno bude v pořádku. Já si dovedu představit i chybu, která je ve váš neprospěch – pravidlo bude méně restriktivní, než jste si myslel, a vy na to nikdy nepřijdete.
Napsat chybné pravidlo je mnohem méně pravděpodobné než nenapsat pravidlo vůbec.Co tak pozoruji různé dotazy, kde má tazatel desítky nebo stovky pravidel ve firewallu a nerozumí ani jedinému, řekl bych, že je to přesně opačně.
Napsal jsem, že když zapomenu na nějakou službu, tak ta služba nebude fungovat nikomu (díky výchozí politice)To sice píšete pořád dokola, ale stále ještě to není pravda. A ani dalším opakováním z toho pravdu neuděláte. Představte si třeba nějaký webový informační systém nebo administraci, které běží jako virtualhost na webovém serveru. Obojí jsou to pochybné aplikace, takže je nechcete zpřístupňovat do internetu. Firemní web samozřejmě z internetu přístupný má být. Takže jste zapomněl na nějakou službu, uživatelé nic nehlásí, protože se na interní IS i administraci dostanou. A vy jste v klidu, protože máte přece politiku na DROP, takže žádná služba nemůže být zpřístupněna omylem. No, evidentně může.
Tak ještě jednou: NEJDE O NÁHODNÉ BLOKOVÁNÍ, ALE O ÚMYSLNÉ BLOKOVÁNÍ!Můžete přidat třeba deset vykřičníků, a stejně to nebude pravda. Kdyby to bylo úmyslné blokování, budete mít vyjmenováno, co přesně blokujete, a tomu budou odpovídat jednotlivá pravidla. Vy ale neustále píšete o případu, kdy máte pravidla firewallu špatně, takže paket náhodou žádnému pravidlu nevyhoví a propadne až do politiky.
Chyby dělá každý. Typická chyba je, že něco zapomenete uvést. Ve vašem případě je to pak přístupné všem, v mém není. Je to tak jednoduché…Opakovaně jsem popisoval, proč je to ve vašem případě jenom otázka náhody, zda to bude nebo nebude přístupné všem. V tom je právě rozdíl mezi námi. Já vím, že můžu udělat chybu, proto se snažím udělat nějaké opatření, které může té chybě zabránit, odhalit jí nebo to ošetřit na jiné úrovni zabezpečení. Vy nastavíte politiku na DROP a chybně si myslíte, že jste něčemu zabránil. A to je přesně ten problém. Pokud by šlo jen o techniku, je výchozí politika DROP stejně dobrá, jako výchozí politika ACCEPT. Jenže do toho vstupuje lidský faktor a to, že správce má pocit, že pro bezpečnost něco udělal, a na skutečné zabezpečení se pak už vykašle. Je to úplně stejné, jako přesouvání
sshd na jiný port, zákaz přihlašování na roota apod. Samo o sobě nic z toho nezhoršuje bezpečnost, ale zároveň ji o v drtivé většině případů ani nezvyšuje, pouze správce získá mylný pocit, že bezpečnost zvýšil, a nevěnuje se pak skutečným bezpečnostním opatřením.
Jak to zaručíte?Tak, že tam neinstaluju aplikace, které nejsou potřeba. Případně si můžu služby naslouchající v síti vypsat příkazem
netstat.
Instaloval jste někdy aplikace třetích stran?Myslíte třeba linuxové jádro, shell, webový server, databázový server, DNS server? Jistě, instaloval. Přece si nebudu všechen software psát sám. I firewall je aplikace třetí strany.
Spravoval jste někdy síť, kde jste nebyl jediný administrátor?Částečně.
Aha, takže blokujete problémy, o kterých víte. A co ty problémy, o kterých nevíte?Problémy, o kterých nevím, musím nejprve odhalit. Občas někde čtu, jak se někdo pokusil blokovat problémy, o kterých nevěděl – vždy to skončilo tak, že dotyčný vytvořil mnohem větší problém, než před kterým se pokoušel chránit.
Samozřejmě mám firewall jak na bráně, tak na všech počítačích v síti. O multi-level security jste někdy slyšel?To je nazváno podle multi-level marketingu? Tam se také slibují zázraky, ale hlavně nesmíte pátrat po tom, jak to doopravdy funguje. Více vrstev zabezpečení funguje tehdy, pokud jsou ty vrstvy různé. Třeba pokud mám někde zámek na klíč, u následujících dveří bude nutné zadat PIN nebo tam bude čtečka otisků prstů. Dát na druhé dveře stejný zámek na ten samý klíč je k ničemu. A stejné je to s těmi vašimi firewally.
To předpokládá mít vytvořený seznam služeb, které mají být zpřístupněné, ne seznam všech služeb, které v síti běží, jako vyžaduje váš přístup.Jenže když nemáte seznam všech služeb, nikdy nevíte, které služby jsou vlastně přístupné. Protože ta služba může být přístupná i jinými způsoby, než tím jedním, který znáte vy – tj. někdo zvenčí naváže spojení na konkrétní port dané služby.
Samozřejmě monitoring používám také.Jak konkrétně monitorujete pakety, které spadly do politiky DROP?
Jak provádíte monitoring, že na nějakém portu nějakého počítače neběží služba, o které nevíte?Pokud je to počítač, který mám ve správě, pak nejjednodušeji tak, že tam neinstaluju službu, o které bych nevěděl. Případně si můžu vypsat netstatem naslouchající procesy, rc-statusem provozované služby… Pokud je to nějaký blackbox, jako třeba starší verze Windows, u kterého nedokážu rozumn ěovlivnit, jaké služby tam poběží, pak nastavím pravidla firewallu pro ten konkrétní počítač – povolím komunikaci, která má být povolena, a ostatní komunikaci s tím konkrétním počítačem zakážu. Nebudu spoléhat na to, že paket probublá firewallem až nakonec a tam to zachytí politika.
V mém případě opomenutí způsobí, že je to blokováno před útočníkem i uživatelem.Nezpůsobí. Pořád nechápete, že když směřujete útočníka, aby šel vámi zvolenou cestou, útočník vás vůbec nemusí poslechnout a může jít jinudy. „Podívejte, jak mám ty dveře perfektně zabezpečené, jaký je tam bytelný zámek!“ – „Ale vždyť hned vedle máte otevřené okno?!“ – „Aha, tak na ty dveře přidám ještě jeden zámek!!!“
Změnit nastavení služby, ke které se nedostanete, je trochu složitější než měnit nastavení služby, ke které se dostanete, nemyslíte?Můžete na firewallu blokovat přístup na port webového serveru i databázového serveru, takže se na ně útočník nedostane. Když se ale na server přihlásí přes ssh, změní jejich nastavení velice snadno. Když naopak nebude mít přístup přes ssh, ale pouze se jako běžný uživatel dostane ne příslušný web nebo k databázi, nastavení těch služeb nijak nezmění.
Opět to byla jen parodie vašeho arogantního tvrzení, že si snad myslím, že DROP vyřeší všechny problémy.Netvrdím, že si myslíte, že politika DROP vyřeší všechny problémy. Bohužel ale opakovaně ukazujete, že si myslíte, že politika DROP vyřeší problémy, které ve skutečnosti nevyřeší.
Kdyby takové případy nenastávaly, tak přece veškerý provoz spadne pod některé z vámi zadaných pravidel, a na politiku nikdy nedojde.Hovadina. Na politiku dojde vždy, když se nematchne jiné pravidlo.
Rozdíl je jenom v tom, že vy si dovedete představit jedině takovou chybu, která je ve váš prospěch – tedy že pravidlo bude restriktivnější, než by mělo být, odříznete nějakou službu, uživatelé vás upozorní, vy to opravíte a všechno bude v pořádku. Já si dovedu představit i chybu, která je ve váš neprospěch – pravidlo bude méně restriktivní, než jste si myslel, a vy na to nikdy nepřijdete.Já si ji umím představit taky. A co jako? To nic nemění na tom, že taková chyba je mnohem méně pravděpodobná než ta opačná, kdy nějaké pravidlo ZAPOMENU. V bezpečnosti se vždy operuje s pravděpodobnostmi a vždy se snažíte minimalizovat pravděpodobnost chyby.
To sice píšete pořád dokola, ale stále ještě to není pravda. A ani dalším opakováním z toho pravdu neuděláte. Představte si třeba nějaký webový informační systém nebo administraci, které běží jako virtualhost na webovém serveru. Obojí jsou to pochybné aplikace, takže je nechcete zpřístupňovat do internetu. Firemní web samozřejmě z internetu přístupný má být. Takže jste zapomněl na nějakou službu, uživatelé nic nehlásí, protože se na interní IS i administraci dostanou. A vy jste v klidu, protože máte přece politiku na DROP, takže žádná služba nemůže být zpřístupněna omylem. No, evidentně může.PŘESTAŇTE UŽ DĚLAT Z OSTATNÍCH DEBILY! Nikde jsem nepsal, že jsem v klidu a že nemůže být něco zpřístupněné omylem, to si tu jen vymýšlíte, abyste měl vůbec nějaké argumenty. Psal jsem, že je mnohem méně pravděpodobné, že to bude zpřístupněné omylem než že to bude omylem zablokované. Tenhle příklad funguje úplně stejně s ACCEPT, takže když ignoruju ty arogantní narážky, tak jde dodal argument úplně stejně fungující proti vašemu přístupu.
Tak, že tam neinstaluju aplikace, které nejsou potřeba. Případně si můžu služby naslouchající v síti vypsat příkazem netstat.Fakt kontrolujete netstat po každé aktualizaci? Víte o tom, že u mnoha systémů (včetně těch linuxových) se služby spouští už v průběhu instalace, v té době je tedy nemáte zablokované a navíc mají výchozí jména a hesla? Víte o tom, že mnoho útoků je automatizovaných a server s výchozím natavením prolomí za pár sekund? Víte o tom, že následným zablokováním komprimované služby jste situaci nemusel opravit?
Myslíte třeba linuxové jádro, shell, webový server, databázový server, DNS server? Jistě, instaloval. Přece si nebudu všechen software psát sám. I firewall je aplikace třetí strany.Ne, to jsou aplikace druhých stran. Myslím aplikace, které nejsou v balíčkách, často mají mizernou dokumentaci a je otázka, na čem všem naslouchají.
Částečně.Takže vůbec. Je to vidět.
Problémy, o kterých nevím, musím nejprve odhalit.Pokud ho dřív neodhalí někdo jiný.
Občas někde čtu, jak se někdo pokusil blokovat problémy, o kterých nevěděl – vždy to skončilo tak, že dotyčný vytvořil mnohem větší problém, než před kterým se pokoušel chránit.Já zase čtu často lidech, kteří se blokovat problémy, o kterých neví, nepokoušejí. Jsou jich miliony. Jako třeba u rom-0, NAT traversal, veřejně dostupné sdílení souborů, veřejně dostupné web kamery a podobně.
To je nazváno podle multi-level marketingu? Tam se také slibují zázraky, ale hlavně nesmíte pátrat po tom, jak to doopravdy funguje.To má být vtip?
Více vrstev zabezpečení funguje tehdy, pokud jsou ty vrstvy různé. Třeba pokud mám někde zámek na klíč, u následujících dveří bude nutné zadat PIN nebo tam bude čtečka otisků prstů. Dát na druhé dveře stejný zámek na ten samý klíč je k ničemu. A stejné je to s těmi vašimi firewally.Aha, takže pokud máte dveře na klíč a za tím další dveře na jiný klíč, tak to nefunguje? Zajímavý názor… (Ty firewally samozřejmě nejsou totožné a pravděpodobně nebyly nastavovány najednou.)
Jak konkrétně monitorujete pakety, které spadly do politiky DROP?Jako základ stačí
iptables -A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG, pak se to dá prohánět nějakými analyzátory. U mého monitoringu nevadí, pokud něco přehlédnu nebo se to odhalí za týden (prostě to nefunguje). U vašeho je to průser (dostane se tam kdokoliv).
Pokud je to počítač, který mám ve správě, pak nejjednodušeji tak, že tam neinstaluju službu, o které bych nevěděl.To se hezky řekne, ale v praxi to nejde zaručit.
Pokud je to nějaký blackbox, jako třeba starší verze Windows, u kterého nedokážu rozumn ěovlivnit, jaké služby tam poběží, pak nastavím pravidla firewallu pro ten konkrétní počítač – povolím komunikaci, která má být povolena, a ostatní komunikaci s tím konkrétním počítačem zakážu. Nebudu spoléhat na to, že paket probublá firewallem až nakonec a tam to zachytí politika.Jak to nastavíte pro konkrétní počítač? Podle IP adresy? Co když ji změní? Jak to uděláte u sítě, kde máte desítky strojů, které nemáte ve správě?
Nezpůsobí. Pořád nechápete, že když směřujete útočníka, aby šel vámi zvolenou cestou, útočník vás vůbec nemusí poslechnout a může jít jinudy. „Podívejte, jak mám ty dveře perfektně zabezpečené, jaký je tam bytelný zámek!“ – „Ale vždyť hned vedle máte otevřené okno?!“ – „Aha, tak na ty dveře přidám ještě jeden zámek!!!“Chápu, moc dobře chápu, proto se snažím jakékoliv vektory útoku minimalizovat. Ale to nemá nic společného s nastavováním firewallu. A určitě to moc dobře víte. A PŘESTAŇTE ZE MĚ DĚLAT DEBILA!
Můžete na firewallu blokovat přístup na port webového serveru i databázového serveru, takže se na ně útočník nedostane. Když se ale na server přihlásí přes ssh, změní jejich nastavení velice snadno. Když naopak nebude mít přístup přes ssh, ale pouze se jako běžný uživatel dostane ne příslušný web nebo k databázi, nastavení těch služeb nijak nezmění.Jak tedy blokujete služby, o kterých nevíte?
Netvrdím, že si myslíte, že politika DROP vyřeší všechny problémy. Bohužel ale opakovaně ukazujete, že si myslíte, že politika DROP vyřeší problémy, které ve skutečnosti nevyřeší.Ne, to mi vy jen neustále podsouváte a vymýšlíte si absurdní způsoby, kdy to nefunguje.
Na politiku dojde vždy, když se nematchne jiné pravidlo.A máte teda pravidla pro veškerý provoz, nebo to, že nějaká komunikace nevyhoví žádnému pravidlu a propadne až do politiky, je záměr?
taková chyba je mnohem méně pravděpodobná než ta opačná, kdy nějaké pravidlo ZAPOMENUZa prvé, jak jste na něco takového přišel? A za druhé, i kdyby to byla pravda, co z toho plyne?
Nikde jsem nepsal, že jsem v klidu a že nemůže být něco zpřístupněné omylem, to si tu jen vymýšlíte, abyste měl vůbec nějaké argumenty.Explicitně jste to nenapsal, ale neustále to uvádíte na příkladech. Neviděl jsem žádný váš komentář, kde byste napsal, že nastavíte politiku na DROP, což je úplně k ničemu. Naopak neustále uvádíte příklady, kdy by možná politika DROP při určité souhře okolností mohla pomoci. Což znamená, že jste v klidu. Kdybyste nebyl, tak napíšete, které všechny případy to neřeší, jak řešíte ty jiné případy, že tohle jiné řešení vlastně pokrývá i to, čeho se snažíte dosáhnout politikou DROP, a že je tudíž ta politika DROP zbytečná.
Myslím aplikace, které nejsou v balíčkách, často mají mizernou dokumentaci a je otázka, na čem všem naslouchají.Na tuto otázku je velice snadná odpověď, kterou jsem napsal shodou okolností také v komentáři, na který reagujete.
NAT traversalTo je přece úplně stejný způsob uvažování, jako ta vaše DROP politika. "Mám přece počítač za NATem, takže se na něj nějaký útočník z druhého konce světa nemůže dostat." Že na jeho počítač může útočit třeba jiné zařízení ve stejné síti, to dotyčného nenapadne - a vás taky ne. (Tady by se hodila zase nějaká vaše reakce o pravděpodobnosti. Jak je pravděpodobné, že zrovna v mém routeru bude chyba typu rom-0, jak je pravděpodobné, že někdo objeví zrovna mou webkameru - aha, pardon, to byly vaše protipříklady.)
Aha, takže pokud máte dveře na klíč a za tím další dveře na jiný klíč, tak to nefunguje?Těch případů, kdy to zrovna náhodou zafunguje, je nezajímavě málo. Pokud už vám někdo ukradne jeden klíč, nejspíš ukradne i ten druhý. Pokud bude umět otevřít bez klíče první zámek, nejspíš to zvládne i s tím druhým.
Jako základ stačí iptables -A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG
To bude správně fungovat do té doby, než někdo přidá další pravidlo iptables -A INPUT.
To se hezky řekne, ale v praxi to nejde zaručit.To, že vy to neumíte, neznamená, že to nejde. Já to umím.
Jak to nastavíte pro konkrétní počítač? Podle IP adresy? Co když ji změní?Ano, podle IP adresy. Když ji změní, tak nedokáže s nikým komunikovat.
Jak to uděláte u sítě, kde máte desítky strojů, které nemáte ve správě?Oddělím je do samostatné sítě, oddělené od zabezpečené sítě. A pak záleží na tom, jaká bude dohoda s provozovateli těch strojů. Nejlepší samozřejmě je nechat jim plný přístup k síti. Pokud provozovatelé těch strojů řeknou, že ty stroje nejsou bezpečné a není možné je takhle provozovat, bude záležet na tom, jaké budou chtít zabezpečení.
Chápu, moc dobře chápu, proto se snažím jakékoliv vektory útoku minimalizovat.Takže už máte na dveřích čtvrtý zámek, a vedle dveří pořád to otevřené okno. Ono nestačí minimalizovat nějaké náhodně vybrané vektory útoku, nebo ty vektory útoku, proti kterým se vám dobře brání. Když dáte na dveře zámek, nemá smysl tam přidávat druhý zámek do té doby, než všechno okolo budete mít zabezpečené alespoň tak dobře, jako ty dveře se zámkem.
Jak tedy blokujete služby, o kterých nevíte?Stejně jako vy - nijak. Akorát si - na rozdíl od vás - nemyslím, že je blokuju. Takže se logicky snažím docílit toho, aby takové služby neexistovaly.
vymýšlíte si absurdní způsoby, kdy to nefungujeZatímco útočníci spořádaně útočí zásadně jenom těmi způsoby, proti kterým máte obranu. Když nějaký útočník vidí dveře se třemi zámky, tak přece nepoleze vedle otevřeným oknem, to by bylo absurdní, že.
U mého monitoringu nevadí, pokud něco přehlédnu nebo se to odhalí za týden (prostě to nefunguje). ... KDYŽ ZE VŠECH OKOLO DĚLÁ NEUSTÁLE DEBILYNedělám debily ze všech okolo, pouze poukazuju na vaše omyly. Opravdu nemůžu za to, že na nich tak vehementně trváte. Pořád se ohrazujete proti tomu, že tvrdím, že nastavíte politiku DROP a máte pocit, že jste tím něco vyřešil. No a pak sám napíšete "prostě to nefunguje". Tak jak to tedy je? Platí to "prostě to nefunguje"? A je to důsledek politiky DROP?
A máte teda pravidla pro veškerý provoz, nebo to, že nějaká komunikace nevyhoví žádnému pravidlu a propadne až do politiky, je záměr?Je to záměr. Pokud máte pravidlo, které matchne veškerý zbylý provoz (tj. to, co nematchly předchozí pravidla), je to taky politika a jen si hrajete na to, jak jste cool, že vám iptables vypisují policy ACCEPT.
Za prvé, jak jste na něco takového přišel? A za druhé, i kdyby to byla pravda, co z toho plyne?Z praxe. A nejsem sám, lidé od IBM nebo Cisca (
it is a best practice to have an explicit deny statement at the end and log all the denied packets) mají stejné zkušenosti. Plyne z toho to, že je z bezpečnostního hlediska výhodnější least privilege principle, což DROP policy nepochybně je.
Těch případů, kdy to zrovna náhodou zafunguje, je nezajímavě málo. Pokud už vám někdo ukradne jeden klíč, nejspíš ukradne i ten druhý. Pokud bude umět otevřít bez klíče první zámek, nejspíš to zvládne i s tím druhým.Například jen u všech bytových domů. Bydlíte v bytovém domě? Máte na dveřích do bytu zámek, i když je podle vás zbytečný?
To bude správně fungovat do té doby, než někdo přidá další pravidlo iptables -A INPUT.Což nepřidá, protože tam tohle dává nadstavba firewallu, kterou používáme, a ta si ohlídá, že to bude na konci. Ještě jste neodpověděl, jak děláte ten zázračný monitoring, co zastavuje útočníky.
To, že vy to neumíte, neznamená, že to nejde. Já to umím.Bohužel ne všichni jsou tak dokonalí jako vy. My ostatní děláme chyby a opomenutí je nejčastější chyba. (Anebo si jen myslíte, že to umíte.)
Oddělím je do samostatné sítě, oddělené od zabezpečené sítě.To řeší ten problém, že se přes ně dá dostat na službu do zabezpečené sítě, kam mají přístup, jak?
Když nějaký útočník vidí dveře se třemi zámky, tak přece nepoleze vedle otevřeným oknem, to by bylo absurdní, že.Myslíte to děravé Jetty, co máte na serveru? Znovu opakuji, že to nemá s politikou firewallu nic společného, proto o tom nic nepíšu. Firewall samozřejmě není jediné zabezpečení, které používám, tak mi to dokola nepodsouvejte.
Pořád se ohrazujete proti tomu, že tvrdím, že nastavíte politiku DROP a máte pocit, že jste tím něco vyřešil. No a pak sám napíšete "prostě to nefunguje". Tak jak to tedy je? Platí to "prostě to nefunguje"? A je to důsledek politiky DROP?Platí, jen jste to (zase) nepochopil. Prostě to nefunguje = nikdo se na tu službu nedostane. Je to důsledek politiky DROP.
1.1.2015 16:47
pavlix | skóre: 54
| blog: pavlix
Pokud máte pravidlo, které matchne veškerý zbylý provoz (tj. to, co nematchly předchozí pravidla), je to taky politikaA proto se o tom jsou schopni lidé v diskuzi hádat, případně i házet nadávkami. Já osobně jsem tento názor vyjádřil ještě když tady moc příspěvků nebylo, a nemůžu říci, že bych s ním sklidil kdovíjaký úspěch. Mimochodem, když už tady házíme pojmy, politika je především celý ten firewall. Už jen proto považuju volbu toho termínu za nešťastnou a především danou funkcionalitu z důvodu, který jsi právě popsal, považuju za nadbytečnou až matoucí.
lidé od IBM nebo Cisca ("it is a best practice to have an explicit deny statement at the end and log all the denied packets")Vida že v tom nejsem sám :).
A proto se o tom jsou schopni lidé v diskuzi hádat, případně i házet nadávkami. Já osobně jsem tento názor vyjádřil ještě když tady moc příspěvků nebylo, a nemůžu říci, že bych s ním sklidil kdovíjaký úspěch.Tohle jsem taky napsal o několik příspěvků dřív. Jirsák na to odpověděl, že to tak nemá a že to nic nepřináší.
Mimochodem, když už tady házíme pojmy, politika je především celý ten firewall. Už jen proto považuju volbu toho termínu za nešťastnou a především danou funkcionalitu z důvodu, který jsi právě popsal, považuju za nadbytečnou až matoucí.Máte pravdu, ten DROP je výchozí politika (default policy), nějak se to tu v diskusi zkrátilo.
Vida že v tom nejsem sám :).To je tím, že Cisco nemá speciální příkaz pro výchozí politiku.
To je tím, že Cisco nemá speciální příkaz pro výchozí politiku.Oprava: jak jsem zjistil, tak Cisco má implicitní DROP (tj. nemůžete to nastavit, ale má to). Ten explicitní DROP tam doporučují kvůli statistikám, protože u toho implicitního se (na rozdíl od Linuxu) nepočítají.
1.1.2015 17:31
pavlix | skóre: 54
| blog: pavlix
iptables -F v domnění, že tím vypnu firewall a až potom si uvědomím, že jsem měl nejdříve přepnout politiky.
Teoreticky má DROP tu výhodu, že zastaví nevyžádaný provoz a tím zabrání útoku. Jenže pořád zůstává ten argument, že je firewall jen dodatečná bezpečnostní technika, navíc je tu zásadní nevýhoda, že v takovém případě zastaví i legitimní provoz a v případě řetězů INPUT a OUTPUT zastaví i management provoz (například běžící SSH spojení). V posledních letech jsem jen příležitostný admin, ale i tak pro mě pořád platí, že zastavení legitimního provozu je relativně drahé a zablokování vlastního přístupu je ještě řádově dražší. V tomto ohledu je výchozí politika ponechaná na ACCEPT ideální řešení.
Teoreticky bych tedy měl volit DROP v případech, kdy se i pár paketů považuje za riskantní. Jenže to se typicky týká jen výchozí politiky řetězu FORWARD, která je tuplem zbytečná, vzhledem k tomu, že lze vypínání/zapínání forwardingu řešit přesy sysctl. Neumím si představit, že by byl kritický i INPUT, ale i v tom případě bych asi primárně hledal jiné řešení než nastavení výchozí politiky.
Teoreticky má DROP tu výhodu, že zastaví nevyžádaný provoz a tím zabrání útoku.Myslim, ze dnes se to jeste vyplati. Bezpecnosti site po cele delce od ISP az po koncovy server je dost zajimava sama o sobe. Kdysi jsem se naucil jedno pravidlo
ACLs should be placed as close to the source devices as possible. Takze napriklad na koncovem linux serveru firewall jeste delam, ale jen velice trivialni a spoleham na centralni firewall a IDS/IPS reseni. Rozhodne bych nespolehal na to, ze mam monitoring, ktery oznami, ze se nekdo boura do site..Dalsi diskutabilni vec je spoluprace na strane ISP/tranzitu ve veci rekneme DDoS a vetsich utoku.
2.1.2015 09:00
pavlix | skóre: 54
| blog: pavlix
31.12.2014 09:08
pavlix | skóre: 54
| blog: pavlix
Pro úplně blbé tedy ještě potřetíOd blbých pro blbé? :)
1.1.2015 14:10
pavlix | skóre: 54
| blog: pavlix
-A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTZlikviduje vadny pakety, povoli loopback, povoli odpoved na tebou zahajeny provoz.
-A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTdtto, loopack se neforwarduje V kazdym pripade bys pak mel pridat neco jako
-A FORWARD -s 172.17.16.0/20 -i eth0 -j DROP -A FORWARD -d 172.17.16.0/20 -i eth0 -j DROPPri tom, ze eth0 vede do netu, zabranis tim utoku na interni sit, z(do) netu by nemely prijit privatni adresy. Muzes samo pridat i dalsi rozsahy.
-A FORWARD -s 172.17.16.0/20 -j do_netu -A do_netu -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPTMala ukazka jak (pro policy drop) povolit pristup na web z daneho rozsahu - poslem si to do extra supliku, aby to nebyl bordel, a pak budem povolovat. Velmi podobne muzes povolit sluzby, bezici primo na tom stroji (mail ...) jen to pises do inputu. Podobne povolis tomu stroji komunikovat ven (trebas kvuli mailu) jen do output Bacha, NA PORADI ZALEZI a to naprosto zasadne !!! Pokud nevis co delas, nekoho si na to najmi! Tohle sou jen hinty aby sis udelal predstavu. Mam tu trebas firewall, kterej ma 500+ radku jen pro Ipv4 a dalsich 200+ pro Ipv6.
Host is up (0.016s latency). Not shown: 65519 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 110/tcp open pop3 143/tcp open imap 993/tcp open imaps 995/tcp open pop3s 3390/tcp open dsc 5022/tcp open unknown 5443/tcp open unknown 7500/tcp open silhouette 8010/tcp open xmpp 8100/tcp open xprint-server 9000/tcp open cslistener 9200/tcp open wap-wsp Nmap done: 1 IP address (1 host up) scanned in 35.51 s
Tiskni
Sdílej:
