Elmentek a felfedezők a Python bolygóra és mentek és csak mendegéltek, de egyszer csak...
...és akkor egyszer csak ott termett egy ajtó....
https://www.zdnet.com/article/malicious-python-libraries-targeting-linu…
Szeretnék rsync-et mélyebben használókkal körbejárni egy jelenséget, amibe most botlottam bele.
Egy szerver teljes mentése évek óta stabilan és megbízhatóan zajlik az rsync programmal.
Ám az éles szerveren egy letörölt mappa a backup területen továbbra is elérhető.
Az rsync root joggal fut, a következő kapcsolókkal:
rsync -aHvz --delete --numeric-ids root@{forrás} {cél}
Az rsync a másolás során a "cannot delete non-empty directory" hibaüzenetet adja, vagyis észleli, hogy a mappát törölnie kellene, de nem tudja, mivel annak tartalma van. A tartalma azonban csak két normál fájl, és innentől nem igazán értem a jelenség okát. Főleg azért, mert a teljes szerver mentésében ez az egyetlen ilyen hiba. Általában le tudja szinkronizálni a mappák törlését. A jogosultságok sem zavarhatják, mert root joggal fut.
Egyedüli érdekesség, hogy a törlésre került mappa szülőmappája az éles és a mentés szerveren is azonos dátumú. Pedig, ha egyszer törlésre került a szerveren a mappa, akkor a szülőmappa dátumának meg kellett volna változni. Vagy lehet, hogy azt leszinkronizálta az rsync, annak ellenére, hogy a benne lévő mappát nem tudta törölni?
Szükségessé vált, hogy Andriod alól ssh-n keresztül tudjak kapcsolódni több távoli géphez klienssel. Mivel korábban sikerült megégetnem magamat Androidos ssh klienssel, most kissé viszolyogva figyelem a Play által felkínált lehetőségeket. Annó, a fenekemet az mentette meg, hogy a távoli gépen sessiononként változó felhasználónévvel és jelszóval lehetett belépni, de a most nincs meg ugyanez a háttér.
Milyen ötleteitek vannak arra, hogy egy normál linux alaptelepítés eszköztárából felhasznált eszközökkel, az ember védve legyen egy megbízhatatlan ssh kliens általi adatszivárgás kivédésére? Hogyan konfigurálnátok fel egy ilyen rendszert? Milyen, általános, disztribúciók által szállított toolokat ismertek ilyen managementre?
Úgy tűnik, nem értem, az SSH hitelesítés folyamatát.
Egy szerver mentést állítanám vissza egy újratelepített szűz rendszerre úgy, hogy az új szerver is elérje azokat az ssh erőforrásokat, amiket a régi.
A probléma ott van, hogy már maga a mentés is SSH kulcs segítségével érhető el.
Az új rendszer feltelepítése után el kellene érnem, hogy kulccsal tudjam hitelesíteni az új szervert is a mentés szerverén.
Ehhez azonban tudnom kéne, az SSH mikor milyen kulcsot használ hitelesítéshez. Ez azonban nem sikerül.
A éles szerver root felhasználója készíti a mentést. A root felhasználónak nincs saját kulcsa, mégis be tud lépni a távoli mentés gépére egy egyszerű ssh paranccsal.
Az új gép root felhasználójának szintén nincs saját kulcsa, de nem tud belépni a mentéshez.
Gondoltam, ha nem a user kulcsával hitelesít az ssh, akkor a szerver valamelyik kulcsával. De ha a teljes /etc/ssh mappát átmásolom az új szerverre, akkor sem tudom elérni az új gépről a mentés szerverét. Mindig jelszót kér.
Ha naplózom az ssh kapcsolódást, a logban nem látom, melyik kulcsfájlt használja a hitelesítéshez. Egyik naplófájlban megjelent ugyan a sikeres hitelesítésről, hogy RSA és 16 bájt, de ebből sem tudom beazonosítani, melyik kulccsal hitelesít.
Hogyan állapíthatom meg, hogy a jelenlegi rendszer melyik kulcs használatával hitelesíti magát?
Sziasztok!
Otthoni házautomatizálás projekt kapcsán egy raspberry pi zero W-re domoticz-ot
tettem. Interneten bárhonnan szeretném elérni a pi-t is (ssh), és a domoticz-ot is.
Adta magát a tor onion hidden service, fail2ban-nal megspékelve.
A domo szépen elérhető, az ssh-t is beállítottam a tor-ban, viszont windows
alól putty-val hogy tudom elérni a toron osztott ssh-t? Belső hálón megy az ssh, ezen
matatom a pi-t.
Köszönöm,
Roland
A laptopom wincsesztere (1TB) kezd elhalni. Jelenleg két nem olvasható szektora van.
Bár mentés van az adatokról, jó lenne az egészet átmásolni egy új merevlemezre, és egyszerűen csak kicserélni.
Ehhez keresek Debian alól használható eszközt.
Amit tudnia kellene:
- A teljes lemez másolása, boot információkkal együtt. Bár a lemez a Debianban csak adatpartíciókat tartalmaz, van rajta egy Win10, amiről be lehet bootolni. Szeretném, ha ez a másolattal is működne.
- Elég sok üres hely van a lemezen, ezt jó lenne nem másolni.
- A hibás szektor a másolaton ne legyen hibás szektor.
- A két lemez nem tökéletesen egyforma, az újabb nagyobb picivel.
Ha még grafikus felülete is lenne, az szép lenne.
Ismertek ilyen direkt mentő programot linuxra?
Van egy távoli ssh elérésem egy mentés tárterülethez, amire rsync segítségével másolnék fájlokat.
Azt szeretném elérni, hogy a távoli területen valamilyen titkosítással tárolódjanak a fájlok.
A távoli fájlrendszerhez nincs további hozzáférésem, azon módosítani nem tudok, így gyanítom, vagy az rsync-nek kellene tudnom olyat mondani, hogy kódolva tárolja le a fájlokat, vagy valamilyen közbenső réteget, kódoló csatornát kellene kiépítenem.
Csinált már valaki ilyet? Van ötletetek, ezt hogyan tehetném meg?
Egy friss mod_security blokkol egy eddig jól működő weboldalt.
A naplók alapján egy coockie-ra illeszkedik a libinjection "sosks" fingerprint-je.
Még a libinjection forrásába is belenéztem, de nem találom, mit jelent ez az ujjlenyomat, milyen mintára illeszkedik az adott cookie, ami amúgy normálisnak, biztonságosnak tűnik.
ISSQL: libinjection fingerprint 'sosks' matched input 'a:2:{i:0;s:28:\"/cikkek/kategoriak/tartalom/\";i:1;s:5:\"index\";}'
Egyébként szinte minden más url-re is illeszkedik a minta. Érdekes azonban, hogy a nyitóoldali
a:1:{i:0;s:5:"index";}
cookie értékre nem illeszkedik. Talán a / jel lenne tiltott a cookie értékében a sosks szerint?
Tudja valaki, milyen minta ez, hogyan lehet megtalálni? Hogyan lehet kitalálni, mi nem tetszik neki ebben a coockie-ban?
Hi!
Néhány user gyenge jelszava kikerül, így szépen kiment néhány 1000 levél. Erre persze blokkoltak pár helyen, de egy címmel továbbra sem boldogulok, mert csak ennyit ír:
======================
(host mailgw8.chrobinson.com[168.208.16.177] refused to talk to me: 554-mailgw8.chrobinson.com 554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure is in error, please contact the intended recipient via alternate means.)
======================
Ötlet, hogy mit tehetnék, hogy a fenti címre újra tudjunk levelet küldeni?
A hibára persze jelszócsere, fail2ban na és persze felvilágosítás.
Előre is köszönöm az ötleteket!
Szerver: Ubuntu 18.04, 17.10-ről upgrade-elve, rajta FreeRADIUS 3.0
Szeretném a wifimet végre átállítani RADIUS-ra, első körben csak usernév-jelszó authentikációval.
Évekkel ezelőtt csináltam már ilyet, szerintem még 1.x verzióval (Tomato-ra telepíthető entware csomagból), akkor és ott, a default konfig... hát elég "érdekes" volt, az egyes protokollokat nekem kellett engedélyezni, elég könnyű volt elcseszni, ha valaki nem értett hozzá. Ráadásul valahogy sikerült úgy elkavarni, hogy végül üres usernév, üres jelszó párossal is beengedett volna az akkori router.
Jó lenne az ilyeneket elkerülni.
Ahogy elnézem, a 3.0-s FreeRADIUS konfigjában az egyetlen, számomra is feltűnő probléma, a kliens számára beírt testing123 jelszó, amit célszerű lesz megváltoztatni, pontosabban azt a klienst kidobni.
Ezen kívül tud valaki, valami ismertebb buktatóról?
Vagy elég a /etc/freeradius/3.0/users-be beleszerkeszteni a használni kívánt usereket, Cleartext-password-del és kész?
https://www.packet6.com/install-freeradius-ubuntu-server/ - ez volt, amit elsőre találtam, ez kb. semmi újat nem mondott, a komplett doksit meg most nem biztos, hogy időszerű előszednem, ahhoz már "idegállapotba kerültem" :)