Korábbi thread: https://hup.hu/node/188264 - csak éppen nem szúrta ki a szemem. Bocsi.
Engem nem érint, de hátha valamelyik HUP-os fórumtársat igen:
https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.o…
A következő AUR csomagokba kártékony kód került. Ha valaki frissítette ezeket júl 16. és júl 18. között, annak ajánlatos sürgősen újból frissíteni / eltávolítani:
- librewolf-fix-bin
- firefox-patch-bin
- zen-browser-patched-bin
A támadás klasszikus supply chain attack, a csomagok hátteréül szolgáló GitHub repó kompromitálódott, és oda került fel a trójai faló.
EDIT: nem tudom, hogy lehetne tömören beleírni a címbe, de megpróbáltam.
Ezt kaptam. Sajnálom, mert jó volt, most naptárazhatok. Tudom az acme script megújítja magától. Már ha összejön neki.
As a Let’s Encrypt Subscriber, you benefit from access to free, automated TLS certificates. One way we have supported Subscribers is by sending expiration notification emails when it’s time to renew a certificate.
We’re writing to inform you that we intend to discontinue sending expiration notification emails. You can learn more in this blog post. You will receive this reminder email again in the coming months:
https://letsencrypt.org/2025/01/22/Ending-Expiration-Emails
Here are some actions you can take today:
Automate with an ACME Client that supports Automated Renewal Information (ARI). ARI enables us to automatically renew your certificates ahead of schedule should the need arise:
https://letsencrypt.org/2024/04/25/guide-to-integrating-ari-into-existi…
Sign up for a third-party monitoring service that may provide expiration emails. We can recommend Red Sift Certificates Lite, which provides free expiration emails for up to 250 active certificates:
https://redsift.com/pulse-platform/certificates-lite
Opt in to emails. While we are deprecating expiration notification emails, you can opt in to continue to receive other emails. We’ll keep you informed about technical updates, and other news about Let’s Encrypt and our parent nonprofit, ISRG, based on the preferences you choose:
https://letsencrypt.org/opt-in/
All the best,
Let’s Encrypt
jopar eve tortent, lehet mar ~10 ?
vmelyik OpenBSD appot, talan sshd-t, pontosabban annak portjat vhogy elneztek
es a linuxokon randomness hiany lett a vege
barchoba go! :D
A 2013. évi L. törvény megköveteli, hogy az adatok olyan titkosítással legyenek titkosítva, ami megfelel a Poszt-kvantumtitkosítás követelményeinek:
poszt-kvantumtitkosítás: a matematikailag valószínűsíthetően igazolható, kvantumszámítógép által megvalósított támadás ellen a hagyományos kriptográfiai alkalmazáson felüli poszt-kvantum alkalmazást, illetve megoldást nyújtó titkosítás, amely során a két végpont közötti kommunikáció felhasználásával, az adatátvitellel megosztott kulcsot hoz létre a két végfelhasználó között, anélkül, hogy a kulcsot jogosulatlan harmadik fél megismerné;
Ilyen titkosítások léteznek már a gyakorlatban? Amiket találtam azok inkább POC-ok, meg tech-demok, meg hasonlók, mint gyakorlatban alkalmazható, supportált, stb megoldások.
Ha jól értem a törvényt, akkor ilyennel kell titkosítani az adatokat, valamint ilyen titkosítást kell alkalmazni a végpontok felé történő kommunikáció esetén is (IMAP, vagy HTTPS, stb).
Sziasztok!
Futtatok egy Drupal 7-es weboldalt. Ma az alábbi levelet kaptam emailben a Drupal 7-től:
"A Drupal alaprendszer telepített változatához biztonsági frissítés
érhető el. Erősen javasolt az azonnali frissítés a biztonságos
működés érdekében.
További információ az elérhető frissítések oldalán:
http://azenv.net/admin/reports/updates
A jelenlegi beállítások szerint minden új elérhető frissítés esetén
küldi a rendszer ezeket az e-maileket. Értesítés csak biztonsági
frissítésekről az alábbi címen kérhető:
http://azenv.net/admin/reports/updates/settings."
Ezzel csak egy probléma van, a levélben szereplő URL, vagyis a benne lévő azenv.net domain; és mondanom sem kell, hogy nem ez kellene, hogy ott legyen.
A Drupal 7 Nginx konfigjában szerepel az alábbi:
location ~ \.php$ {
include snippets/fastcgi-php.conf;
# Block httpoxy attacks. See https://httpoxy.org/.
fastcgi_param HTTP_PROXY "";
...
}
A weboldalt leállítottam, a logokat most nézegetem.
Láttatok már ilyet? Hogyan érhették el, hogy az emailben az azenv.net domain jelenjen meg? Feltörték a Drupal 7-es weboldalt, és esetleg a szervert is?
Korábban ilyen nem fordult elő, igaz két esetben volt, hogy üres URL-ek voltak a levélben, de annak nem tanúsítottam nagyobb figyelmet (sajnos).
"http:///admin/reports/updates
http:///admin/reports/updates/settings"
Van egy 2.3-as OpenVPN szerverem, amihez jelenleg egy 2.5-ös OpenVPN klienssel kapcsolódom sikeresen.
Gépköltözés miatt szeretnék egy már újabb verziójú, 2.6-os OpenVPN klienssel is felkapcsolódni. Mindkét kliens Debian Gnome alatti.
Az új gépen azonban nem épül ki a VPN kapcsolat. A szerver naplójában sokszor ismétlődő
MULTI: multi_create_instance called
Re-using SSL/TLS context
LZO compression initialized
Control Channel MTU parms [ L:1590 D:138 EF:38 EB:0 ET:0 EL:0 ]
Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Local Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Expected Remote Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-
Local Options hash (VER=V4): '1a6d5c5d'
Expected Remote Options hash (VER=V4): 'c6c7c21a'
TLS: Initial packet from [AF_INET]178.164.216.47:39311, sid=2440f1b9 47406e0dsorok után egyedül a
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failedhibaüzenetet találom. A szerver alapértelmezetten a BF-CBC cipher-t használta, ami már nem használható 2.6 alatt. Ezt átváltottam AES-256-CBC -re. A régi géppel így is rendben kiépül a kapcsolat, az új géppel így sem.
Mindkét gép ugyanarról a hálózatról próbál meg kapcsolódni, ugyanazokkal a paraméterekkel. (Természetesen a hitelesítési kulcsa a klienseknek egyedi.)
Ha lenne valakinek ötlete, hogy merre keressem a hibát, vagy hogy mire próbál utalni a hibaüzenet, azt örömmel olvasnám.
Megoldás: mind a kliens, mind a szerver konfigurációjában be kell állítani a "tls-version-min" értékét, ráadásul azonosra.
Most olvastam milyen csúnyán beszopott a CHS egy ransomware-t. Ha az adatok tárolására használt háttértár egy külön Linux szerveren futott volna ZFS fájlrendszerrel az teljeskörű védelmet jelentett volna ilyen esetre?
Fontos, hogy másik szerveren legyenek az értékes, pótolhatatlan adatok! Mert ha azonos szerveren vannak és már teljeskörű root jogosultságot szerzett a ransomware akkor elég egy zfs destroy a snapshotok legyalulására. Illetve itt konkrétan a CHS-nél Windows szerverek vannak, ami adott tényező. Szóval például hasonló esetben az SQL server háttértára mindenképp külső Linux szerver zfs partíciójára kell, hogy kerüljön. Illetve ha az alkalmazásszerver tárol fontos adatokat az is.
A backupok pedig értelemszerűen szintén a Linux szerver ZFS partíciójára mennek.
Firefox böngészőt használok, és szeretném elérni, hogy a weboldalak ne ajánlgassák örökkön, az értesítéseikre való feliratkozás lehetőségét.
A beállításokban találtam egy olyan lehetőséget, hogy az új értesítéseket blokkolja, de mégis rendszeresen jönnek fel ilyen kérdések. Akkor is, ha nemmel válaszolok. Van olyan pofátlan oldal is, ahol az elfogadás melletti másik lehetőség a "majd később", nemet nem is lehet mondani.
Lehet ezeket teljesen, globálisan blokkolni? Ha igen, hogyan?