Linux-security

https://www.microsoft.com/security/blog/2022/04/26/microsoft-finds-new-…

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29799

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29800

fstab-ba "nosuid" és "chmod -R -s /" kiadása vajon mennyire tud rosszat tenni egy kiszolgálón? :D előtte max lementeni a permissionoket:

find / -type f \( -perm -4000 -o -perm -2000 \) -exec ls -1 {} \; | while read oneline; do perl -e 'printf "chmod %04o \"%s\"\n", (lstat)[2] & 07777, $_ for "@ARGV"' $oneline; done > $(date +%F-%Hh-%Mm-%Ss)-hardening-permission-backup.txt

HUP cikket is megérne, de nem vagyok annyira kreatív: https://www.bleepingcomputer.com/news/security/linux-system-service-bug…

Már több bejegyzés volt crypto témában, járatosak vagytok/lehettek benne. Hátha van erről is véleményetek.

Electrum nevű cold-wallet-et szeretném használni, nem túl csilivili, hittel vagyok iránta, hogy csak azt csinálja, amit kell. A wallet létrehozásakor a 12 szavas listát legépelteti velem, megerősítéskor bekéri, egyik helyen sem megy a copy és paste. A végén azonban a wallet leíró fájlban ez az infó is benne van simán olvashatóan! (Hibáztam a tesztnél, mert nem adtam jelszót a walletnek, lehet akkor nem lehetne olvasni). Viszont sehol nem hívja fel a figyelmet a priv+public key mentésére, bár ezek is kinyerhetőek az infó fülön.

A szerverek ahova csatlakozikm elég furcsák, amolyan geek/warez/ncore világban érzem magam. Ilyen szerverekhez csatlakozik, a no-ip.biz-t külön kiemelném:

    "electrum.coinext.com.br:50002:s",
    "xtrum.com:50002:s",
    "dxm.no-ip.biz:50002:s",
    "ex04.axalgo.com:50002:s",
    "electrum.bitkoins.nl:50512:s",
    "electrum.hsmiths.com:50002:s",
    "178.62.80.20:50002:s",
    "btce.iiiiiii.biz:50002:s",
    "elx.bitske.com:50002:s",
    "ex.btcmp.com:50002:s",
    "hodlers.beer:50002:s",
    "188.230.155.0:50002:s",
    "electrum.qtornado.com:50002:s",
    "electrumx.erbium.eu:50002:s",
    "electrum.blockstream.info:50002:s",
    "electrum.emzy.de:50002:s",
    "fortress.qtornado.com:443:s",
    "bitcoin.aranguren.org:50002:s",
    "blockstream.info:700:s"
 

Kraken és BitPanda a bróker, ahol van wallet-em (ezekkel próbálkozom most jelenleg). Ezek az online wallet-ek felhasználóbarátabbak mint ez az electrum hardcore cold wallet. Ha anyámnak kellene gépén electrumot használnia, kezelnie, nemelvesztenie, nemletörölnie, akkor soha nem terjedne el a crypto. Mondjuk a bummerek (beleértve engem is (M42)) nem túl nyitottak ebbe az irányba. Majd ha a fizetésüket ide kapják...

Egy HW wallet még nekem is sok: van rajta kijelző meg minden, de ha lemerül? Vagy onnan is ki lehet menteni a priv/pub kulcsokat?

Szóval mennyire láttok Ti (is) kockázatot egy ilyen software-es cold-wallet-ben?

Ma reggel meghalt a PowerDNS névszerverem. A jelenség: nem old fel semmilyen nevet. A másodlagos névszerver - az is pdns - szintén.

A naplóban semmilyen érdemi információ nincs:

 systemd[1]: pdns.service: Main process exited, code=exited, status=1/FAILURE
 systemd[1]: pdns.service: Unit entered failed state.
 systemd[1]: pdns.service: Failed with result 'exit-code'.

Gyakorlatilag ennyi, és semmi más hibaüzenet. Próbálja magát újraindítani, de mindig csak erre jut.

Mint kiderült, "etikus hackerek" teszteltek egy domaint, aminek csak a névszervere van a gépen. (Többet egyelőre nem tudok a tesztelés mikéntjéről.) Leállították a tesztet, azóta békesség, minden megy, mint békeidőben.

A legfőbb kérdésem: hogyan tudnám elkerülni, hogy a PowerDNS-t ilyen könnyen le tudják ölni? 8 magból maximum 4 volt terhelés alatt, disk és RAM is volt bőven, mégis kifeküdt.

Másodszor az is zavar, hogy gyakorlatilag semmilyen értelmes infót nem tudtam kinyerni a PowerDNS logjaiból, sem a webes monitor felületéből. Ha bárkinek van értelmes ötlete, hogy mit kellene/kellett volna használnom hogy kritikus esetben több információt láthassak a DNS folyamatról, azt is megköszönném.

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:

• gazdaságosan: FTP backup
• redundánsan: 3 földrajzilag máshol lévő FTP
• biztonságosan: fájlonként gpg-vel titkosítom a fájlokat, amiből ha törölni kell, név alapján egyértelműen megtalálható, nem kell tar.gz-t megbontani.

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?

https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/