• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    SHORTYMikrotik, Alix a jina mala reseni... Arduino, RaspberryPi, Mikrotik, Alix a jina mala reseni...
    LEXXA
    LEXXA --- ---
    prosimvas, mate nekdo nejaky "tucnejsi" mikrotik?
    mam hex3 a kdyz hrnu provoz pres SSTP tak dostanu v idealnem pripade 7-8mbitu. linka ustoji nasobne vic.
    kdyz pouzivam eoip/ipsec tunel nemam problem se dopracovat na udavanou kapacitu linky.
    chci vedet jestli muzu s tim neco udela nebo musim jit do drazsiho/lepsiho cosi od mikrotiku, nebo v krajnem pripade uplne zmenit platformu...
    TEAPACK
    TEAPACK --- ---
    GHORMOON: Tak zádrhel byl v Bridge v nastavení fast-track... teď už to jede =)
    GHORMOON
    GHORMOON --- ---
    TEAPACK: a ten nat mas jak? pripadne jak psal ATAN, jestli tam nemas jeste nejakou jinou botu
    TEAPACK
    TEAPACK --- ---
    GHORMOON: jj ven = internet, v NATu mám akorát maškarádu a ve filtru default:
     D ;;; special dummy rule to show fasttrack counters
          chain=forward action=passthrough 
     1    ;;; defconf: accept ICMP
          chain=input action=accept protocol=icmp 
     2    ;;; defconf: accept established,related
          chain=input action=accept connection-state=established,related 
     3    ;;; defconf: drop all from WAN
          chain=input action=drop in-interface=ether1 
     4    ;;; defconf: fasttrack
          chain=forward action=fasttrack-connection 
          connection-state=established,related 
     5    ;;; defconf: accept established,related
          chain=forward action=accept connection-state=established,related 
     6    ;;; defconf: drop invalid
          chain=forward action=drop connection-state=invalid
     7    ;;; defconf:  drop all from WAN not DSTNATed
          chain=forward action=drop connection-state=new 
          connection-nat-state=!dstnat in-interface=ether1
     
    ATAN
    ATAN --- ---
    TEAPACK: k cemu je tam bridge2? bylo by jednodussi, kdybys jsem dal vystup '/export hide-sensitive'.
    GHORMOON
    GHORMOON --- ---
    TEAPACK: ven -> do internetu? co mas ve firewallu a natu? tam nejspis neco bude chybet :)
    TEAPACK
    TEAPACK --- ---
    Ahoj, už druhej den přehlížím něco v nastavením mikrotiku (RouterOS v6)... Potřebuju oddělit wifi od ethernetu, takže jsem si:
    1) přidal druhý pool s požadovaným rozsahem
    2) Adresses s taktéž
    3) vytvořil jsem druhý bridge a nastavil u iface vlan bridge2
    4) vytvořil druhý DHCP server a nastavil mu bridge2

    Zařízení se připojí, dostanou IP, ale ven se nedostanou :-/ Pokud to jde udělat jedodušeji, rozhodně se bránit nebudu, ale musím nakombinovat ethernet s DHCP pro jednu část s IP 192.168.3.0/24, další eth bez DHCP (fixní IP v rozsahu 192.168.1.0/26), ale aby na sebe zařízení viděly a wifi, která by měla vidět jen do internetu...
    ROENICK
    ROENICK --- ---
    Postřehy z bezpečnosti: úroda u MikroTiků - Root.cz
    https://www.root.cz/clanky/postrehy-z-bezpecnosti-uroda-u-mikrotiku/
    DANYSEK
    DANYSEK --- ---
    ROENICK: Spousta "profi" firewallu ti tu hlavicku dropne (aby mohla provadet L7 inspekci), kdyz si nepohrajes s nastavenim. Takze me to neprekvapuje :-)
    Google & spol to asi tlaci proto, ze se ve svym distribuovanym DNS, ktery navic odpovida ruzne podle toho, odkud se ho zrovna ptas srat s DNSSECem nechce... na druhou stranu to muze skoncit podobne, jako s HPKP - ktery Google taky protlacil do RFC... a v novym Chrome to dnes uz nepodporujou.
    ROENICK
    ROENICK --- ---
    DANYSEK: jo o tom vsem tam vcera mluvil Hala. Nevim proc napr Google tlaci ten MTA-STS

    STARTTLS hlacicku prej dokonce vyhazovali nekteri ISP
    DANYSEK
    DANYSEK --- ---
    ROENICK: vsak vime... DANE je zavisly na DNSSECu, do kteryho se ne vsichni hrnou a tak se vymyslela opicarna MTA-STS, kdy si mail server bude nejakou politiku lovit na webserveru (kdy ne/existenci one politiky zjistis opet z toho nezabezpecenyho DNS, kvuli kterymu ta opicarna je). Aneb dalsi skrabani se levou rukou za pravym uchem z pera tech, co na DNSSEC dlabou... dalsi paskvil, cinici navic dorucovani mailu zavisle nejen na DNS, ale jeste i na webu :-) A stejne to neresi onen uvodni problem - stejne jako muze MITM vymaskovat STARTTLS hlavicku u SMTP spojeni je mozne vyblokovat (podvrhnout) ten potrebny uvodni DNS dotaz, pripadne i ten vlastni download politiky. Proste nedomyslena opicarna :-)
    ROENICK
    ROENICK --- ---
    DANYSEK: dnes na linuxdays o tom mluvili, chce to implementovat DANE a sifrovat, z CZ.NIC snad bude nakej tlak
    DANYSEK
    DANYSEK --- ---
    ROENICK: me se strasne libi to aktualni "hypersilenstvi" kolem https, ale to ze maily kdekdo transportuje nesifrovane (a sifrovani nepodporuje) nikdo absolutne nepitva... :) Aneb je "uzasny", ze i webik pejskaru pobezi sifrovane, ale ze notifikace treba z datovky (a hromady dalsich mist, i ruzny eshopy, atd... ale treba i tady nyx) litaj nesifrovane je naprosto cajk a nikdo se tim nezabejva...
    ROENICK
    ROENICK --- ---
    DANYSEK: to byla jen poznamka, podstata tweetu je jinde. A pricin proc ti nekdo upravi http provoz muze byt spousta
    DANYSEK
    DANYSEK --- ---
    ROENICK: resi dusledky, nikoliv priciny...
    ROENICK
    ROENICK --- ---
    DANYSEK: on narazi na to, ze ti pak do http webu nekdo cestou vlepi cryptominer..coz se do https dava blbe. Nemusi to bejt router, ISP vkladali reklamy apod...
    DANYSEK
    DANYSEK --- ---
    ROENICK: seznam hezkej, ale Spackova zkratka je o hovne. Problem je nezabezpecenej management routeru otevreny do sveta, nikoliv absence HTTPS vsudemozne...
    ROENICK
    ROENICK --- ---

    @spazef0rze

    Shodan umí vytvářet i hezké reporty. Tady jsou např. aktuálně napadené routery Mikrotik, které do stránek vkládají skript na těžení kryptoměny:
    https://t.co/ciJPmgOr3w (mimochodem: i proto by HTTPS mělo být všude, i na statických stránkách) #LinuxDays
    NYXEL
    NYXEL --- ---
    Jn, to jsou spis takovy "roztomilosti" :D
    ATAN
    ATAN --- ---
    Neni to nic hrozneho:

    CVE-2018-1156: An authenticated user can trigger a stack buffer overflow.
    CVE-2018-1157: File upload memory exhaustion. An authenticated user can cause the www binary to consume all memory.
    CVE-2018-1158: Recursive JSON parsing stack exhaustion, which could allow an authenticated user to cause crash of the www service.
    CVE-2018-1159: www memory corruption, if connections are initiated and not properly cleaned up then a heap corruption occurs in www.
    Kliknutím sem můžete změnit nastavení reklam