V X.Org v libX11 do 1.8.7 a libXpm do 3.5.17 bylo nalezeno a v upstreamu opraveno 5 bezpečnostních chyb (CVE-2023-43785, CVE-2023-43786, CVE-2023-43787, CVE-2023-43788 a CVE-2023-43789). Dvě nejstarší jsou s námi 35 let. Obsaženy byly již v X11R2 vydaném v únoru 1988.
Byly publikovány informace o bezpečnostní chybě Looney Tunables aneb CVE-2023-4911 v glibc ld.so. Útočník ji může využít k lokální eskalaci práv. Vyzkoušeno na výchozích instalacích linuxových distribucí Fedora 37 a 38, Ubuntu 22.04 a 23.04 a Debian 12 a 13. Chyba byla do glibc zavlečena v dubnu 2021. Detaily v txt.
Na Kickstarteru byla spuštěna crowdfundingová kampaň na podporu telefonu Murena 2 s /e/OS. Telefon má 2 hardwarové přepínače. Prvním lze jednoduše vypnout kamery a mikrofony. Druhým se lze odpojit od sítí.
Společnost Qualcomm publikovala říjnový bezpečnostní bulletin. V úvodu informuje, že bezpečnostní chyby CVE-2023-33106, CVE-2023-33107, CVE-2022-22071 a CVE-2023-33063 jsou cíleně využívány útočníky. O CVE-2022-22071 se píše už v loňském květnovém bulletinu. Detaily o zbylých chybách jsou k dispozici OEM partnerům. Veřejně budou k dispozici až s vydáním prosincového bulletinu.
Byla vydána nová verze 5.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 12.5.6. Tor na verzi 0.4.8.6.
Šifrovací nástroj VeraCrypt v menším vydání 1.26.7 nejen opravuje chyby a aktualizuje podporované algoritmy (podrobnosti v poznámkách vydání), ale také přestává podporovat původní svazky TrueCrypt.
V sobotu 7. října proběhne Maker Faire Liberec, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Mastodon vydal výroční zprávu za rok 2022 (pdf).
Ubuntu Summit 2023 proběhne od 3. do 5. listopadu v Rize.
Programovací jazyk Python byl vydán v nové major verzi 3.12.0. Podrobný přehled novinek v Changelogu.
Řešení dotazu:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
apt-get install fail2ban
iptables pak není větší, než jednoduché uzavření spojení.
1.6.2011 23:30
Bilbo | skóre: 29
Když se chcete kdykoliv jakkoliv a odkudkoliv přihlásit, tak si to tak nastavit můžete, ale pak se může kdykoliv jakkoliv a odkudkoliv přihlásit také někdo jiný.
, obvykle to řeším z ntb, kde vlastně ani neřeším kde jsem co dělám - stačí 3 hesla (k disku, k přihlášení a k certifikátu) a dostanu se všude. Ale někdy jsem rád, že mám aspoň platební kartu .No zrovna u toho ssh to není tak těžké, můžete si nechat třeba pro začátek nechat posílat audit.log ohledně úspěšných spojení a jednou denně ho číst. Což tak nějak je používaná praktika.Myslíte, že když se někdo na server dostane, bude čekat, až se mi pošle neupravený log spojení? A že „ruční“ pročítání takového logu bude spolehlivé?
A ohledně monitorování zvenčí, IDS softwarů je docela dost a myslím si že pokud mám nějakou síť opravdu zabezpečit, tak je lepší investovat trochu vůle a času do ochočení nějakého, byť blbého, IDS, než pozorovat ... co?A co budu pozorovat s tím IDS? Že se ten napadený počítač chová z venku pořád stejně? Obě zmíněná opatření by asi odhalila nějaké script-kiddies, ale proti těm je dostatečnou ochranou aktualizovaný software a používání bezpečných způsobů přihlášení (nejlépe klíče, nebo alespoň silná hesla).
Myslíte, že když se někdo na server dostane, bude čekat, až se mi pošle neupravený log spojení? A že „ruční“ pročítání takového logu bude spolehlivé?Já jsem kdysi míval normální syslog forwarding a to celkem spolehlivé bylo. Ta hláška se odešle souběžně, ne-li dřív, než se přihlásí, a když si to necháte jednou denně vyjet a přečtete si to, tak máte aspoň omezenou dobu, do kdy na to přijdete. Pravděpodobně na to lze nasadit nějaký automatický analyzátor, ale to mi na první iteraci přijde zbytečně složité.
A co budu pozorovat s tím IDS? Že se ten napadený počítač chová z venku pořád stejně?Spoustu věcí. Že se na počítač spojuje kdosi odkudsi jinud než normálně, že se počítač začne chovat jinak - např. napadat ostatní počítače. Samozřejmě se lze před tím skrýt, ale je to další úsilí, které musí útočník vyvinout, když nemáte IDS, tak nebude muset vyvinout nic.
Funguje to tak, že si počítá počet připojení za jednotku času a pokud je ten počet překročen zdrojovou adresu zablokuje.To pak musí být zábava, když na nějakém počítači, který není na whitelistu, pustíte třeba tohle:
for f in * do scp $f user@remote:/nejaka/cesta doneZrovna v tomhle případě to jde udělat lépe, ale někdy něco takového může být nejjednodušší řešení.
find (nestačí na to hězdičková expanze scp), a je jich tolik, že se nevejdou všechny jako parametry příkazové řádky?
Jaka hvezdickova expanze scp?Normální hvězdičková expanze
scp. Když dáte cestu s hvězdičkou do uvozovek, shell neprovede expanzi a předá hvězdičku scp. Hvězdičku pak expanduje až scp. Díky tomu můžete hvězdičku použít i ve vzdálené cestě (shell by vám ji expandoval podle místních souborů nebo vůbec – podle toho, jak by si poradil s tou divnou cestou). Nebo-li
scp -r user@remote:/home/user/* ./vám nejspíš neprojde a shell vám vynadá, že nezná cestu
user@remote:/home/user/ a nemůže expandovat hvězdičku. Nebo to pochopí jako lokální cestu /home/user a ze vzdáleného serveru tak okopírujete soubory a adresáře s takovými jmény, jaké máte v lokálním adresáři /home/user. Což jste asi nechtěl.
scp -r "user@remote:/home/user/*" ./udělá to, co očekáváte, totiž okopíruje všechny viditelné soubory a adresáře ze vzdáleného adresáře
/home/user.
jestli je seznam dlouhy, tak scp * rozhodne fungovat nebudeTo jsem psal.
Presne tenhle problem se resi pres xargs.Který se interně chová tak, že seznam argumentů rozdělí na několik kratších a zavolá příkaz (tady
scp) opakovaně – čímž se aktivuje zmíněná ochrana a daná IP adresa se zablokuje.
Kdyz potrebuje neco jineho nez *, tak samozrejme find .. -exec vcetne spravnych uvozovek.Tím se
scp spustí pro každý soubor zvlášť, tedy opakovaně, a opět zafunguje zmíněná ochrana a blokace.
Seznam ze souboru musite cist pres while read LINE; do scp "$LINE" host:/dir/ ; done < file_listA do třetice opakované spuštění
scp následované aktivací ochrany a blokací IP adresy.
scp pouštět opakovaně. Způsobů provedení si můžete vymyslet milion – já jsem zvolil schválně takový, ze kterého bude na první pohled vidět, o co jde.
A k vasi hvezdicce: scp ji vazne nikdy neexpanduje. Jenom ji preda bashi na druhe strane.Když se chcete nimrat v nepodstatných detailech (podstatné je, že hvězdičku nezpracuje shell, ale že ji dostane program na příkazovém řádku), dělejte to důsledně. SFTP bude zcela jistě fungovat i bez bashe na serveru.
Navic jste ji v prikladu mel u zdroje.Já jsem v příkladu hvězdičku v příkazu
scp vůbec nepoužil. Navíc u scp může být hvězdička vždy jen u zdroje, protože cíl je jen jeden argument. Podstatné je ale to, zda je to lokální cesta (které rozumí i shell), nebo vzdálená cesta (které ne každý shell rozumí).
Jak podotknul kolega, uz vymysleli tar.Jenže
scp umí kopírovat jen soubory, takže bych ty zdrojové soubory musel spojit do jednoho souboru, k čemuž nemusí být místo ani příležitost (třeba read-only médium). Samozřejmě existuje spousta různých způsobů, jak soubory okopírovat úplně jinak – ale proč, když existuje jednoduché a snadno použitelné scp?
Expanzi hvezdicky vzdy provadi bash.Asi mám kouzelný počítač.
bash nemám, a expanze hvězdičky funguje.
Neplette dohromady SCP a SFTP. To je jina vesnice.Ano.
scp je (v této debatě) program z balíku OpenSSH, který implementuje SFTP klienta.
Co ma spolecneho read-only medium a tar? Nikdy jste nevidel konstrukci tar -cf - soubor1 soubor2 .. souborN | ssh user@remote tar -xf - -C /remote/dir?A opačně, když chci přenést soubory ze vzdáleného počítače na lokální? Taky to napíšete z hlavy? Mimochodem, kde v tom vašem zápise vidíte použití příkazu
scp?
Psát z hlavy - to jste předpokládám nemyslel ten příkaz (který umí každý, je to klasika) ale myslel jména těch souborů na vzdáleném stroji?Příkaz, který v rámci jedno
ssh spojení na vzdáleném počítači zabalí soubory, pošle je na lokální počítač a tady je rozbalí? To z hlavy rozhodně nenapíšu (což samozřejmě není měřítko).
V souvislosti s tím bych ten limit nastavil nějak rozumně (vyšší)Abych pravdu řekl, nevím, jak zsh-completion (v mém případě) pracuje se spojeními při doplňování ze vzdáleného serveru (tedy jak moc si drží jednou otevřená spojení, a jak moc spoléhá na přístup „nevadí, klidně si připojím za chvilku znova“). Takže nevím, zda nastavení rozumného limitu pro práci by neznamenalo úplnou bezzubost takového opatření.
tar -cf - file1 file2 | tar -xf - -C dir tar -cf - file1 file2 | ssh user@hostname "tar -xf - -C dir" ssh user@hostname "tar -cf - file1 file2" | tar -xf - -C dirS tou bezzubostí máte pravdu, je to asi "buď recent, nebo bash-completion". Mnohem vhodnější bude modul na složitější hesla, jak jste navrhoval, a být připraven na zával žádostí o obnovu hesla :D
Expanzi hvezdicky vzdy provadi bash. At uz lokalni nebo vzdaleny.Jenom aby to někoho nemátlo, pokud se sem dostane: Expanzi na vzdáleném serveru samozřejmě neprovádí
bash ani jiný shell. Ono by asi bylo dost složité nebo spíš nemožné obecně z libovolného shellu v neinteraktivním režimu vymámit expanzi cesty s žolíky. Ve skutečnosti to, alespoň v implementaci SFTP serveru v OpenSSH, dělá funkce glob (3).
Tar spojuje zdrojové soubory do jednoho souboru. Je to vlastně jediná věc, co dělá (a dělá ji dobře). Proto jsem mluvil o vhodnosti jeho použití. Místo stačí mít na cílovém počítači, tam předpokládám je. Příležitost je právě teď.Je to trochu komplikovanější.
tar umožňuje spojovat soubory a standardní vstup, a výsledek uložit do souboru nebo na standardní výstup. Jenže příkaz scp umí pracovat jen se soubory, tudíž jako zdroj ani jako cíl nemůžete použít standardní vstup nebo výstup. Takže buď byste musel tarem soubory spojit do souboru (který musíte mít kam uložit), nebo můžete použít pojmenovanou rouru (to mi připadá kvůli překopírování souborů po síti trochu komplikovaný postup), nebo vůbec nepoužívat scp a poslat výstup z taru anonymní rourou do ssh. Jinak tar je samozřejmě vhodný nástroj, když to budete chtít třeba opakovaně pouštět ve skriptu. Když si ale nejprve odladím find, aby mi našel pár desítek správných souborů, tak pak na závěr akorát přidám -exec scp, a nebudu řešit, že je to neefektivní. Vy to evidentně chápete, alkoholik asi ne 
tar -cf - file1 file2 | scp /dev/fd/0 user@remote:/nejaka/cesta/soubor.tarcož je k mání někdy od roku jádra 2.4. Já bych ve všech zatím zmiňovaných případech použil to ssh :) ale pokud je někdo zvyklý na scp, jak říkám, ten limit chce mít rozumný, ne 3 pokusy a dost, ale třeba sto a chvíli pauza. A kdyby bylo jen po mém, tak bych limit nedával žádný, cítil bych se tím jen omezen, nikoliv chráněn. Na druhou stranu pokud bych věděl, že tam mám uživatele, kteří trvají na tom že musí mít hesla a ne klíče (protože třeba neví jak klíč uložit do mobilu), a věděl bych, jak asi jejich "hesla" budou vypadat, asi bych ten recent zvážil, s pocitem, že maj co si zaslouží :) Zabezpečení je stejně jako cokoliv vždy otázka určitého kompromisu, nejzabezpečenější počítač je nedostupný a nejde použít apod...
/dev/fd/0 mne vůbec nenapadla. Ale je na tom dobře vidět, jak je v unixu spousta možností, jak udělat jednu a tu samou věc. Myslet na to, že jednu variantu nemůžu použít – rovněž bych si připadal omezen, ne chráněn.
Na druhou stranu pokud bych věděl, že tam mám uživatele, kteří trvají na tom že musí mít hesla a ne klíče (protože třeba neví jak klíč uložit do mobilu), a věděl bych, jak asi jejich "hesla" budou vypadat, asi bych ten recent zvážil, s pocitem, že maj co si zaslouží :)V tom případě bych použil spíš PAM modul na vynucení kvality hesla. Aspoň by uživatelé rychle zjistili, jak ten klíč do mobilu uložit
No a nebo prostětar -cf - file1 file2 | scp /dev/fd/0 user@remote:/nejaka/cesta/soubor.tar
... | ssh host 'cat >soubor.tar'
/dev/fd/0 u nástroje, který umí pracovat jen se soubory, což bylo aktuální téma diskuze :)
Jste si jist, že všude, kde lze použít scp, lze automaticky použít i ssh?
cat > /home/abdaluhguldiwarth/presto/ese/meo/precnik/savemethere), což bylo rovněž horké téma.
tar
Pokud na počet souborů nestačí délka příkazové řádky, bude jich asi hodně, takže není chytré je posílat po jednom přes scp. Naštěstí byl vynalezen tar.
Zakazat prihlaseni roota primo je urcite vhodne.Zejména jako startovací bod pro diskuse o tom, proč je to k ničemu. Ale jak je vidět, kouzlo pořád funguje.
Ten port si staci dat do .ssh/config.
Klice jsou obecne lepsi nez hesla, ale pokud kopirujete neco ze vzdaleneho serveru na kterem se nejdriv musite prihlasit na roota, na jiny server, je to opruz. Jasne, jde to, ale je to opruz.
denyhosts/recent/fail2ban/sshguard ma tu vyhodu, ze pokud je adresa blokovana, tak chrani i pred chybami v ssh.
Povolit firewallem spojeni jen z nekterych adres je taky dobra soucast reseni. Pokud to zrovna vam nevyhovuje, ok, ale v kombinaci s VPN nebo pristupovym serverem se to pouziva bezne a ku prospechu veci, rekl bych.
Tiskni
Sdílej:
