Sziasztok!
Nem tud véletlenül valaki jó megoldást egy régi (0.5) nft és 4.1.15-ös kernel esetében syn-flood ellen ?
A limit rate x/minute nem működik megfelelően.
Próbáltam csak a syn packeteket korlátozni, de nem működik.
A limit rate x/second ICMP esetében megy.
Minden segítséget előre is nagyon szépen köszönök!
Sziasztok
Időszakosan kis példányszámú fájlokat kell letárolnom automatizálva redundánsan, gazdaságosan, biztonságosan. Adott fájlból több verzió nem kell, viszont a backup hétről-hétre új fájlokkal fog bővülni.
Ezekből időnként automatizálva törölnöm is kell illetve dedikált mappát visszaállítani. Simán lehet, hogy több tucat fájlt 20 évig múlva kell tervezetten visszaállítani.
Gondolatmenetem:
Mindezt bash script ütemezetten végzi.
A kérdés, hogy van-e jobb, értelmesebb megoldás? (Felmerült itt duplicity meg encfs cryptált mappája menjen ftp-re, végül ez tűnt legkonzervatívabbnak, mert fontos, hogy 20 év után is vissza lehessen állítani.)
A fő kérdés, mivel gpg-vel így még nem foglalkoztam, nem hibádzik-e semmi a jövőre nézve?
# gpg --full-generate-key
paranccsal generálok egy kulcspárt, ahol jelszónak semmit nem adok meg az automatizálhatóság miatt.
# gpg --output public.pgp --armor --export USERNAME
# gpg --output privat.pgp --armor --export-secret-key USERNAME
parancsokkal exportálom és jól elteszem több biztonságos helyre a kulcsokat tartalékba.
# gpg --encrypt -r USERNAME teszt.txt
# gpg --decrypt -o teszt.txt teszt.txt.gpg
parancsokkal titkosítom a kívánt fájlokat majd lftp-vel feltöltöm az FTP szerverekre. Igény esetén a visszaállítandót visszanyerem a decrypttel.
Szóval ez így rendben van a következő 10-20 évre vagy van benne olyan buktató, amit esetleg nem látok?
Köszönöm!
Egy XPenology-t futtató NAS-t megevett regglre egy Linux/Filecoder.ECh0raix nevezetű trójai.
Minden fájlnév végéhez került egy .encrypt kiterjesztés, a fájlok mellett pedig egy README_FOR_DECRYPT.txtt fájlban az "instrukciók"
Van erre valami gyógyszer? Gondolom, ha fizetne is valaki, akkor sem történne semmi.
(az "állítsd vissza biztonsági mentésből" jellegű kommenteket kérem mellőzni)
További információk: https://hup.hu/comment/2659697#comment-2659697
Sziasztok,
Masodlagos rendszerbe torteno authenikaciohoz keszulo egyedi azonosito "salt" -ja lenne a jelenlegi authentikalt ssh sessionhoz tartozo pubkey. Mivel az ~/.ssh/authorized_keys tobb publikus kulcsot is tartalmazhat, igy szeretnem visszakapni vagy magat a pillanatnyilag hasznalt kulcsot, vagy az emlitett fajlban talalhato poziciojat.
Szerintetek hogyan kaphatnam ezt vissza?
Sziasztok!
Nem újdonság, hogy próbálják feltörni a weboldalunkat, de a tegnapi Logwatch üzenet egy kicsit elgondolkodtatott:
--------------------- httpd Begin ------------------------
A total of 1 possible successful probes were detected (the following URLs
contain strings that match one or more of a listing of strings that
indicate a possible exploit):
/index.php?option=com_b2jcontact&view=loader&type=uploader&owner=component&bid=1&qqfile=/../../../Raiz0WorM_1620790849.php HTTP Response 200
---------------------- httpd End ------------------------- PHP log:
- - 12/May/2021:05:43:29 +0200 "POST ?option=com_b2jcontact&view=loader&type=uploader&owner=component&bid=1&qqfile=/../../../Raiz0WorM_1620790849.php" 200 /var/www/drupal/index.php 414.896 18432 69.90% - - 12/May/2021:05:43:59 +0200 "POST ?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form%22" 200 /var/www/drupal/index.php 469.983 14336 68.09%
Webszerver log:
20.98.105.13 - - [12/May/2021:05:43:29 +0200] "POST /index.php?option=com_b2jcontact&view=loader&type=uploader&owner=component&bid=1&qqfile=/../../../Raiz0WorM_1620790849.php HTTP/1.1" 200 8002 "-" "python-requests/2.25.1"
Webszerver log az érintett IP-ről: https://pastebin.com/fDgi4Mb2
Az érintett rendszer: Debian 10 + Drupal 9.1, kezdjek aggódni?
Vagy ez a támadás egy sérülékeny WP esetén lenne hatásos?
Sziasztok,
Eddig a szervereimen letsencrypt-et használtam, de most van egy aminek gogetssl-től vásárolt certificate-et kellene beállítanom.
Csináltam egy privát kulcsot amiből generáltam egy csr file-t. Ezt elküldtem az ügynöknek, aki visszaküldött egy zipet amiben mindösszesen két file van:
domain.ca-bundle (ez két begin end certificate részt tartalmaz)
domain.crt (egy begin end certificate)
A .crt-t le tudtam ellnőrizni a openssl x509 -text -noout -in domain.crt paranccsal, látszanak benne a következő adatok:
- Issuer: GoGetSSL
- validity: from-to dátum
- Subject: CN=domain
A szerveren Debian stable fut. Hogy kell ebből nginx alá kulcsokat generálni?
köszi,
Zamek
miért vették le a kernel.org-ról és miért nincs erről infó?
Nem olvastam, hogy lett volna hír róla, itt a hupon. Esetleg van valakinek bővebb infója?
https://biztonsagportal.hu/igy-leplezi-magat-egy-linuxos-trojai.html
Any unprivileged user can gain root privileges on a vulnerable host.
10 éves bug, részletek itt.