abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 12:33 | Nová verze

Byla vydána nová stabilní verze 1.8 (1.8.770.50) webového prohlížeče Vivaldi (Wikipedie). Z novinek vývojáři zdůrazňují vylepšenou historii prohlížení. Ukázka na YouTube. Chromium bylo aktualizováno na verzi 57.0.2987.111.

Ladislav Hagara | Komentářů: 0
dnes 05:55 | Zajímavý projekt

Google na svém blogu věnovaném open source představil portál Google Open Source informující mimo jiné o více než 2000 open source projektech vyvíjených nebo používaných v Googlu.

Ladislav Hagara | Komentářů: 0
dnes 03:33 | IT novinky

Pro společnost Red Hat skončil 28. února fiskální rok 2017. Dle finančních výsledků bylo čtvrté čtvrtletí, stejně jako celý fiskální rok 2017, opět úspěšné. Tržby jsou zvyšovány již 60 čtvrtletí v řadě. Za čtvrté čtvrtletí 2017 to bylo 629 milionů dolarů, tj. meziroční nárůst 16 %. Tržby za celý fiskální rok činily 2,4 miliardy dolarů, tj. meziroční nárůst 18 %.

Ladislav Hagara | Komentářů: 2
včera 18:22 | Bezpečnostní upozornění

V balíčku eject, příkaz pro vysunutí CD/DVD z mechaniky, v linuxových distribucích Ubuntu (USN-3246-1) a Debian (#858872) byla nalezena bezpečnostní chyba CVE-2017-6964 zneužitelná k lokální eskalaci práv. Linuxové distribuce používající eject z balíčku util-linux nejsou zranitelné.

Ladislav Hagara | Komentářů: 14
včera 05:55 | Komunita

Dries Buytaert, autor a vedoucí projektu Drupal a prezident Drupal Association, požádal soukromě před několika týdny Larryho Garfielda, jednoho z klíčových vývojářů Drupalu, aby projekt Drupal opustil. Larry Garfield minulý týden na svých stránkách napsal, že důvodem jsou jeho BDSM praktiky a rozpoutal tím bouřlivou diskusi. Na druhý den reagoval Dries Buytaert i Drupal Association. Pokračuje Larry Garfield [reddit].

Ladislav Hagara | Komentářů: 50
včera 04:44 | Humor

Společnost SAS zveřejnila na svých stránkách studii s názvem Open Source vs Proprietary: What organisations need to know (pdf). Organizace by měly například vědět, že ideální je mix 40 % open source softwaru a 60 % proprietárního softwaru [Slashdot].

Ladislav Hagara | Komentářů: 12
27.3. 23:33 | Zajímavý software

Byl vydán ShellCheck ve verzi 0.4.6. Jedná se o nástroj pro statickou analýzu shellových skriptů. Shellové skripty lze analyzovat na webové stránce ShellChecku, v terminálu nebo přímo z textových editorů. Příklady kódů, na které analýza upozorňuje a doporučuje je přepsat. ShellCheck je naprogramován v programovacím jazyce Haskell. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GPLv3.

Ladislav Hagara | Komentářů: 0
27.3. 23:33 | Pozvánky

Czech JBoss User Group zve na setkání JBUG v Brně, které se koná ve středu 5. dubna 2017 v prostorách Fakulty informatiky Masarykovy univerzity v místnosti A318 od 18:00. Přednáší Pavol Loffay na téma Distributed Tracing and OpenTracing in Microservice Architecture.

… více »
mjedlick | Komentářů: 0
27.3. 11:33 | Zajímavý článek

Národní centrum kybernetické bezpečnosti (NCKB) vypracovalo (pdf) 26 podrobných bezpečnostních doporučení pro síťové správce. Tato doporučení jsou nastavena tak, aby je bylo možné aplikovat v každé instituci. Jsou rozdělena na tři základní části: bezpečnost infrastruktury, bezpečnost stanic a serverů a bezpečnost uživatelů.

Ladislav Hagara | Komentářů: 17
27.3. 05:55 | Komunita

Prezident Nadace pro svobodný software (FSF) Richard M. Stallman vyhlásil na slavnostním ceremoniálu v rámci konference LibrePlanet 2017 vítěze Free Software Awards za rok 2016. Ocenění za společenský přínos získal SecureDrop (Wikipedie). Za rozvoj svobodného softwaru byl oceněn Alexandre Oliva (Wikipedie).

Ladislav Hagara | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (14%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 959 hlasů
 Komentářů: 72, poslední 1.3. 11:16
    Rozcestník

    Dotaz: Zdokonalenie firewallu proti svinstvu

    22.11.2013 07:24 Peter
    Zdokonalenie firewallu proti svinstvu
    Přečteno: 594×
    Dobrý deň vám prajem.

    Firewall mám nakonfigurovaný tak, že policy je drop a povoľujem len to čo vážne potrebujem - to je samozrejme základ. Okrem toho zahadzujem komunikáciu ktorá nemá čo robiť na tom ktorom rozhraní: napríklad privátne adresy nemajú čo hľadať na rozhraní, ktoré ide do netu, ... Ďalej pomocou modulu recent blokujem jednoduche DOS na SSH a DNS:
    iptables --table filter --new-chain SECURE_SSH
    iptables --table filter --append SECURE_SSH --match recent --set --name SECURE_SSH_RECENT
    iptables --table filter --append SECURE_SSH --match recent --update --name SECURE_SSH_RECENT --hitcount 10 --seconds 60 --jump DROP
    iptables --table filter --append SECURE_SSH --jump ACCEPT
    iptables --table filter --append INPUT --match state --state NEW --protocol TCP --match multiport --destination-port 22 --jump SECURE_SSH
    
    A to je asi tak všetko čo mám - čomu rozumiem. Chcem sa ale opýtať, že aké su ešte možné techniky škodenia a ako im zabrániť na firewalle? Napríklad na nete som našiel takéto niečo:
    iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE --jump DROP
    iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG --jump DROP
    iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG --jump DROP
    iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN FIN,SYN --jump DROP
    iptables --table filter --append INPUT --protocol TCP --tcp-flags SYN,RST SYN,RST --jump DROP
    iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,RST FIN,RST --jump DROP
    iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,ACK FIN --jump DROP
    iptables --table filter --append INPUT --protocol TCP --tcp-flags PSH,ACK PSH --jump DROP
    iptables --table filter --append INPUT --protocol TCP --tcp-flags ACK,URG URG --jump DROP
    
    O čo tu presne ide? Na rôznych stránkach som našiel rôzne varianty takéhoto kódu, niektoré to boli príklady na 4 riadky, niektoré na 6 a tento 9 riadkový príklad je najdlhší aký som našiel. Ďalej som našiel takého niečo:
    iptables --table filter --new-chain SYN_FLOOD
    iptables --table filter --append SYN_FLOOD --match limit --limit 1/s --limit-burst 3 --jump RETURN
    iptables --table filter --append SYN_FLOOD --jump DROP
    iptables --table filter --append INPUT --protocol TCP --syn --jump SYN_FLOOD
    
    Tomuto rozumiem čo robí, len ten limit je nastavený správne?

    Aké sú ďalšie techniky na obranu proti svinstvu z netu?

    Vopred vám veľmi pekne ďakujem za odpovede.

    Odpovědi

    22.11.2013 08:34 j
    Rozbalit Rozbalit vše Re: Zdokonalenie firewallu proti svinstvu
    Jde o ruzny kombinace priznaku, kterema se utocnici obcas snazi vyvolat nejakou znamou/neznamou chybu, a ve standardni provozu se takovy kombinace nevyskytujou nebo jen extremne vzacne.
    22.11.2013 13:12 Peter
    Rozbalit Rozbalit vše Re: Zdokonalenie firewallu proti svinstvu
    To som zhruba pochopil, ale prečo na jednej stránke uvádzajú len niečo, na inej zasa niečo iné a na ďalšej zasa dokopy čo na predošlých dvoch. Proste aké su všetky možnosti? A po ďalšie ma hlavne zaujímaly skúsenosti odborníkov, že čo všetko treba (okrem toho klasického filtrovania) blokovať.
    23.11.2013 09:25 j
    Rozbalit Rozbalit vše Re: Zdokonalenie firewallu proti svinstvu
    Protoze co admin to jinej nazor na to, co by potencielne mohlo byt nebezpecny. Ber to tak, ze takovej provoz sam o sobe neni nic proti nicemu, proste to jsou nejaky bity v hlavickach paketu - tedy naprosto nezajimavy a resit to nemusis vubec. Ale protoze ve vsech vecech jsou chyby, a je znamo, ze nektere veci na to reaguji, tak to nekteri projistotu blokuji.
    22.11.2013 16:50 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Zdokonalenie firewallu proti svinstvu
    napríklad privátne adresy nemajú čo hľadať na rozhraní, ktoré ide do netu

    To neplatí obecně. IPSec je jedna z důležitých výjimek.

    (Ať tak nebo tak, IPv4 se svými „privátními“ adresami je něco jako mor, protože kvůli němu přestal fungovat Internet „tak, jak měl“ a zvítězily pak pochybné technologie typu Skype, které celý uměle vytvořený problém „řeší“.)

    Základní technika obrany proti svinstvu z netu (na které všechno ostatní stojí) je aktuální kernel. Pokud jde o ip{,6}tables, filtrovat se dá téměř všechno, ale v každém případě by mělo být povolené ICMP{v4,v6}. Dají se nastavit omezení na frekvenci a typ zpráv, ale bez ICMP může docházet ke spoustě ošklivých jevů jak pro klienty serveru ve vnějším Internetu, tak pro stroje ve vnitřní síti, pro které server třeba slouží jako router. Jde zejména o MTU. Když je někde po cestě menší MTU než lokální, uživatelům se pak třeba nestahují z některých serverů stránky, případně se jejich stahování pokaždé na pár minut zasekne.

    Pravidla s typy TCP paketů by pravděpodobně měla být vhodně seřazená a na vhodném místě v řetězci oddělená něčím jako

    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

    To oddělí kombinace flagů, které jsou podezřelé vždy, od těch, které se v navázaném spojení můžou vyskytovat. To všechno by pak mělo být před přijímacími pravidly pro různé konkrétní protokoly nad TCP. Otázkou zůstává, jestli má smysl „závadné“ kombinace flagů takto fitrovat. Nesmyslné kombinace musí zahodit přímo TCP stack v kernelu. (Kdyby na něj nebylo spolehnutí, Internet by byl velmi nebezpečným místem.) Jediné vysvětlení by mohlo být, že správce u nějaké konkrétní služby neočekává jisté typy chování (protistrany), takže si může dovolit některé zvláštnosti odfiltrovat. Nicméně nepřipadá mi, že by se něco takového obecně hodilo jako globální nastavení pro všechny protokoly nad TCP.

    Ochrana proti SYN floodingu je v kernelu zabudovaná pro IPv6 i IPv4 a ve většině případů není nutné vymýšlet na to nějaká explicitní pravidla. Přímé filtrování na základě frekvence se sice na první pohled může jevit jako dobrý nápad, ale nějaký globální limit nadělá nakonec víc škody než užitku, protože jeden útočník útočící na jednom portu může klidně omezit použitelnost všech ostatních služeb, když se mu zlíbí. Přinejmenším by mělo existovat jiné nastavení pro SSH (velmi nízká frekvence i burst) a jiné třeba pro HTTP, DNS (ano, i tam dojde na TCP, třeba u DNSSEC) či obecně pro protokoly, kde se větší bursty dají očekávat. Rozhodně tady nebude fungovat one size fits all konfigurace; server pak může navenek vypadat jako nespolehlivý a každou chvíli offline.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    22.11.2013 17:47 Peter
    Rozbalit Rozbalit vše Re: Zdokonalenie firewallu proti svinstvu
    Ďakujem veľmi pekne za obsiahle vysvetlenie. ICMP samozrejme povolené mám a IPsec neriešim - používam OpenVPN. Teda podľa teba v podstate na firewally netreba okrem blokovania nepotrebých služieb nič iné riešiť a zvyšok nechať na aktuálny kernel?

    Mimochodom, dala by sa viac rozviesť tá myšlienka ohľadom tohto:
    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    
    Z "vonku" povoľujem len ICMP, 22, 25, 53U, 53T, 80, 443, 465, 993, 1194 a z "vnútra" je to samozrejme nejaká samba, proxy, ntp, cups, udpxy, ...

    Ešte raz ďakujem.
    25.11.2013 15:40 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Zdokonalenie firewallu proti svinstvu
    Mimochodom, dala by sa viac rozviesť tá myšlienka ohľadom tohto:
    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

    Před tím pravidlem jsou pravidla, která sežerou všechny možné vadné nebo nechtěné pakety — nechtěné nebo vadné za všech okolností, bez ohledu na to, jestli existují nějaká TCP spojení. (Ne že by taková pravidla byla nutná, ale někteří správci je rádi používají kvůli logování — aby měli přehled o případných pokusech o útok.)

    Po tom pravidle následují pravidla, která sežerou pakety předstírající existenci nějakého TCP spojení, přestože ve skutečnosti žádné neexistuje. Taková pravidla se používají snad jedině kvůli logování; každopádně ale nechceš, aby se k nim řetězec dostal v případě, kdy spojení opravdu existuje. Že spojení existuje, o tom ví právě modul conntrack.

    Pravidlo s conntrack se dá použít ještě v jednom případě: Když je nějaký řetězec extrémně dlouhý. Pak se toto pravidlo dá někam na začátek řetězce a ušetří tak průchod celým řetězcem při každém paketu. V některých jiných systémech (FreeBSD, Solaris) má firewall stromovitou strukturu, která se samovolně přeuspořádá a rotuje v závislosti na přijímaných paketech, aby se vždycky nejčastěji přijímaný typ paketu ocitl nejblíž kořeni stromu. (Tím pádem není potřeba řešit dělení pravidel do řetězců a počet pravidel.) Tohle ale v Linuxu (zatím) není, takže se někdy může hodit průchod dlouhým řetězcem zkrátit. Na gigabitovém ethernetu to rozhodně nehraje roli, zatímco u 10 Gb/s se už o takových věcech uvažovat musí.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.