Příspěvky

631

Server / Re:Správa serveru s Debianem – jak začít jako admin

« kdy: 19. 10. 2018, 11:40:26 »

přečti si manuál (man pages, dají se exportovat všechny do pdf), vem do ruky knížku a nastuduj, není horší admin než ten, který naprosto netuší co a jak funguje, jen si umí na googlu vyhledat nějaké nastavení, které mu funguje, ale netuší jaké má vedlejší efekty.

https://www.oreilly.com/library/view/linux-bible-9th/9781118999875/
https://www.amazon.de/How-Linux-Works-Superuser-Should/dp/1593275676/

Nějak nevěřím tomu, že zvládáš iptables , u něho je potřeba znát hlavně jak funguje IP protokol, kudy putují v kernelu pakety a co se vše děje při otevírání a zavírání spojení, něco bys měl vědět i chainech v iptables, umět zablokovat nebo otevřít port není znalost iptables .

632

Odkladiště / Re:Internetbanking – Heslo nesmie obsahovať špeciálne znaky

« kdy: 15. 10. 2018, 20:14:34 »

řekl bych, že to tam mají z historických důvodů, dříve jsem tohle pravidlo vídal často a jako argument jsem slyšel, že lidé pak měli problém na jiném počítači zadávat ty speciální znaky a nemohli se přihlásit.

Před 15 lety možná obhajitelné, dnes to vypadá jako hodně blbý vtip.

Kit: ty budeš také pěkný exot.

633

Studium a uplatnění / Re:API Mojebanka.cz

« kdy: 11. 10. 2018, 13:27:19 »

pouze u byznys účtu mají API, osobní účty umí pouze zasílat výpisy přes email.

PS: to, že jsi otevřel vlákno, neznemaná, že nad ním máš automaticky kontrolu a můžeš ostatní okřikovat

634

Sítě / Re:Zabezpečení přístupu přes SSH

« kdy: 10. 10. 2018, 20:10:35 »

To je uplne jedno, je to totez jako kdyz pred bepecnostni dvere das jeste dalsi dvere a pred ne jeste dalsi ... a zlodej prijde oknem.

+1

Pokud bych ciste teoreticky byl opravdu paranoidni, pak asi nejak takhle. SSH vystaveno pouze na VPN, IPTABLE umozni pripojit na SSH pouze predem znamym statickym IP klientu. SSH akceptuje pouze pripojeni pres klic. Kazdy klient ma vlastni klic s omezenou dobou platnosti. (Idealne nekoncici vsem naraz). FAIL2BAN nebo jinej log parser upozorni administratora mailem/smskou pokud pokusy o prihlaseni prekroci threshold. Optional: port knocking, zmena SSH portu.

Utocnik v tomhle pripade (pokud neprojde oknem) musi byt schopen proniknout do VPN jako "admin" klient nebo premluvit VPN server o prideleni povolene IP adresy, pripadne se pred serverem tvarit ze ji ma i kdyz nema (MITM pres VPN). Ziskat klic k ssh, a optional vedet spravny port a sequence (coz dokaze ziskat pokud se mu podari proves MITM na VPN). Nebo ziskat user access na klientsky PC/Mobil (vsechna tahle prace prichazi v nivec instalaci prvniho cracku)

No a pak prichazi na radu zabezpeceni oken (aplikace bezici v kontejnerech)

Udivují mě tady rady od lidí, kteří snad o zabezpečení čtou jen na rootu.J to řiká správně.

SSH klíč nemůže mít nastavenou dobu platnosti, musel bych ho někým podepsat a ssh server nastavit tak, aby akceptoval pouze validní podepsané klíče. Port knocking, změna SSH portu jsou nesystémové změny, které nemají reálný význam.

Kontejner (Linux containers aka LXC aka docker) není vůbec určený k zabezpečení, má spousty míst kudy může útočník uniknout.

Sice jsi super paranoidní, máš vpn s adminem, ale pak tam necháš apache pod rootem či jinou zranitelnou službu a jsi v loji. Zabezpečení serveru musí být komplexní, musí se řešit veškeré služby, musí se řešit jejich pravidelná aktualizace (co bylo neproniknutelné dnes, je děravé zítra), logy se samozřejmě musí zpracovávat.

Fail2ban je nesmysl, snadno se dá zahltit a poslat server do kolen, při jeho restartu se pak může najít slabina u nějaké služby (velká část služeb startuje pod rootem a teprve posléze snižuje svoje práva) či prostě stačí jen omezit dostupnost serveru a vyprovokovat admina k unáhleným krokům a otevření vrat. FW pravidla musí být před samotným serverem, jejich automatické bezhlavé vyplňování do lokálního iptables je cesta do pekel, s ipv6 ta cesta má ještě zkratku.

635

Software / Re:Monitoring sítě

« kdy: 08. 10. 2018, 23:01:52 »

Nejsnadnejsi reseni je zaradit mezi hlavni router a klienty transparentni proxy server pro auditovani provozu. Tzn. vsechny schovas za NAT a pak mas nekolik moznosti jak to resit.

Vše natovat je dost nepěkné, nemluvě ne nemožnosti monitorovat icmp, udp nebo obecně L2. Stačí tam strčit před router switch a v promiskuitním módu provádět na klidně běžném malém servříku monitoring.

Jak píše Miroslav, vhodnější je celou síť rozdělit do menších celků a monitorovat důležité uzly, přidat internetovou gateway, nastavit na ní firewall, ids, ips a prostě do dostat do bezpečného stavu.

Ta síť je hodně zanedbaná, ale není to ve výrobních firmách žádná vyjímka, mění se to poslední dobou dost výrazně.

636

Studium a uplatnění / Re:iinfo.cz PHP programátor

« kdy: 08. 10. 2018, 22:52:51 »

Bohužel, taky mě ničí vidět jak někdo kdo nabízí práci trpí zapomnětlivostí a nenapíše plat

Nevidím v tom problém, v inzerátu neříkají jaké znalosti a zkušenosti požadují, plat lze čekat podle toho. Tady je vždy nějak moc lidí, pro které je plat to hlavní, očividně takoví lidé nejsou cílem inzerátu a třeba je to odradí zbytečně plýtvat čas náborářů.

637

Vývoj / Re:Riemannova hypoteza

« kdy: 28. 09. 2018, 21:15:19 »

Co napsal Vít dává smysl.

O prvočíslech toho moc nevíme, jejich zastoupení je třeba přibližně definované přirozeným logaritmem a v případě, kdy bychom dopředu věděli, která čísla jsou prvočísly, můžeme snížit náročnost RSA 2048 o spousty řádů, v tom tkví dokázání téhle hypotézy.

Co je ale vtipné, pokud se prokáže, že tenhle důkaz sporem je správný, nevypadá to, že by se něco s kryptografií prvočísel stalo, pořád nemáme "funkci na prvočísla" a musíme je hledat hrubou silou.

638

Bazar / Re:Prodám: Cisco CCNA CCNP Switch Router

« kdy: 21. 09. 2018, 15:17:58 »

líbí se mi catalyst 3550, ale 3500 za to nedám a ty ostatní mi jsou k ničemu. Nabízím za něj 1000 Kč.

639

Software / Re:Zabránit jakýmkoliv stránkám ve změně URL

« kdy: 21. 09. 2018, 15:13:44 »

přes custom script (třeba v adblocku) si přepiš funkce, které se o tu změnu starají. Jedná se o window.history.pushState a window.history.replaceState

Kód: [Vybrat]

window.history.pushState = function() {}
window.history.pushState = function() {}

Můžeš s tím ale rozbít určitou funkcionalitu stránek.

Tramvajak: doufám, že ti řízení tramvají jde lépe než javascript? Lze to. Je-li nová adresa ze stejné domény, změní se pouze url, je-li nová adresa z jiné domény (např. google.com), dojde ke klasickému přesměrování.

640

Sítě / Re:Jak funguje seekování MP4/MKV/TS přes HTTP?

« kdy: 11. 09. 2018, 16:49:44 »

ano, hlavně je potřeba mít metadata na začátku.

Seekování v FF nejde vidět nejspíš proto, že tam jdou vidět až dokončená http spojení, zatímco přehrávání videa to spojení bude držet otevřené. Kdysi byl problém, že ne všechny komunikace z prohlížeče šly vidět v debug panelu dokud probíhaly, implementace přehrávání videa tady bude hrát zásadní roli, DRM a další drobnosti. Přesně nevím.

Osobně bych se spíše podíval do OS, případně, wireshart hodně pomůže. Na HTTP server jede klasický range, v indexu v metadatech je také range, stejně to funguje při přehrávání na disku, http server pak nedělá z principu nic jiného než ten range předává OS a ten dělá přesně to co běžně.

3) stačí stáhnout tu koncovou část, ale musí si to udělat klient sám nebo si z JS můžeš říct o konec souboru, sám naparsovat a poté si seekovat sám

4) odhaduji, že pár Kb, už je to ale roky co jsem něco ručně parsoval. Existují na to hotové knihovny v různých jazycích, případně je možné projít specky

5) nikterak moc dat tam není, třeba u mkv je uvnitř blocku pouze časová značka, flagy pro dekódování, velikost framů a prá drobností o samotném snímku, podobné to je u mp4. Lepší je, když si ty specky prostě nastuduješ

641

Server / Re:Jak na efektivni remote desktop u linux serveru

« kdy: 03. 09. 2018, 18:20:13 »

občas si vystačím s novnc za vpn, používat se to dá a není to tak pomalé jako x11.

642

Server / Re:Podivný proces (initctl) v /tmp

« kdy: 28. 08. 2018, 02:04:44 »

tenhle zmetek nevypadá nijak nebezpečně, standadní program, ani se nesnaží nijak moc maskovat

totem-daemon: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=9f048c5a172c22779466986ce41a77f98c3f0282, stripped

linux-vdso.so.1 =>  (0x00007ffeda73f000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe89362e000)
libm.so.6 => /lib64/libm.so.6 (0x00007fe89332b000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe892f6a000)
/lib64/ld-linux-x86-64.so.2 (0x000055c932c9d000)

zapisuje do těhle souborů, aplikaci na těžbu si stahuje ze serverů z OVH, adresu má přímo v sobě a očividně běhá na netu více verzí, jak se adresa postupně měnila.

Kód: [Vybrat]

/home/aok/.bash_logout
/home/aok/.bash_profile
/home/aok/.bashrc
/home/aok/.cache/totem/service/.totem-daemon.bin
/home/aok/.cache/totem/service/.totem-daemon.log
/home/aok/.cache/totem/service/.totem-daemon.sys
/home/aok/.cache/totem/service/totem-daemon
/home/aok/.config/autostart/dbus-daemon.desktop
/home/aok/.local/share/accounts/services/.dbus-daemon.bin
/home/aok/.local/share/accounts/services/.dbus-daemon.log
/home/aok/.local/share/accounts/services/.dbus-daemon.sys
/home/aok/.local/share/accounts/services/.zeitgeist-fts.sys
/home/aok/.local/share/accounts/services/dbus-daemon
/home/aok/.local/share/accounts/services/zeitgeist-fts
/home/aok/.local/share/icc
/home/aok/.local/share/icc/.icc-daemon.bin
/home/aok/.local/share/icc/.icc-daemon.log
/home/aok/.local/share/icc/.icc-daemon.sys
/home/aok/.profile
/home/aok/.ssh/service/.ssh-agent.bin
/home/aok/.ssh/service/.ssh-agent.log
/home/aok/.ssh/service/.ssh-agent.sys
/home/aok/.ssh/service/ssh-agent

Aplikaci do /tmp stahuje po spuštění, není perzistentní, k jeho odstranění by mělo stačit odstranit a upravit soubory výše. Avšak nikdy si ale nemůžeš být jistý co jiného tam máš a co jiného tam běží

643

Server / Re:podivny proces (initctl) v /tmp

« kdy: 28. 08. 2018, 00:25:43 »

Opravdu? Jak je možné v prohlížeči jen tak spustit libovolný kód?

Kupodivu stačí neaktualizovat prohlížeč, i po roce už může být docela průser, zranitelností přes JS či média bylo v historii několik. Na up to date prohlížeči už tak samozřejmě tak snadné není.

Dejme tomu, že by dokázal zjistit, že se v nějakém terminálu přihlásil jako root. A co by ten kód spuštěný pod běžným uživatelem dál dělal? Jak by ovlivnil ten rootovský proces?

ve většině případů stačí sledovat titulek okna a hledat sudo, lze pak do bash procesu pod rootem poslat svůj obsah.

Jak router jen tak nakazil počítač v síti? Nejsnáz asi kapénkovou infekcí…

Ne jen tak, musíš tam mít otevřenou nezabezpečenou službu nebo může páchat mitm, to se ale rychle prozradí.

Píšete blbosti, bylo vyvedeno dost úsilí aby někdo nemohl jen tak spustit libovolný kod po navštívení webove stranky. A i pokud mate otevreny port, stale potrebujete něco co na něm poslouchá s nějakou zranitelností, která nebyla patchnuta.

Jinak na webu se píše, že byl nakažený nějaký plugin pro přehrávač na Archu (Kodi), to mi spíš příjde jako rozumný attack vector.

Pro dlouho neaktualizované prohlížeče takových stránek je poměrně velké množství. Je ale obtížné tě na takovou stránku dostat, to ano, neaktualizovaný prohlížeč je ale častý vej.

Ano, musí tam být běžící služba, nebo se může páchat mitm třeba na stahování balíčků, pacman ale používá gpg a tady bych problém neviděl.

Pokud se jedná o Kodi, dobře. Zranitelnost může udělat jakákoliv spuštěná aplikace.

644

Server / Re:podivny proces (initctl) v /tmp

« kdy: 27. 08. 2018, 19:12:32 »

nakažení linuxu není kupodivu tak složité, za vším hledej prohlížeč, přes ně se spustil kód, který třeba nemusel dělat nic jiného než čekat až se v nějakém terminálu přihlásíš jako root. Nebo klidně ani nemusel potřebovat roota, prostě si vlezl do .bashrc a odtud se spouštěl a těžil. Pokud to nebyl prohlížeč, tak ti někdo kazil router a ten zase nakazil sebe, protože jak to bývá u domácích počítačů, FW není potřeba...

To ale pouze střílím, k přesným závěrům je potřeba bitová kopie disku a dump paměti.

Smaž to a jdi znovu, nebo si začni prohledávat tempy a hledat kudy ten program se mohl někam dostat.

645

Server / Re:Jak dokumentujete servery?

« kdy: 27. 08. 2018, 11:23:57 »

Já dokumentuji na dokuwiki. Základní logiku serveru, komunikační schéma, nutné procesy a speciální úpravy konfigurace. Je tam i dvouvětový manažerský úvod, víc nepobírají. Zbytek nechávám na zálohování. Dokumentace by se měla upravovat maximálně při reinstalaci serveru nebo přidání nové služby. Většinou platí, že dokumentace, která se upravuje častěji než 1x ročně, není správně udělaná.

Ono asi jde o to co provozuješ, pokud ale máš desítky, stovky serverů a k tomu desítky neustále pracujících vývojářů, máš tým sysadminů, kteří pernamentně implementují nové věci, pak prostě dokumentaci upravuješ i několikrát denně.

Už jen taková maličkost jako pravidla pro FW, potřebuješ k nim evidovat spoustu věcí a to je přesně to, co se také do dokumentace píše. Brát jako dokumentaci aktuální (či minulý) stav serveru je tenký led, občas potřebuješ vědět důvod, občas potřebuješ udělat audit, že vše je správně a zamýšleně nastavené, občas potřebuješ vědět které nastavení je pro kterou aplikaci, jak to chceš udělat, když máš jen ten stav?

Chápu, že provozovat apache server a na něm dva weby znamená v podstatě nulovou potřebu něco poměnit.