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 05:55 | Zajímavý projekt

Dle příspěvku na blogu zaměstnanců CZ.NIC byl spuštěn ostrý provoz služby Honeypot as a Service (HaaS). Zapojit se může kdokoli. Stačí se zaregistrovat a nainstalovat HaaS proxy, která začne příchozí komunikaci z portu 22 (běžně používaného pro SSH) přeposílat na server HaaS, kde honeypot Cowrie (GitHub) simuluje zařízení a zaznamenává provedené příkazy. Získat lze tak zajímavé informace o provedených útocích. K dispozici jsou globální statistiky.

Ladislav Hagara | Komentářů: 0
dnes 04:44 | Komunita

Před týdnem společnost Feral Interactive zabývající se vydáváním počítačových her pro operační systémy macOS a Linux oznámila, že pro macOS a Linux vydají hru Rise of the Tomb Raider. Včera společnost oznámila (YouTube), že pro macOS a Linux vydají také hru Total War Saga: Thrones of Britannia. Verze pro Windows by měla vyjít 19. dubna. Verze pro macOS a Linux krátce na to.

Ladislav Hagara | Komentářů: 0
včera 21:33 | Nová verze

Byla vydána nová major verze 7.10 svobodného systému pro řízení vztahů se zákazníky (CRM) s názvem SuiteCRM (Wikipedie). Jedná se o fork systému SugarCRM (Wikipedie). Zdrojové kódy SuiteCRM jsou k dispozici na GitHubu pod licencí AGPL.

Ladislav Hagara | Komentářů: 0
včera 16:44 | Nová verze

Byla vydána nová verze 0.30 display serveru Mir (Wikipedie) a nová verze 2.31 nástrojů snapd pro práci s balíčky ve formátu snap (Wikipedie). Z novinek Miru vývojáři zdůrazňují vylepšenou podporu Waylandu nebo možnost sestavení a spouštění Miru ve Fedoře. Nová verze snapd umí Mir spouštět jako snap.

Ladislav Hagara | Komentářů: 0
včera 14:00 | Komunita

Na Indiegogo běží kampaň na podporu Sway Hackathonu, tj. pracovního setkání klíčových vývojářů s i3 kompatibilního dlaždicového (tiling) správce oken pro Wayland Sway. Cílová částka 1 500 dolarů byla vybrána již za 9 hodin. Nový cíl 2 000 dolarů byl dosažen záhy. Vývojáři přemýšlejí nad dalšími cíli.

Ladislav Hagara | Komentářů: 1
včera 11:11 | Nasazení Linuxu

Před dvěma týdny se skupina fail0verflow (Blog, Twitter, GitHub) pochlubila, že se jim podařilo dostat Linux na herní konzoli Nintendo Switch. O víkendu bylo Twitteru zveřejněno další video. Povedlo se jim na Nintendo Switch rozchodit KDE Plasmu [reddit].

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

Byla vydána vývojová verze 3.2 softwaru Wine (Wikipedie), tj. softwaru, který vytváří aplikační rozhraní umožňující chod aplikací pro Microsoft Windows také pod GNU/Linuxem. Z novinek lze zdůraznit například podporu HID gamepadů. Aktuální stabilní verze Wine je 3.0, viz verzování. Nejistá je budoucnost testovací větve Wine Staging s řadou experimentálních vlastností. Současní vývojáři na ni již nemají čas. Alexandre Julliard, vedoucí projektu Wine, otevřel v diskusním listu wine-devel diskusi o její budoucnosti.

Ladislav Hagara | Komentářů: 2
18.2. 16:55 | Komunita

Do 22. března se lze přihlásit do dalšího kola programu Outreachy (Wikipedie), jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 14. května do 14. srpna 2018, v participujících organizacích lze vydělat 5 500 USD.

Ladislav Hagara | Komentářů: 54
17.2. 15:44 | Komunita

Nadace The Document Foundation (TDF) zastřešující vývoj svobodného kancelářského balíku LibreOffice dnes slaví 6 let od svého oficiálního vzniku. Nadace byla představena 28. září 2010. Formálně ale byla založena až 17. února 2012. Poslední lednový den byl vydán LibreOffice 6.0. Dle zveřejněných statistik byl za dva týdny stažen již cca milionkrát.

Ladislav Hagara | Komentářů: 1
17.2. 04:44 | Bezpečnostní upozornění

CSIRT.CZ upozorňuje, že byla vydána nová verze 1.2.3 svobodného routovacího démona Quagga (Wikipedie) přinášející několik bezpečnostních záplat. Při nejhorší variantě může dojít až k ovládnutí běžícího procesu, mezi dalšími možnostmi je únik informací z běžícího procesu nebo odepření služby DoS. Konkrétní zranitelnosti mají následující ID CVE-2018-5378, CVE-2018-5379, CVE-2018-5380 a CVE-2018-5381.

Ladislav Hagara | Komentářů: 0
Který webový vyhledávač používáte nejčastěji?
 (2%)
 (28%)
 (62%)
 (2%)
 (3%)
 (1%)
 (1%)
 (1%)
Celkem 390 hlasů
 Komentářů: 34, poslední 14.2. 18:44
    Rozcestník

    Dotaz: ignorováni SNAT, do internetu odchází pakety s privátní IP

    22.5.2015 11:16 Franta Hanzlík
    ignorováni SNAT, do internetu odchází pakety s privátní IP
    Přečteno: 318×
    Zdravím, neřešili jste už někdo někdy problém, kdy netfilter pro některá spojení (zdá se) ignoruje pravidla iptables, a nepomáhá ani restart iptables?
    V nat table na firewallu mám zhruba tohle:
    -P PREROUTING ACCEPT
    -P INPUT ACCEPT
    -P OUTPUT ACCEPT
    -P POSTROUTING ACCEPT
    -A PREROUTING -d PubIP1 -i eth1 -j DNAT --to-destination 192.168.0.248
    -A POSTROUTING -s 192.168.0.248 -o eth1 -j SNAT --to-source PubIP1
    -A POSTROUTING -o eth1 -j SNAT --to-source PubIP2
    
    eth1 je rozhraní do internetu a má dvě veřejné adresy PubIP1 a PubIP2, vnitřní síť je 192.168.0.0/24, na stroj 192.168.0.248 se dělá IP fowarding.

    Po provedení nějakých, většinou ručních úprav (s následným zapsáním pravidel do konfiguráku (u mne /etc/sysconfig/iptables)) jsem zjistil, že některá spojení do internetu nejsou NATovaná a pakety odchází s privátní IP (v tomto případě ze stroje IP=192.168.0.248 na cíl odcházely UDP pakety na dstport 5060 s jeho původní privátní adresou 192.168.0.248). Ale pakety ze stejného stroje 192.168.0.248 na jiné cíle v internetu (vč. jiného stroje s kterým se komunikovalo také přes UDP) byly překládané správně, na source adresu PubIP1. Restart iptables (včetně 'ip link set eth1 down/up') nepomohl, restart celého firewallu ano.
    Zdá se, jako kdyby se nějak pamatovala předchozí spojení a pokračovalo se v nich či co. Je možné, že by např. conntrack table takhle ovlivňovala netfilter (asi jsem ji mohl zkusit flushnout pomocí conntrack, ale nenapadlo mne to a byl kvalt)? Nebo je to způsobeno něčím jiným? Myslím, že už se mi to stalo (že jsem viděl z internet rozhraní odcházet neNATované pakety) jednou, dvakrát i v minulosti, okolnosti byly podobné (nat table i jednodušší (jen jeden SNAT), problém nastal také po nějakých mých vrtáních se v netfilter pravidlech) a řešil jsem to stejně blbě jako teď, restartem stroje. Teď to bylo na FW s jádrem 3.19.5-100.fc20.x86_64 a iptables 1.4.19.1.


    Odpovědi

    22.5.2015 12:19 NN
    Rozbalit Rozbalit vše Re: ignorováni SNAT, do internetu odchází pakety s privátní IP
    Mohlo by se to stat proto, ze mas nastavenou veskerou politiku na ACCEPT, takze pokud firewall nevi co ma s paketem udelat, tak ho proste pusti(neprelozeny).. ale to je debata, kterou byfh neotviral. Dale jsi nezaslal zbytek firewallu, takze muzeme jen hadat a zaroven mam pocit, ze nemas jistotu, ze tvou modifikovanana pravidla jsou ta jedina, ktera se uplatnuji pri startu systemu a v podstate to nemas pod kontrolou. Nebo se pletu?
    22.5.2015 13:47 Franta Hanzlík
    Rozbalit Rozbalit vše Re: ignorováni SNAT, do internetu odchází pakety s privátní IP
    Zkusím položit dotaz jinak: jediná iptables pravidla jsou ta v "/etc/sysconfig/iptables", firewalld ani jiný dynamický firewall v systému není. Pokud dobře čtu "/usr/libexec/iptables/iptables.init" (ovládací script iptables Fedora 20), tak zastavení iptables provede:
    - flush všech tabulek - výmaz všech pravidel
    - výmaz všech uživatelem definovaných chainů
    - vynulování paket/byte čítačů všech chainů
    - nastaví politiky všech chainů na ACCEPT
    - provede unload kernel modulů souvisejících s netfiltrem
       (netuším jak moc dobře, můžu se na to mrknout večer)
    
    Takže, co může způsobit to, že navzdory SNAT pravidlu v nat POSTROUTING chainu se toto na některé pakety neaplikuje, ani po restartu firewallu (a po restartu systému je vše OK)? Mohly by to způsobit z nějakého důvodu neuloadované síťové moduly jádra?
    PS: V nat tabulce jsou v podstatě jen ta v dotazu napsaná pravidla, filter table by to snad ovlivnit neměla, mangle ani jiné tabulky tam nejsou.
    (pod kontrolou to ovšem evidentně nemám, když si to neumím jasně vysvětlit ;)
    22.5.2015 14:16 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: ignorováni SNAT, do internetu odchází pakety s privátní IP
    Ten popis je trochu zmatený a není z něj jasné, co přesně jste udělal, kdy a v jakém pořadí. Obecně: NAT pravidla v tabulce nat se aplikují jen na pakety, které jsou (z pohledu conntracku) "NEW". Takže jestliže už máte v conntrack tabulce nějaké položky a přidáte nové pravidlo, může se stát, že se na pakety odpovídající těm stávajícím položkám neaplikuje, protože jsou "ESTABLISHED". Zkuste, jestli pomůže "conntrack -F".
    22.5.2015 15:27 Franta Hanzlík
    Rozbalit Rozbalit vše Re: ignorováni SNAT, do internetu odchází pakety s privátní IP
    Co přesně jsem dělal a v jakém pořadí samozřejmě nevím - kdybych to věděl nebo si to uměl nasimulovat, tak bych to zkusil dohledat sám. Byla to asi hodinová patlanina všeho možného, hrál jsem si s nf_nat_sip, vyráběl jsem na pravidlech nějaké čítače, logování, filtrování a jiné opičárny. Když jsem byl s výsledkem spokojen, upravil jsem konfigurák s iptables pravidly ("/etc/sysconfig/iptables", viz výše) a udělal restart iptables (ve Fedoře se dělá pomocí zmíněného scriptu "/usr/libexec/iptables/iptables.init" - a nemám nastaveno, že se při restartu iptables budou ukládat aktuálně běžící pravidla). Vše vypadalo OK - ale pak jsem zjistil, že se jedno spojení (bylo to spojení asteriska na té 192.168.0.248 na VoIP providera) nepřekládá - ale všechna ostatní ano, včetně externích VoIP telefonů které se na tu ústřednu připojovaly zvenku.

    Proto byl dotaz spíš teoretický - co může v běžícím systému způsobit, že po restartu iptables se jeho pravidla obecně neaplikují?
    Restart/stop iptables ve Fedoře se mj. pokouší udělat rmmod x_tables, nf_nat a nf_conntrack modulů a modulů na nich závislých, měl jsem tedy za to, že tím také zaniknou všechny položky v conntrack table. Asi nejpravděpodobněji ale vypadá možnost, že se ve scriptu z nějakého důvodu nf_conntrack nepovede unloadnout, a v conntrack table zůstane info o daném spojení (neNATovaném, třeba z toho důvodu, že vzniklo během předchozího (re)startu iptables v době, kdy nat table ještě nebyla kompletní), souhlasíte? Nebo je ještě jiná možnost, jak se to může stát?
    Na ten flush conntrack table jsem nevzpomněl, zkusím - jestli to zase někdy nastane.

    22.5.2015 15:38 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: ignorováni SNAT, do internetu odchází pakety s privátní IP

    Pokud skript opravdu unloadne všechny relevantní moduly, tak ta varianta, že conntrack položka vznikla v okně mezi natažením modulu a přidáním NAT pravidla, mi zní jako docela pravděpodobné vysvětlení. Pak by asi bylo vhodné na konec skriptu nastavujícího firewall přidat flushnutí conntracku.

    Je to ale dvousečné. Dokážu si třeba představit situaci, kdy mám existující TCP spojení ven a aplikační data proudí jen směrem dovnitř (HTTP stahuje velký soubor, případně SSH spojení se spuštěným příkazem generujícím výsup). Pak se pakety zvenku budou zahazovat a zevnitř nikoho nenapadne nějaké poslat, takže spojení po nějakém čase umře (pokud bude REJECT, pak umře hned). Ono se asi celkově při návrhu toho skriptu předpokládá, že se bude spouštět při startu, ne za běhu systému, kdy už tam probíhá nějaká komunikace.

    19.11.2015 14:28 Franta Hanzlik
    Rozbalit Rozbalit vše Re: ignorováni SNAT, do internetu odchází pakety s privátní IP
    Teď se mi stal stejný případ - po malé úpravě (změna IP adresy v INPUT chainu filter pravidla) v souboru konfigurace iptables a po jejich restartu opět odcházely (opět UDP SIP, ale jiný Linux stroj) pakety s ne-nat-ovanou zdrojovou IP. Inspekcí conntrack table a následným výmazem ('conntrack -D -p udp ...', ale flush conntrack table by musel zabrat také) příslušných spojení se problém odstranil.
    Zajímavé bylo, že v tomto případě se jednalo o SIP traffic ze čtyř Siemens Gigaset VoIP základen, a problém (neNATování) se týkal všech čtyř. Pravděpodobnost, že by v době startu iptables nastala všechna čtyři spojení je nepravděpodobná, tak jsem se koukal na konfiguraci jádra - a tady je asi příčina problému.
    Jádro je sestaveno s volbami:
    CONFIG_NETFILTER=y
    CONFIG_NETFILTER_ADVANCED=y
    CONFIG_BRIDGE_NETFILTER=y
    CONFIG_NETFILTER_NETLINK=m
    CONFIG_NETFILTER_NETLINK_QUEUE=m
    CONFIG_NETFILTER_NETLINK_LOG=m
    CONFIG_NF_CONNTRACK=y
    CONFIG_NF_CONNTRACK_MARK=y
    CONFIG_NF_CONNTRACK_SECMARK=y
    CONFIG_NF_CONNTRACK_ZONES=y
    CONFIG_NF_CONNTRACK_EVENTS=y
    CONFIG_NF_CONNTRACK_AMANDA=m
    CONFIG_NF_CONNTRACK_FTP=m
    CONFIG_NF_CONNTRACK_H323=m
    CONFIG_NF_CONNTRACK_IRC=m
    CONFIG_NF_CONNTRACK_NETBIOS_NS=m
    CONFIG_NF_CONNTRACK_PPTP=m
    CONFIG_NF_CONNTRACK_SANE=m
    CONFIG_NF_CONNTRACK_SIP=m
    CONFIG_NF_CONNTRACK_TFTP=m
    CONFIG_NETFILTER_TPROXY=m
    CONFIG_NETFILTER_XTABLES=y
    CONFIG_NF_CONNTRACK_IPV4=y
    
    tj. nf_conntrack a nf_conntrack_ipv4 jsou v jádře, ne jako moduly, a tudíž conntrack table se nevyprázdní.
    Druhá zajímavost je, že stav těch špatných spojení byl (aspoň myslím) 'ASSURED' a tak zůstal napořád, a traffic se neNAToval. Asi protože se VoIP zařízení neustále pokoušelo o navázání spojení, tak příslušná položka v conntrack table zřejmě zřejmě nevypadla na nějaký timeout.

    Zásadní je samozřejmě to, že jsem s existujícími spojeními v conntrack table a jejich ovlivňováním iptable pravidel vůbec nepočítal, moje chyba. Díky za nakopnutí!

    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.