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 11:11 | Nová verze

Byla vydána verze 0.10.0 webového prohlížeče qutebrowser (Wikipedie). Přehled novinek v příspěvku na blogu. Vývojáři qutebrowseru kladou důraz na ovladatelnost pomocí klávesnice a minimální GUI. Inspirovali se prohlížečem dwb a rozšířeními pro Firefox Vimperator a Pentadactyl. Prohlížeč qutebrowser je naprogramován v Pythonu a využívá PyQt5. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU GPL 3.

Ladislav Hagara | Komentářů: 1
včera 16:22 | Nová verze

Po pěti měsících od vydání Waylandu a Westonu 1.12.0 oznámil Bryce Harrington (Samsung) vydání Waylandu 1.13.0 a Westonu 2.0.0.

Ladislav Hagara | Komentářů: 0
24.2. 13:37 | Bezpečnostní upozornění

Společnost Cloudflare (Wikipedie) na svém blogu potvrdila bezpečnostní problém s její službou. V požadovaných odpovědích od reverzní proxy byla odesílána také data z neinicializované paměti. Útočník tak mohl získat cookies, autentizační tokeny, data posílaná přes HTTP POST a další citlivé informace. Jednalo se o chybu v parsování HTML. Zneužitelná byla od 22. září 2016 do 18. února 2017. Seznam webů, kterých se bezpečnostní problém potenciálně týká na GitHubu.

Ladislav Hagara | Komentářů: 1
24.2. 08:22 | Nová verze

Byla vydána první beta verze Ubuntu 17.04 s kódovým názvem Zesty Zapus. Ke stažení jsou obrazy Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu GNOME, Ubuntu Kylin, Ubuntu Studio a Xubuntu. Dle plánu by Ubuntu 17.04 mělo vyjít 13. dubna 2017.

Ladislav Hagara | Komentářů: 38
23.2. 17:53 | Bezpečnostní upozornění

Google na svém blogu věnovaném počítačové bezpečnost informuje o nalezení "reálného" způsobu generování kolizí hašovací funkce SHA-1. Podrobnosti a zdrojové kódy budou zveřejněny do 90 dnů. Již dnes lze ale na stránce SHAttered nalézt 2 pdf soubory, jejichž obsah se liší a SHA-1 otisk je stejný (infografika).

Ladislav Hagara | Komentářů: 34
23.2. 17:51 | Nová verze

Vyšla nová verzia open source software na správu a automatizáciu cloudových datacentier Danube Cloud 2.4. Danube Cloud je riešenie postavené na SmartOS, ZFS, KVM a zónach. Obsahuje vlastnosti ako integrovaný monitoring, DNS manažment, zálohy, a samozrejme rozsiahlu dokumentáciu.

dano | Komentářů: 12
23.2. 17:46 | Pozvánky

V Plzni se 3. až 5. března 2017 uskuteční AIMTEChackathon. Je to akce pro vývojáře, grafiky, webdesignéry i veřejnost. Akci provází zajímavé přednášky IT odborníků. Více o programu a možnosti přihlášení na stránkách akce.

cuba | Komentářů: 0
23.2. 01:00 | Nová verze

Známý šifrovaný komunikátor Signal od verze 3.30.0 již nevyžaduje Google Play Services. Autoři tak po letech vyslyšeli volání komunity, která dala vzniknout Google-free forku LibreSignal (dnes již neudržovaný). Oficiální binárky jsou stále distribuované pouze přes Google Play, ale lze použít neoficiální F-Droid repozitář fdroid.eutopia.cz s nezávislými buildy Signalu nebo oficiální binárku stáhnout z Google Play i bez Google účtu

… více »
xm | Komentářů: 8
22.2. 23:14 | Nová verze

Po třech týdnech od vydání první RC verze byla vydána první stabilní verze 17.01.0 linuxové distribuce pro routery a vestavěné systémy LEDE (Linux Embedded Development Environment), forku linuxové distribuce OpenWrt. Přehled novinek v poznámkách k vydání. Dotazy v diskusním fóru.

Ladislav Hagara | Komentářů: 8
22.2. 17:28 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2017-6074 v Linuxu zneužitelné k lokální eskalaci práv. Jde o chybu v podpoře DCCP (Datagram Congestion Control Protocol). Do linuxového jádra se dostala v říjnu 2005. V upstreamu byla opravena 17. února (commit). Bezpečnostní chyba byla nalezena pomocí nástroje syzkaller [Hacker News].

Ladislav Hagara | Komentářů: 16
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (13%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 711 hlasů
 Komentářů: 66, poslední 22.2. 18:57
    Rozcestník

    Dotaz: Zdokonalenie firewallu proti svinstvu

    22.11.2013 07:24 Peter
    Zdokonalenie firewallu proti svinstvu
    Přečteno: 593×
    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.