Thunderbird biztonsági frissítés.

Az LMDE3 alatt:

sudo apt-get update

sudo apt-get upgrade
Csomaglisták olvasása... Kész
Függőségi fa építése       
Állapotinformációk olvasása... Kész
Frissítés kiszámítása... Kész
Az alábbi csomagok frissítve lesznek:
  calendar-google-provider lightning lightning-l10n-hu thunderbird
  thunderbird-l10n-hu
5 frissített, 0 újonnan telepített, 0 eltávolítandó és 0 nem frissített.
Letöltendő adatmennyiség: 38,0 MB.
A művelet után 181 kB lemezterület kerül felhasználásra.
Folytatni akarja? [I/n] i

Forrás: Debian Security levelezési lista

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- -------------------------------------------------------------------------
November 10, 2018                     https://www.debian.org/security/faq
- -------------------------------------------------------------------------

Package        : thunderbird
CVE ID         : CVE-2018-12389 CVE-2018-12390 CVE-2018-12392
                 CVE-2018-12393

Multiple security issues have been found in Thunderbird: Multiple memory
safety errors may lead to the execution of arbitrary code or denial of
service.

For the stable distribution (stretch), these problems have been fixed in
version 1:60.3.0-1~deb9u1.

We recommend that you upgrade your thunderbird packages.

For the detailed security status of thunderbird please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/thunderbird

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/

#7 Az unattended-upgrades? ... én csak nyomok naponta többször egy-(egy) frissítő parancsot.
Fel tudsz iratkozni a Debian Security listára, akkor értesítőket fogsz kapni.
Szívesen. :-)

#6 Köszi, tényleg fontos, igaz nem LMDE3, de Bunsenlabs, frissitettem.

#9 Az nem tudom, hogyan csinálta. :-)
Nálam:

Start-Date: 2018-11-10  23:28:44
Commandline: apt-get upgrade
Requested-By: kim (1000)
Upgrade: thunderbird-l10n-hu:amd64 (1:60.2.1-2~deb9u1, 1:60.3.0-1~deb9u1), lightning:amd64 (1:60.2.1-2~deb9u1, 1:60.3.0-1~deb9u1), thunderbird:amd64 (1:60.2.1-2~deb9u1, 1:60.3.0-1~deb9u1), lightning-l10n-hu:amd64 (1:60.2.1-2~deb9u1, 1:60.3.0-1~deb9u1), calendar-google-provider:amd64 (1:60.2.1-2~deb9u1, 1:60.3.0-1~deb9u1)
End-Date: 2018-11-10  23:28:57

Jelenleg elérhető csomagok:

apt-cache policy thunderbird
thunderbird:
  Telepítve: 1:60.3.0-1~deb9u1
  Jelölt:    1:60.3.0-1~deb9u1
  Verziótáblázat:
     1:60.3.0-1 100
        100 http://ftp.us.debian.org/debian testing/main amd64 Packages
          1 http://http.debian.net/debian unstable/main amd64 Packages
 *** 1:60.3.0-1~deb9u1 700
        700 https://deb.debian.org/debian-security stretch/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1:60.2.1-2~deb9u1 700
        700 https://deb.debian.org/debian stretch/main amd64 Packages

#8 Az unattented-upgrades nálam a Debian testing (buster)-en müködik. Megnéztem a historyban nov 7.én frissitett a  60.3.0.1-re

#11 A preferences fájlomban lehet a „hiba”. Valahol mindkettőnknek igaza van:

news: https://tracker.debian.org/pkg/thunderbird

• [2018-11-10] Accepted thunderbird 1:60.3.0-1~deb9u1 (source) into stable->embargoed, stable (Carsten Schoenert)
• [2018-11-06] thunderbird 1:60.3.0-1 MIGRATED to testing (Debian testing watch)
• [2018-11-01] Accepted thunderbird 1:60.3.0-1 (source) into unstable (Carsten Schoenert)

Nem tudom de:

Start-Date: 2018-11-07  08:13:01
Commandline: /usr/bin/unattended-upgrade
Upgrade: thunderbird-l10n-hu:amd64 (1:52.9.1-1, 1:60.3.0-1), lightning:amd64 (1:52.9.1-1, 1:60.3.0-1), thunderbird:amd64 (1:52.9.1-1, 1:60.3.0-1)
End-Date: 2018-11-07  08:13:11

@#22 Szerintem, át kell kapcsolni más NAT kapcsolatra vagy frissíteni az újabb VB verzióra.

Új kriptobányász malware ütötte fejét, amely a Linux-alapú rendszereket veszi célba. Az élelmes Linux.BtcMine.174 kártevőt az orosz Dr.Web biztonsági cég szakértői fedezték fel, a rosszindulatú szoftver amellett, hogy egy sor, a hálózatra csatlakozó eszközt képes megfertőzni, akár a biztonsági szoftvereket is lekapcsolhatja.

A malware több komponensből áll: az első az adott rendszerre kerülve keres egy nem írásvédett könyvtárat, ahová a később letöltött modulok kerülhetnek. Ezt követően a nohup paranccsal újraindítja magát daemonként - ha pedig a nohup parancs nem található meg az adott rendszeren, a kártevő maga telepíti az azt tartalmazó coreutils csomagot. Ha mindez megtörtént a rosszindulatú szoftver a Dr.Web által Linux.BackDoor.Gates.9 néven emlegetett trójai letöltésével folytatja, amely egy sor ismert biztonsági rést tartalmaz, amelyeken keresztül a támadók parancsokat futtathatnak a rendszeren, vagy akár DDoS támadáshoz is csatasorba állíthatják azt. Amennyiben a Linux.BtcMine.174 nem root jogosultságokkal jut az adott rendszerre, több sebezhetőséget is végigpróbál jogosultságainak feltornázására. Ezek között ott van az Android által is megörökölt, linuxos DirtyCow biztonsági rés is.

...

Miután a malware berendezkedett, elkezd rivális kártevők után kutatni az adott gépen, és ha ilyet talál, leállítja a hozzájuk tartozó folyamatokat. Ezt követően biztonsági szoftverek után is elkezd kutatni, és ha azokhoz köthető nevű futó szolgáltatást talál, mint például a safedog, aegis, yunsuo, clamd, avast, avgd, netán esets, nem csak leállítja azt, de a csomagkezelővel el is távolítja a elcsípett vírusirtót a gépről, annak telepítési könyvtárával együtt.

Ha a konkurenciát és a rendszer védelmi vonalait kiiktatta, a malware hozzáadja magát az automatikusan induló alkalmazások listájához, illetve egy rootkitet is elindít. Utóbbi modul képes a su parancshoz megadott felhasználói jelszavak begyűjtésére, valamint igény szerint fájlokat, futó folyamatokat és hálózati kapcsolatokat is el tud rejteni. A trójai az adatok birtokában terjeszkedni is megpróbál azokra az eszközökre, amelyekkel az adott rendszer korábban SSH kapcsolatot létesített.

Végül kártevő elindítja a kriptobányász-modulját az eszközön, amellyel a fertőzött gép erőforrásait használva Monero kriptovalutát igyekszik gyűjteni - és amelynek aktivitását percenként ellenőrzi, így ha kell, újra tudja indítani a bányászt. Mindeközben a malware a vezérlőszerverrel is tartja a kapcsolatot, ahonnan igény szerint frissítéseket is letölt. A Dr.Web GitHub oldalán közzétette a kártevő egyes komponenseinek SHA1 hash-eit, illetve az érdeklődők számára részletes leírást is közölt a fertőzés folyamatáról. Azt egyelőre nem tudni, hogy a kártevő eddig hány eszközt fertőzhetett meg.

Forrás: https://www.hwsw.hu/hirek/59677/linux-kriptobanyasz-malware-monero-karte...

-----

https://www.youtube.com/watch?v=cBGR0_xIEbo
A villámokban nincs kímélet
A hullámok a partra törnek
Tépi a szél és mossa eső
És mégis ott marad helyén a kő ...

#28 Mostanában gondolkodom, hogyan lehet törölni a Chrome böngészőt a telefonomról. Rendszer szolgáltatás (Flyme OS), a netre kijutását a beállításokban tiltom. Amúgy a Google engem is profiloz, mert szinte csak GMail-es címeim vannak ..., és ezeket jó ideje használom.
De az appoknál a Chrome kicsit „csípi a szemem”, habár telepítettem Firefox-ot és azt használom. Más megoldáson is gondolkodom, mármint a Google Áruház és más Google App-ok eltávolításán is (de van saját OS áruház is, az sem feltétlen kéne). Meg amúgy kifizetném pl. az OsmAnd alkalmazást (támogatás címén, mert kell az ilyesmi ..., most nem akciós sajnos, de annyira ez nem számít), ám nem szeretnék a Google Áruházon keresztül fizetni. Tudom, F-Droid, de át kell gondolni alaposan, mit csinálok végül és azt hogyan. És még körbekérdezek ez ügyben, épp tegnap vetettem fe a témát a Szabad Szoftveres Soirée találkozón, de van ismerősüm, aki nem volt ott és tanácsot adhat. A GMail-es címeimmel nem tudok mit csinálni.

A közelmúltban megjelent új Chrome, a 69-es akkor is belépteti a felhasználót a böngészőbe, ha ő azt nem akarja. Ha ugyanis a felhasználó elkezd használni egy webes Google-szolgáltatást, amihez kell a Google accountja, például belép a Gmailbe, akkor azzal egyben a különböző eszközökön a Chrome böngészőt szinkronizáló Syncbe is automatikusan bejelentkezik. Ez akkor is így történik, ha a böngésző első indításakor ezt a lehetőséget a felhasználó kifejezetten elutasítja. A böngésző még akkor sem figyelmeztet, amikor megtörténik a beléptetés, azaz gyanútlan emberünk abban a tudatban kattingat a neten, hogy arról a Google nem gyűjthet adatokat...

 

https://bitport.hu/furcsan-kezeli-a-felhasznaloit-az-uj-chrome-erre-erde...

Egészen pontos helyadatokat gyűjt be az IBM által 2015-ben felvásárolt The Weather Channel a felhasználóiról, de Los Angeles városi ügyésze szerint a cég nem csak az időjárás-előrejelzéshez használja azokat, hanem azok elemzéséből és értékesítéséből húz hasznot.

Panaszt nyújtott be a kaliforniai felhasználók nevében Los Angeles városi ügyésze, Michael Feuer az IBM tulajdonában lévő The Weather Channel (TWC) ellen. Az irat alapján az alkalmazás évek óta percre pontosan, éjjel-nappal követi a felhasználók geolokációs adatait, méghozzá akkor is, mikor éppen nem az időjárás-jelentő szolgáltatást használják. Az app a személyre szabott, helyi időjárás-jelentési adatok, figyelmeztetések és előrejelzések céljából kér engedélyt a helyadatok követésére iOS-en és Androidon egyaránt.

Azonban az ügyész szerint a vállalat a helyadatokat más cégeknek, többek közt hirdetőknek értékesíti pusztán monetizációs érdekből, függetlenül az időjárás-jelentő alkalmazástól. Mindez a benyújtott panasz indoklása alapján tisztességtelen üzleti gyakorlatra vall, amelynek az ügyész a megszüntetését követeli a kaliforniai versenyjogi törvényre hivatkozva, egyúttal pedig bírság kiszabását is kéri az eddigi megtévesztő tevékenység miatt, méghozzá jogsértésenként (érintett felhasználónként) 2,5 ezer dollár mértékben.
... https://www.hwsw.hu/hirek/59824/ibm-the-weather-channel-panasz-los-angeles.html

Sokat érhetnek a pontos helyadatok

A TWC az adatokat nem csak az IBM leányvállalatainak, hanem más cégeknek is továbbküldi hirdetési, kereskedelmi és egyéb célokból - szerepel a panaszban. Méghozzá a kaliforniai ügyész értesülése szerint a TWC az elmúlt 19 hónapban legalább egy tucat cégnek értékesítette a helyadatokat, amelyből a vállalat rendszere különböző fogyasztói magatartási mintázatokat, "rituálékat" is képes kiolvasni. Az app ugyanis tisztában van a felhasználók lakóhelyével, munkahelyével, napközben és éjszakai látogatásaival, illetve hogy mennyi időt töltöttek egy adott helyen - sorolja az irat.

Ezekből az információkból pedig könnyedén elemezhetők a szokások, a preferenciák, sőt akár még a személyeket is lehet azonosítani. Egy konkrétan említett esetben például az IBM a fiatal felnőtteket célozta meg a McCafé kávéajánlataival a lokációs adataik alapján. A hirdetési célokon kívül továbbá a cég például a fogyasztói magatartás iránt érdeklődő fedezeti alapokat is kiszolgált a helyadatokkal Los Angeles ügyésze szerint.

Az IBM szóvivője cáfolja a vádakat, elmondása szerint a TWC teljesen átlátható módon kommunikál a lokációs adatok felhasználásáról, az app szabályzataiban közöltek helytállóak, amelyhez a cég következetesen tartja magát - nyilatkozta többek közt az Ars Technikának. A kaliforniai panasz viszont vitatja az átláthatóságot, mivel az app leírásában nem szerepel, hogy a helyadatokat az időjárás-előrejelzés mellett másra is használja. Ez az információ csak az adatvédelmi irányelvekben és az adatvédelmi beállítások közt jelenik meg, amely már valóban utal az adatok "esetleges továbbítására" harmadik fél számára és a kereskedelmi felhasználásra.

Az ügyész szerint viszont ennél sokkal többről van szó, hiszen a helyadatok begyűjtésének maximalizálása, továbbá értékesítése hirdetési és kereskedelmi célokból a The Weather Channel fő üzleti modelljének része, ami viszont a helyi versenyjogi törvénybe ütközik. A panasz és a követelés mindenesetre csak a kaliforniai felhasználókra vonatkozik, más országok érintettségéről nincs információ.

#39 Korrigáltad a tartalmat, így én is hozzáfűzök egy videót:
http://szamitastechnika.network.hu/video/erdekessegek/ezert_tiltsd_le_a_...
Ki van mostanában biztonságban? A módszerek rejthetőek ... .
Az Apple persze, hogy sebezhető. Az App áruház viszont vélhetően jobban védett, mint a Google áruház. No meg, elég erősen ellenkeznek, ha ügyfél adatokat kell kiadni ..., ha hinni lehet annak, amit mondanak.

Az e-mail címem három helyen érintett. Adobe, Linux Mint, Dropbox. Amúgy aki ilyen "kétes" hírű domainekkel rendelkező oldalakon jár, az meg is érdemli. Egyébként, ha már biztonság. Az ebből a szempontból magát érinthetetlennek tartó Apple MacOs sem támadhatatlan. https://blog.malwarebytes.com/threat-analysis/2018/09/mac-app-store-apps-are-stealing-user-data/ A legszebb az egészben, hogy ismert antivírus cég érintett. https://blog.trendmicro.com/answers-to-your-questions-on-our-mac-apps-store/

#44 A Digi sem figyelmeztetett, hogy a X. kerületben folyó munkálatok elhúzódnak és ez hatással lesz pár környéki kisvárosra, kerületre, például ide is, ahol lakom. Elment a TV adás. Csak azért volt érdekes, nert éppen néztem valamit, amit nem sokszor teszek meg. Mindenre gyanakodtam, de erre nem, főleg a rendszeremre gyanakodtam, aznap telepített alkalmazásokra, stb.. Film nélkül feküdtem le, nem láttam, csak az első két részt, a harmadikat nem.
Mindenesetre nekem a net nem ment el, így el tudtam volna olvasni amit ők a neten közöltek, hogy 1-2 órás karbantartás lesz ... ami miatt nem lesz net. Vicces. :D
Lehetett volna SMS-t küldeni, mint ... (hóhelyzet). ;-)
Érdekes dolgok ezek, mi vagyunk lassan a szolgáltatókért, és nem ők értünk.

#43 Látod, a példa mutatja, az Apple áruház sem jobban védett mint a Google Play, csak annyi a különbség, hogy a közhiedelemmel ellentétben a telefonokon ezek még kevésbé hatékonyak. Egyébként ebben a "kedves" rendszeralkalmazás által okozott történetben érintett voltam. Egyszerűeb eltűntek az előzmények Safariban. Az alkalmazást az áruházból töltöttem le. Az Apple nem volt olyan kedves, hogy figyelmeztessen, hogy távolítsam el, miután kidobta az Apple Store-ból. https://www.reddit.com/r/MacOS/comments/acbgfq/more_and_more_adware_on_mac/

Kadlecsik Józsi bejelentése szerint megszűnt a KFKI-s Ubuntu mirror, így akik ezt használták frissítési forrásként, hibaüzenetet kaphatnak:

Teendők a hiba elhárítására:

Linux Mint alatt egyszerűen át kell állni egy másik gyors tükörre (lehetőleg ne magyarra, mert ezek a terhelés miatt elég sokszor elérhetetlenek), és a csomagforrásokat frissíteni.

A jelek szerint a cégek és szervezetek vezetőit hidegen hagyja az, hogy évek óta létezik egy keresőoldal a neten, ami jelszóval nem védett adatok között keres: a Shodan például webkamerák képernyőképeit is megtalálja, amik készülhettek nappali szobákban, éjszakai bárokban vagy éppen erőművekben... Keleti Arthur IT biztonsági szakértő megmutat pár ilyen képet, amelyek segítségével immár szafari-jellegű kirándulást is tehetünk (pl. "íme, a meglátogatott helyszínen is van egy nyitva hagyott kamera, nézzünk be!"). A helyzet aggályos és mégsem lép fel senki az oldal leállításáért. (PosztmodeM, 2019.01.29/6.)

https://youtu.be/Vi9RSGJd3KM

https://itcafe.hu/hir/google_jelszo.html

Újabb biztonságtechnológiai megoldást fejlesztett a Google, a Chrome böngésző bővítményeként működő Password Checkupot.

A vállalat hivatalosan is bejelentette két új fejlesztését, az egyik a Password Checkup, melynek használata során azonnal figyelmeztetést kapunk, ha olyan jelszót használnánk, ami már egyszer hackerek kezébe került. A másik friss Google újítást, a fiókokon átívelő védelmet (Cross Account Protection) pedig arra tervezték, hogy figyelmeztető jeleket küldjön és fogadjon kompromittálódott jelszavak használata esetén.

A biztonságosabb internet napjára időzített bejelentés szerint a bővítmény használata rendkívül egyszerű: nyissuk meg a Chrome-ot a számítógépünkön, majd a Google-fiókunkba való bejelentkezés után, töltsük le a Password Checkup bővítményt. Ezt követően kattintsunk a jobb felső sarokban található ‘Továbbiak’ menüpontra, keressük meg a bővítményt és kapcsoljuk be. Innentől kezdve értesítést kapunk, ha bejelentkezéskor olyan felhasználónevet és jelszót adunk meg internetes online fiókjainkba, amelyek egy, a Google által ismert adatvédelmi incidens miatt már nem biztonságosak. Ilyen esetben a Google kérni fogja, hogy módosítsuk jelszavunkat, hogy fiókunk újra biztonságossá váljon. A fejlesztők ajánlása szerint a telepítést érdemes az okostelefonunkon, illetve bármilyen más csatlakoztatott eszközünkön elvégezni.

Kiemelik, hogy az adatok többszöri titkosításon mennek keresztül, így a fiókazonosító adatokra (felhasználónév és jelszó) senki, a Google sem lát rá.

A Google másik újítása, a több piaci szereplővel közösen fejlesztett fiókokon átívelő védelem (Cross Account Protection) a háttérben értesítést küld az incidensről más alkalmazás fejlesztőinek, akik megtehetik a szükséges óvintézkedéseket, mint például a felhasználó kiléptetése.

@#57 Úgy szokták, hogy készül egy nagyon friss backup, arról meg egy hálózattól elzárt tárhelyre pl. napi egy másik backup. És ekkor a levelek zöme megmarad, csak egy napi levelezés vész el. Itt a szolgáltató eléggé elszúrta. Más kérdés, a rosszfiúknak miért csípte a szemét a szolgáltatás. Nem is értem.

Várhatóan 2020-ban lép hatályba a GDPR-t kiegészítő ePrivacy rendelet, mely az elektronikus hírközlési adatvédelmi irányelvet felváltó, új európai uniós szabályozás. Elsődleges célja az elektronikus kommunikáció és az azzal kapcsolatban keletkezett adatok védelme, ... https://www.portfolio.hu/vallalatok/a-gdpr-nal-is-nagyobb-kihivas-var-a-vallalkozasokra-jon-az-eprivacy.314513.html

Az Európai Tanács már 2017 végén bemutatta az ePrivacy rendelet tervezetének szövegét, de az eltérő tagállami álláspontok miatt viták alakultak ki a végleges verzióról, így a rendelet - az eredeti tervekkel ellentétben - nem lépett hatályba a GDPR-ral párhuzamosan. Tartalmával kapcsolatban elsősorban az amerikai technológiai óriások (Google, Facebook, Amazon stb.) fogalmaztak meg komoly kritikákat, hiszen igen érzékenyen érintené az új szabályozás az adatokra épülő üzleti modelljüket, így minden lobbierejüket bevetve igyekeznek megakadályozni, de legalábbis késleltetni, a rendelet elfogadását. A román soros elnökség azonban kiemelt prioritásként kezeli a rendelet szövegének az európai parlamenti választás előtti véglegesítését, így az legkésőbb 2020-ban hatályba léphet. A GDPR felkészülés tapasztalataiból kiindulva érdemes már most elgondolkodni azon, hogy milyen következményekkel jár a rendelet elfogadása a vállalatokra nézve.

Míg a GDPR általános adatvédelmi szabályokat, alapelveket fogalmaz meg, addig az ePrivacy részletes szabályokat tartalmaz az email-ek, smsek, chat- és üzenetküldő szolgáltatások, metaadatok, cookie-k, spamek, direkt marketing szolgáltatások, illetve a végeszközön tárolt adatok tekintetében. Talán a legjelentősebb változás a metaadatok, illetve a sütik (cookie-k) körében várható, hiszen a metaadatokat az új szabályok értelmében úgy kell kezelni, mintha azok különleges személyes adatok lennének, illetve sütik használata is csak a felhasználó aktív beleegyezésével történhet.

A szabályozás újdonsága az is, hogy - a GDPR-hoz hasonlóan - nem tesz különbséget aszerint, hogy hol van a szolgáltató székhelye, mindenkire érvényes, aki az EU területén szolgáltatást nyújt. Fontos változás még, hogy az érintettek számára valós alternatívát kell felkínálni az adatkezelésben, ami a gyakorlatban annyit tesz, hogy nem tagadható meg a szolgáltatás azoktól, akik nem járulnak hozzá saját adataik teljeskörű felhasználásához.  [...]

-----

Kis hallgatnivaló az olvasás időtartamára: https://www.youtube.com/watch?v=AUA9IK1CuKY

Nem rövid, de nagyon hasznos videó:
https://www.youtube.com/watch?v=fNBopyxxjqs
Ubuntu Hour, Budapest, 2019. 03. 08.

Zero-day sebezhetőséget javított a Firefoxban a Mozilla | 2019. június 19.
https://www.hwsw.hu/hirek/60474/mozilla-firefox-biztonsag-zero-day-sebezhetoseg.html
Aktívan kihasznált hibáról van szó, mindenkinek ajánlott késlekedés nélkül frissíteni.

Zero-day sebezhetőséget foltoz a Firefox legújabb frissítése. A tegnap kiadott, 67.0.3-as verziószámú patch-et érdemes haladéktalanul telepíteni, az általa javított sérülékenységet ugyanis a Mozilla biztonsági szakértői szerint jelenleg is aktívan kihasználja több rosszindulatú fél.
https://www.mozilla.org/en-US/security/advisories/mfsa2019-18/

Egy típustévesztéses (type confusion) sebezhetőségről van szó, amely a JavaScript objektumok módosításakor lép fel, és amellyel összeomlás idézhető elő a böngészőben - ennek eredményeként pedig akár tetszőleges kódfuttatásra is lehetősége nyílhat a támadóknak az érintett számítógépeken. A Mozilla kapcsolódó posztja szerint
https://www.mozilla.org/en-US/security/advisories/mfsa2019-18/
a szervezet több esetről is tud, amelynek során célzott támadásokhoz használták fel a biztonsági rést. A sérülékenység kihasználásához a szakértők szerint a támadóknak elég rávenni a felhasználót, hogy a javítást még nem tartalmazó böngészőverzióval látogasson el egy megfelelően preparált weboldalra, és már el is juttathatják a rosszindulatú kódot a megcélzott eszközre.

A CVE-2019-11707 kódszám alatt nyilvántartott hibát a Google Project Zero biztonsági részlegének szakértője Samuel Groß, illetve a Coinbase Security csapata is jelezte a Mozilla felé. A Bleeping Computer szerint
https://www.bleepingcomputer.com/news/security/mozilla-firefox-6703-patches-actively-exploited-zero-day/
továbbá a patch megjelenését követően az Egyesült Államok kiberbiztonsági ügynöksége, a CISA (Cybersecurity and Infrastructure Security Agency) is kiadott egy figyelmeztetést, arra biztatva a felhasználókat, hogy minél előbb telepítsék a szükséges javításokat.

Az aktív támadásokról egyik fél sem közölt részleteket, így egyelőre azt sem tudni, azokban pontosan hány felhasználó lehet érintett, miután azonban a Mozilla bejegyzésében célzott akciókról beszél, jó eséllyel nem tömegesen kihasznált sebezhetőségről van szó. A ZDNet szerint
https://www.zdnet.com/article/mozilla-patches-firefox-zero-day-abused-in-the-wild/
valószínűleg elsősorban különböző kriptovaluták birtokosait vehetik célba a támadók, erre utalhat, hogy a hiba felfedezői között az említett Coinbase is ott volt. A Mozilla egyébként legutóbb 2016 decemberében foltozott zero-day hibát a Firefoxban, akkor a bugot a szoftverre támaszkodó Tor böngésző anonim felhasználóinak beazonosítására használták .

@#69 Olvastam én is. Sajnos, feliratkozni nem lehet, csak a HUP-ra. A backdoor jelenléte egyelöre könnyen kiderül.

Veszélyes hibát találtak az egyik legnépszerűbb ingyenes és nyílt forráskódú médialejátszóban, a VLC-ben, német kutatók szerint a sérülékenység Windowson, Linuxon és Unixon megtalálható, macOS-en és Androidon nem fordul elő.

A német CERT-Bund kiberbiztonsági szakértői azonosították a CVE-2019-13615 számon nyilvántartott hibát, amely távoli kódfuttatást tesz lehetővé. Magyarán a támadók a sérülékenységet kihasználva szoftvereket telepíthetnek és futtathatnak az áldozat számítógépén, és megnézhetik az ott tárolt fájlokat.

Még senki sem használta ki a hibát, de a VLC nagyon elterjedt program, ezért fennáll a veszélye, hogy a kiberbűnözők hamarosan támadásba lendülnek.

Nincs ott semmi?

A VLC közben Twitteren jelezte, hogy senki sem tudja reprodukálni a német kutatók által jelzett hibát, és nemtetszésüket fejezték ki amiatt, hogy sohasem értesítik őket, mielőtt közzétennének egy komoly sérülékenységet. (ejnyebejnye, tényleg!)

    Hey @MITREcorp and @CVEnew , the fact that you NEVER ever contact us for VLC vulnerabilities for years before publishing is really not cool; but at least you could check your info or check yourself before sending 9.8 CVSS vulnerability publicly...
    — VideoLAN (@videolan) July 23, 2019

A VideoLAN hibabejelentő oldalán hosszú vita bontakozott ki a sérülékenységgel kapcsolatban, és a legtöbben azt jelezték, hogy nem sikerült reprodukálni azt, amit a német kiberbiztonsági kutatók állítanak. Alig pár órával ezelőtt Jean-Baptiste Kempf, a VLC-t kiadó VideoLAN elnöke is hozzászólt, és azt írta, hogy a szóan forgó hibát egy évvel ezelőtt kijavították, és a problémát egy tőlük független programkönyvtár okozta.

Akinek mégis kétségei támadtak, nyugodtan térjen át ideiglenesen egy másik médialejátszó programra, és/vagy figyelje a VLC frissítéseit.

https://index.hu/techtud/2019/07/24/vlc_serulekenyseg_medialejatszo/
(Gizmodo)

Ismét konfliktusba került a kényelem a biztonsággal – most a Firefoxban. A beépített jelszókezelőben tárolt bejelentkezési adatokhoz, jelszavakhoz akkor is hozzáférhettek illetéktelenek, ha azokat a felhasználó mesterjelszóval védte. A hibát a Mozilla a böngésző 68.0.2-es kiadásában javította. Ha még nem frissített erre a verzióra, haladéktalanul tegye meg.

Annak ellenére, hogy a hiba a jelszavak kezelését érintette, a Mozilla csupán közepes kockázatúnak minősítette a hibát. Ennek valószínűleg az volt az oka, hogy a kihasználásához hozzá kell férni az adott számítógéphez, és annak felhasználója adataival kell bejelentkezni. Emiatt például kémprogramokkal nem lehet kinyerni a mentett jelszavakat.

A Bleeping Computer ugyanakkor megjegyzi: arra mindenképpen érdemes figyelni, hogy a Firefox jelszókezelője – azaz a jelszómentési lehetőség – alapértelmezett szolgáltatás. Ugyanakkor a böngésző nem követeli meg a mesterjelszó használatát. Ha viszont valaki nem használ mesterjelszót, akkor a hibától függetlenül is bárki ellophatja a mentett bejelentkezési adatokat, ha fizikailag hozzáfér a géphez. Ennek valószínűsége sokkal kisebb, mint az olyan támadásoké, amikor a hekkerek távolról próbálják átvenni a felügyeletet a rendszer vagy egyes részei fölött.

Ha valaki még jobban szeretné védeni jelszavait, telepítheti a Mozilla Lockbox nevű böngészőkiegészítőjét. Ez az egyszerű felületű jelszókezelő – amely idén márciustól Androidon is használható – automatikusan importálja a Firefoxból az ott mentett bejelentkezési adatokat, amikor a felhasználó bejelentkezik a böngészőbe a Firefox-fiókjával, és azokat 256 bites végponti titkosítással tárolja el.

Bővebben: https://bitport.hu/firefoxot-hasznal-kezdje-ezzel-a-frissitessel-a-munkahetet

Itt egy kis érdekes olvasmány, így szilveszter előtt. Egy holland IT biztonsági cég rátalált egy kínai hackertámadásra, ahol már a 2FA-t is fel tudták törni. Hihetetlen : https://www.zdnet.com/google-amp/article/chinese-hacker-group-caught-byp...

#81 Úgy általában 2FA törés is lehet, de most a két faktoros hitelesítés VPN fiókokat védett. Az RSA SecurID token-készítő alkalmazás működését szimulálták eredményesen a támadók távolról ..., bejutva a gépre fizikailag (a neten).

#80 Csak én nem értem, hogy ez mitől 2 faktoros  autentikációs rendszer heckelés? BTW, ha bejut a céges hálóra, de emellett még a VPN logint is megszerezte, az kétféle deal, de nem kétfaktor. Vagy A VPN használt kétfaktoros azonosítás, és az lett megfektetve?

"Érezzék azt a biztonságot, hogy hozzánk fordulhatnak.."
Gyerekek és nagyszülők a neten: hogyan segíthetnek a szülők, pedagógusok és mit ad nekik ehhez a #SaferInternetProgram? Kurkó Zsuzsánna, a SIP programkoordinátora az M1 Ma délelőtt című műsorában beszélt a munkánkról, és a közelgő nemzetközi Biztonságos Internet Napról. A beszélgetés megnézhető itt:
https://mediaklikk.hu/video/ma-delelott-2020-02-08-i-adas/
2020. február 11.

-----

A Nemzetközi Gyermekmentő Szolgálat – mint az Európai Unió Safer Internet Program hazai konzorciumvezetője – szeretettel meghívja Önt a Biztonságos Internet Nap

(Safer Internet Day) alkalmából tartandó rendezvényre.

Időpont és helyszín:
2020. február 11. (kedd), 10.00-14.00 óra
Nemzeti Közszolgálati Egyetem
Zrínyi Terem
(1083 Budapest, Ludovika tér 2.)

Gyereknevelés a kibertérben. A szülők és pedagógusok szerepe.

Napjainkban nem csak a gyerekeknek jelent kihívást a biztonságos internethasználat. Egyre komolyabb feladat jut a szülőknek és a pedagógusoknak, azaz a családnak és az iskolának.

Az internethasználat és – biztonság új, 21. századi tendenciái komoly fejtörést okoznak a szülőknek és a pedagógusoknak, hiszen a hagyományos, jól bevált szabályozási módszerek már nem minden esetben tűnnek életszerűnek. Ezek a gyakran kudarcként megélt tapasztalatok egyre jobban beárnyékolják az internet egyébként igen pozitív és hasznos oldalát.

A Biztonságos Internet Nap – Safer Internet Day (SID) célja, hogy az Európai Unió Safer Internet Program akciótervének keretein belül több mint 150 országban ugyanazon a napon hívja fel a figyelmet az internet előnyeire és veszélyeire, lehetőséget teremtsen és buzdítsa a gyerekeket olyan pozitív tartalmak létrehozására, melyeket később a családban, iskolában, barátokkal is tudnak használni.

A rendezvény tervezett programja: http://gyermekmento.hu/Tartalmak/Hirek/Meghivo-Biztonsagos-Internet-Nap-2020---Februar-11.

A részvételi szándék jelzésének időpontja lejárt ugyan ...

#85 Ja, ez csúnya, ám „tulajdonképpen ötletes” húzás volt.

https://index.hu/kulfold/2020/02/11/cia_hirszerzes_atveres_nsa_crypto_ag...

És még ők pampognak, hogy a kínaiak kémkednek - volt kitől tanulniuk !

A biztonsági kutatók figyelmeztetnek egy jelentős új biztonsági hibára az Intel processzorain belül, és ez legyőzheti a hardver alapú titkosítást és a DRM védelmet. A hiba az utóbbi öt évben kiadott modern Intel processzorok hardver szintjén létezik, és lehetővé teheti a támadók számára, hogy speciális rosszindulatú programokat (például keyloggereket) hozzanak létre, amelyek hardver szinten futnak és a hagyományos antivírus rendszerekkel nem észlelhetők. Az Intel legújabb 10. generációs processzora azonban nem sebezhető, azaz egyedül ezt a sorozatot nem érinti a sebezhetőség.

Az Intel alábecsülte az új biztonsági rést, megjegyezve, hogy ez valószínűleg speciális hardvert és fizikai hozzáférést igényel. „Az Intel értesült az Intel Converged Security Management Engine potenciálisan sérülékenységéről, amelyben egy speciális hardverrel és fizikai hozzáféréssel rendelkező jogosulatlan felhasználó önkényes kódot hajthat végre az Intel CSME alrendszeren belül bizonyos Intel termékeknél" - mondja az Intel szóvivője egy nyilatkozat az Ars Technica-nak . Az Intel kiadott enyhítéseket és javasolja a rendszerek naprakészen tartását. A CVE-2019-0090-re vonatkozó kiegészítő útmutatások itt találhatók: https://www.intel.com/content/www/us/en/support/articles/000033416/techn... ”

https://www.theverge.com/2020/3/6/21167782/intel-processor-flaw-root-of-...

The remote exploitation of this vulnerability is possible due to the fact that integrity in Linux based software installation mechanisms rely on digitally signing files while downloading files over the insecure HTTP connection.
https://thehackernews.com/2020/03/openwrt-rce-vulnerability.html

@#93 Logikus a felvetés. A Debianban a tükrökről elérhető csomagok tekintetében nincs „lyuk”, az esetleges biztonsági hiányosságokat a csomag készítése közben megvizsgálják, és csak ezután töltik fel a szerverre

A stabli rendszer tekintetében biztosan, a többi verzió tekintetáben most a témába ne menjünk bele, de tudok információt erről is. A Zero Day sebezhetőségekről nem tehetnek - ahogy egyik Linux rendszer sem - tehát ezt javítják. A javítás menete és némi információ: https://www.debian.org/security/

Egészen pontosan, arról van szó, hogy a Debian biztonsági frissítései a debian-security tükörről jönnek (akkor, ha javítás is szükséges):

deb http://security.debian.org/debian-security buster/updates main contrib non-free
deb-src http://security.debian.org/debian-security buster/updates main contrib non-free

Az Ubuntu, a Linux Mint (és a többi rendszer) hasonló megoldást alkalmaz, azaz, a tükör szerverekre nem kerülhet fel biztonsági szempontból sebezhető alkalmazás. Az Arch Linux a leírás szerint kicsit más, de mondjuk, szervernek, ahol a biztonság ebből a szempontból és feltétlen szükséges, ezt a Linux terjesztést nem is ajánlják, nem is használják. Vizsgálhatnák azért a biztonsági lyukakat is, nem biztos, hogy túl sok időbe telne.

Nem tudok hasonló alkalmazásról, mivel nincs szükség ilyen vizsgálatra, feltételezem, hogy nem létezik. Létezik azonban olyan alkalmazás a Debian rendszerre, amely a még nem javított futási hibákat mutatja- A futási hibák javításának van egy menete, „menet közben” is felléphetnek, és javítják ezeket is. Kisebb hibákról (bug) van szó, amelyek a „felhasználói élményt” nemigazán befolyásolják. Van kivétel, például a Gnome Commander alkalmazás az alkalmazás fejlesztői nem fejlesztik megfelelően,egészen pontosan az a Debian fejlesztőinek véleménye a témáról, hogy az alkalmazás múködése igen szegényes (sok a hiba), ezért nem teszik be a Debianba. Lehet „nice and fast” ..., ez nem igaz: https://tracker.debian.org/pkg/gnome-commander

Még több részlet:
https://www.debian.org/doc/manuals/securing-debian-howto/
https://wiki.debian.org/LTS
https://wiki.debian.org/Security/Features
-----
https://www.debian.org/Bugs/
https://wiki.debian.org/HowtoUseBTS
https://wiki.debian.org/reportbug
https://security-tracker.debian.org/tracker/

...mindez a Debian terjesztésre jellemző.

A Linux Mint, s az LMDE rendszeren, a biztonsági frissítéseket az unattended-upgrades csomag hozza, a felhasználó tevékenységétől függetlenül is. No,meg a felhasználó, akinek naponta vagy szűkebb időközönként frissíteni kéne. :-)

sudo apt-get install unattended-upgrades

Ha a felhasználó csak a biztonsági frissítéseket telepítené (mert nem frissít „valamiért” általában):

Teszt:

sudo unattended-upgrade -d --dry-run

Élesben:

sudo unattended-upgrade -d

A d paraméter a hibakeresésé (debug).

Az egész rendszert frissíteni kell azonban. Alkalmazás futási, működési problémák is felléphetnek, ha ez nem történik meg. Szoktuk javasolni, a hibakeresékor a frissítést ..., a csomag korábbi verziójának hibája meg lett oldva egy friss verzióban.

Kézikönyvek:
http://manpages.ubuntu.com/manpages/trusty/man8/unattended-upgrade.8.html
https://wiki.debian.org/UnattendedUpgrades

Becslések szerint legalább 300 ezer WhatsApp-felhasználó telefonszáma válhatott nyilvánossá egy a szolgáltatásba épített funkció hibás működésének köszönhetően. A banálisnak tekinthető, először idén februárban jelzett hiba révén a Google keresőben megjelenhettek azoknak a felhasználóknak a telefonszámai, akik a click to chat szolgáltatást rendszeresen használták.

Részletek: https://www.hwsw.hu/hirek/61891/whatsapp-call-hivas-google-kereso-click-...

#97 név (vezetéknév és keresztnév) - ott van
nem, - nincs ott, azt hiszem
lakhely (város) - nem egyértelműen, de van
munkahely, családi állapot - nincs ott
mobiltelefonszám - ezt régebben üzenetekből „csenték ki”, aztán zaklattak percenként, hogy írjam a profilhoz
e-mail cím, Facebook-profil linkje - máshogy nem megy. Egyedi e-mail címet lehet ahsználni, csak ide.

https://m.hvg.hu/tudomany/20200610_facebook_adatlopas_magyar_felhasznalo...
Hoppá !

#99 a javítás nem képezte részét a szoftverhez hivataloson kiadott javítás-csomagoknak ... de telepítették végül.

A bejelentést  az  Adatkezelő 2019.  szeptember  25-én  tette  meg  a  Hatóság  felé,  így  ez  irányú kötelezettségét az incidens tudomására jutásától számított 72 órán belül teljesítette. A Hatóság a bejelentési kötelezettség teljesítésével kapcsolatos jogsértést ezért nem állapított meg.

Más szolgáltatónál a hasonló rések vagy más biztonsági hiányosságok simán megvannak. Az a cél, ne legyen ilyen egyáltalán. Kapnak is büntetéseket, ki ezért, ki azért.

https://hup.hu/cikkek/20200612/100_millio_forintos_gdpr_birsagot_kapott_...

Kötetlen, laza hangvételű, kedd délutáni online rendezvény IT biztonsági szakembereknek, üzemeltetőknek, rendszergazdáknak, érdeklődőknek: https://www.youtube.com/watch?v=Dzamk-mgXmk

SIGRed: 17 éve létező, extrém kritikus, féreg terjesztésére alkalmas sebezhetőséget fedeztek fel a Microsoft DNS szerverében

A Windows DNS szervert érintő, SIGRed névre keresztelt, "férgesíthető" sebezhetőség (CVE-2020-1350) a Windows Server 2003-tól a Windows Server 2019-ig bezárólag érinti a Microsoft szerver termékeket. A sebezhetőséget sikeresen kihasználó támadó domain admin jogokhoz juthat, vagyis a domain-ben levő összes szerver és kliens felett rendszergazdai jogot szerezhet. A sebezhetőség súlyosságára jellemző, hogy míg a WannaCry sebezhetőségek csak 8,5 CVSS pontot kaptak, a SIGRed 10-ből 10-et.

Sebezhetőség idővonal:

• 19 May 2020 – Initial report to Microsoft.
• 18 Jun 2020 – Microsoft issued CVE-2020-1350 to this vulnerability.
• 09 Jul 2020 – Microsoft acknowledged this issue as a wormable, critical vulnerability with a CVSS score of 10.0.
• 14 Jul 2020 – Microsoft released a fix (Patch Tuesday).

Technikai elemzés és részletek itt.

Forrás: https://hup.hu/cikkek/20200715/sigred_17_eve_letezo_extrem_kritikus_fereg_terjesztesere_alkalmas_sebezhetoseget_fedeztek_fel_a_microsoft_dns_szervereben

#105 A frissítés a nem EFI bootos rendszereken az alábbi "grub rescue" problémát okozhatja:

symbol 'grub_calloc' not found

A megoldás a GRUB újratelepítése. Módszerei:

1) https://linuxmint.hu/blog/2017/09/a-grub-ujratelepitese-beallitasa-live-...

2) https://sourceforge.net/p/boot-repair-cd/home/Home/

Esetleg, aki nem gyakran frissít, az most mindenképpen tegye meg.

CVE-2020-10713

    A flaw in the grub.cfg parsing code was found allowing to break
    UEFI Secure Boot and load arbitrary code. Details can be found at
    https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

CVE-2020-14308

    It was discovered that grub_malloc does not validate the allocation
    size allowing for arithmetic overflow and subsequently a heap-based
    buffer overflow.

CVE-2020-14309

    An integer overflow in grub_squash_read_symlink may lead to a heap-
    based buffer overflow.

CVE-2020-14310

    An integer overflow in read_section_from_string may lead to a heap-
    based buffer overflow.

CVE-2020-14311

    An integer overflow in grub_ext2_read_link may lead to a heap-based
    buffer overflow.

CVE-2020-15706

    script: Avoid a use-after-free when redefining a function during
    execution.

CVE-2020-15707

    An integer overflow flaw was found in the initrd size handling.

Further detailed information can be found at
https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot

For the stable distribution (buster), these problems have been fixed in
version 2.02+dfsg1-20+deb10u1.

We recommend that you upgrade your grub2 packages.

For the detailed security status of grub2 please refer to its security
tracker page at:
https://security-tracker.debian.org/tracker/grub2

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/

#115 Szépen helyrerakta GRUB-ot, persze ez is Ubuntu menüket hozott létre, de működni működött, a rendszer elindult.

A chroot ezek szerint jobb javaslat volt.:)

#114 Most d.u. a fő gépen, amit hajnalban visszaállítottam, újra felajánlotta a GRUB2 frissítést, gondoltam, azóta javították, hát kipróbálom. De előtte gondosan letöltöttem innen:
https://sourceforge.net/p/boot-repair-cd/home/Home/ a 64 bites ISO-t, rátettem a ventoy-os pendrájvra, biztos, ami biztos. Hát nem javíttották, úgyanúgy rossz lett.

Így szépen bebutultam a boot-repair-cd-t, ami megy Ventoy alól, de viszont frissíteni nem tud, jó párszor nekifutottam, de végül feladtam, és nekiálltam vele kijavítani a GRUB-ot. Arra figyelni kell, hogy tök másképp számozza a lemezeket, mint normál üzemmódban, nem szabad a megszokásra hagyatkozni!

Szépen helyrerakta GRUB-ot, persze ez is Ubuntu menüket hozott létre, de működni működött, a rendszer elindult. Ezután egy update-grub-al a menük kinézetét is helyrehoztam, így most a rendszer a friss GRUB-al szépen működik. Még megnézem valamikor a többi lemez MBR-jét is, hogy azokba nem rondított-e bele.

(jelenleg 3 merevlemez duruzsol a gépben, a 2 rack fiók üres napok óta, kop-kop)

U.I. amit reggel láttam EFI partició, az a live pendrájvon van, nem a GRUB frissítés hozta létre.

#117 A chroottal biztonságosan kijavítható a történet, sőt, más partícióra is teheted a GRUB-ot.

Nem kell Boot Repair CD, főleg, ha EFI partíciót hoz magától létre. Az EFI particiót a szabad helyen hozta létre a lemez végén? Vagy csak EFI menüt hozott létre? Az Ubuntu menü meg amiatt van, mert annak ismeri fel a Linux Mintet, esetleg a Debian-alapú rendszert is. A Virtualbox is Ubuntu ikont tesz be, ha Mintet telepítek. Kicsit zavaró.

Frissitett a Bunsenlabs, javitva lett a grub, persze megint rossz. Talán nem véletlen, hogy az MXLinux nem tette be ezeket a csomagokat...Mentségére szolgáljon, hogy lényegesen kevesebb fals bejegyzés került bele (úgy 30) s makacsul MBR-be ír pedig particióra kellene...

#119 Azt nem egészen értem, hogy a grub frissítés az MBR-be írta magát. Ott is van, igen, oda is ír, ha a lemezre teszed (például sda, sdb, sdc), de partícióra is teheted. Ha a chroottal csinálod, akkor te jelölöd ki. Mi volt, hogy volt?

#118 Nekem Legacy telepitésem van, és a különböző Linux-ok grubja a saját particiójukra kerül, kivétel az Arch, amelyik MBR-be kerül a sok frissités miatt (Ne kelljen olyan sokszor a sudo update-grub, bér ez archon kicsit másképp néz ki) Ezért fura a Bunsenlabs MBR-be való irása. A Boot Repair CD-ről csak hallottam, sohasem használtam.

Természetesen semmiféle particiót nem hozott létre, (emlitettem Legacy), de szerintem másnak sem, hacsak nem figyelmetlenül olvastam. (előfordulhat...)

#121 Értem már! Szóval, a GRUB2 biztonsági frissítése tette az MBR-be, de korábban az egyik partíción volt a BunsenLabs GRUB. De azt egyébként honnan látod, hogyan ellenőrizted, hogy az MBR-bsn most nem az Arch Linux, hanem a BunsenLabs Linux GRUB-ja van?

#120 Én sem értem. A Bunsenlabs grubja is particóra került (elég régen, még a 9-es Debian-nal) soha probléma nem volt vele, csak a mostani frissitések nem voltak jók. A bunsenlabs history.logja szerint ez történt

Start-Date: 2020-07-30  02:23:07
Commandline: /usr/bin/apt-get dist-upgrade --no-install-recommends -ym --allow-downgrades --allow-change-held-packages
Upgrade: grub-common:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), grub2-common:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), grub-pc:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), grub-pc-bin:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), firefox-esr-l10n-hu:amd64 (68.10.0esr-1~deb10u1, 68.11.0esr-1~deb10u1), firefox-esr:amd64 (68.10.0esr-1~deb10u1, 68.11.0esr-1~deb10u1)
End-Date: 2020-07-30  02:25:04

Start-Date: 2020-07-31  08:05:58
Commandline: apt dist-upgrade -y
Requested-By: andrea (1000)
Upgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u1, 2.02+dfsg1-20+deb10u2), grub2-common:amd64 (2.02+dfsg1-20+deb10u1, 2.02+dfsg1-20+deb10u2), grub-pc:amd64 (2.02+dfsg1-20+deb10u1, 2.02+dfsg1-20+deb10u2), grub-pc-bin:amd64 (2.02+dfsg1-20+deb10u1, 2.02+dfsg1-20+deb10u2)
End-Date: 2020-07-31  08:07:54

#126 Azt nem értem, honnan tudod:, melyik van például az sda MBR-jében? Kétségem nincs, hogy. GRUB menüket magukban meg tudod különböztetni. :)

#124 Már ránézésre is könnyű, témázva van mindkettő. Ha nem úgy néz ki, ahogy szeretném, már lehet szentségelni.

#129 Nem értem sajnos, a MBR-be telepítést. Mik a parancssorai?

#128 Számomra a jól bevált szisztéma: Az sda-ra megy Win10, Arch, Ubuntu, Bunsenlabs. Az Arch grub-ot az MBR-be telepitem az összes többit particióra. Azért az arch-ot, mert képes összeakadni az Ubuntuéval, Debianéval, forditva meg nem igaz. 

Elvileg van még egy USB-s sdb is, Erre kerülnek a kipróbálásra szánt verziók, ugyanazon elv szerint.

Ezenkivül van még egy 32 GB-os Ventoy pendrive, ha netán valamiért live boot-ra lenne szükség. Azon nem tudom hirtelen hány distro van...

#131 Tökéletes (indul a rendszer). A csomag verzió:

dpkg -l | grep grub*
ii  grub-common 2.02+dfsg1-20+deb10u2 amd64 GRand Unified Bootloader (common files)
ii  grub-pc 2.02+dfsg1-20+deb10u2 amd64 GRand Unified Bootloader, version 2 (PC/BIOS version)
ii  grub-pc-bin 2.02+dfsg1-20+deb10u2 amd64 GRand Unified Bootloader, version 2 (PC/BIOS modules)
ii  grub2-common 2.02+dfsg1-20+deb10u2 amd64 GRand Unified Bootloader (common files for version 2)

Két dolgot nem értek atime:
-- a BunsenLabs Linux melyik frissítést nem tette be (a kettőből)?
-- mit takar, amikor az MBR-be telepíted a GRUB-ot?

#125 A kiemelt jelzést kaptam,

sudo apt-get upgrade
Csomaglisták olvasása... Kész
Függőségi fa építése       
Állapotinformációk olvasása... Kész
Frissítés kiszámítása... Kész
Az alábbi csomagok frissítve lesznek:
  grub-common grub-pc grub-pc-bin grub2-common
4 frissített, 0 újonnan telepített, 0 eltávolítandó és 0 nem frissített.
Letöltendő adatmennyiség: 4.049 kB.
A művelet után 0 B lemezterület kerül felhasználásra.
Folytatni akarja? [I/n]
Letöltés:1 http://security.debian.org/debian-security buster/updates/main amd64 grub-pc amd64 2.02+dfsg1-20+deb10u2 [131 kB]
Letöltés:2 http://security.debian.org/debian-security buster/updates/main amd64 grub2-common amd64 2.02+dfsg1-20+deb10u2 [538 kB]
Letöltés:3 http://security.debian.org/debian-security buster/updates/main amd64 grub-pc-bin amd64 2.02+dfsg1-20+deb10u2 [903 kB]
Letöltés:4 http://security.debian.org/debian-security buster/updates/main amd64 grub-common amd64 2.02+dfsg1-20+deb10u2 [2.477 kB]
Letöltve 4.049 kB 1mp alatt (3.495 kB/s)
Reading changelogs... Done
Csomagok előkonfigurálása ...
(Adatbázis olvasása ... 375445 files and directories currently installed.)
Preparing to unpack .../grub-pc_2.02+dfsg1-20+deb10u2_amd64.deb ...
Unpacking grub-pc (2.02+dfsg1-20+deb10u2) over (2.02+dfsg1-20+deb10u1) ...
Preparing to unpack .../grub2-common_2.02+dfsg1-20+deb10u2_amd64.deb ...
Unpacking grub2-common (2.02+dfsg1-20+deb10u2) over (2.02+dfsg1-20+deb10u1) ...
Preparing to unpack .../grub-pc-bin_2.02+dfsg1-20+deb10u2_amd64.deb ...
Unpacking grub-pc-bin (2.02+dfsg1-20+deb10u2) over (2.02+dfsg1-20+deb10u1) ...
Preparing to unpack .../grub-common_2.02+dfsg1-20+deb10u2_amd64.deb ...
Unpacking grub-common (2.02+dfsg1-20+deb10u2) over (2.02+dfsg1-20+deb10u1) ...
Beállítás: grub-common (2.02+dfsg1-20+deb10u2) ...
Beállítás: grub2-common (2.02+dfsg1-20+deb10u2) ...
Beállítás: grub-pc-bin (2.02+dfsg1-20+deb10u2) ...
Beállítás: grub-pc (2.02+dfsg1-20+deb10u2) ...
Telepítés a(z) i386-pc platformhoz.
grub-install: figyelmeztetés: A(z) „ext2” fájlrendszer nem támogatja a beágyazást.
grub-install: figyelmeztetés: Beágyazás nem lehetséges. A GRUB ezen telepítés során kizárólag blokklisták segítségével települhet, viszont a blokklisták NEM MEGBÍZHATÓAK és használatuk nem javallott..
A telepítés befejeződött. Nem jelentettek hibát.
GRUB beállítófájl előállítása…
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Megtalált linux lemezkép: /boot/vmlinuz-5.6.0-0.bpo.2-amd64
Megtalált initrd lemezkép: /boot/initrd.img-5.6.0-0.bpo.2-amd64
Megtalált linux lemezkép: /boot/vmlinuz-5.4.0-0.bpo.4-amd64
Megtalált initrd lemezkép: /boot/initrd.img-5.4.0-0.bpo.4-amd64
Megtalált linux lemezkép: /boot/vmlinuz-4.19.0-9-amd64
Megtalált initrd lemezkép: /boot/initrd.img-4.19.0-9-amd64
kész
Processing triggers for man-db (2.8.5-2) ...

amikor ezt csináltam (chroot):

grub-install /dev/sda1

grub-install --recheck /dev/sda1

... itt lehet gond (kiemelt szöveg), nem az XTerm vagy UXTerm használatnál.

Ez az Xfce4 Terminálban futtattam:

grub-install /dev/sda

grub-install --recheck /dev/sda

és sikerült a művelet, a javítás.

-----

Partíciós táblám:

fdisk -l
Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: TOSHIBA MQ04ABF1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x4bb720d8

Device     Boot     Start        End    Sectors   Size Id Type
/dev/sda1  *         2048  429686783  429684736 204,9G 83 Linux
/dev/sda2       429686784  449607679   19920896   9,5G 82 Linux swap / Solaris
/dev/sda3       449609726 1953523711 1503913986 717,1G  5 Extended
/dev/sda5       449609728 1953523711 1503913984 717,1G 83 Linux

Partition 3 does not start on physical sector boundary.

parted -l
Model: ATA TOSHIBA MQ04ABF1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  220GB   220GB   primary   ext4            boot
 2      220GB   230GB   10,2GB  primary   linux-swap(v1)
 3      230GB   1000GB  770GB   extended
 5      230GB   1000GB  770GB   logical   ext4

A root felhasználóval néztem (sudo -i), mert a chroot parancs előzményeket is a root futtatta.

... most újraindítom a rendszert. És nem lesz jó?
Nos, futtattam ;), hátha így jó lesz mégis:

update-grub
GRUB beállítófájl előállítása…
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Megtalált linux lemezkép: /boot/vmlinuz-5.6.0-0.bpo.2-amd64
Megtalált initrd lemezkép: /boot/initrd.img-5.6.0-0.bpo.2-amd64
Megtalált linux lemezkép: /boot/vmlinuz-5.4.0-0.bpo.4-amd64
Megtalált initrd lemezkép: /boot/initrd.img-5.4.0-0.bpo.4-amd64
Megtalált linux lemezkép: /boot/vmlinuz-4.19.0-9-amd64
Megtalált initrd lemezkép: /boot/initrd.img-4.19.0-9-amd64
kész

#133 Az sda-ra megy Win10, Arch, Ubuntu, Bunsenlabs.

arch alatt a grub-install /dev/sda paranccsal kerül az MBR-be

Nekem úgy tűnik, mind az sda-ra megy. :)
Ezt írod...

-----

Ha lemez (például sda), akkor mondhatjuk úgy is MBR, de ..., mégsem: ;)

A háttértár formázásától függően, a megadott alapértelmezett foglalási egységnek (szektorméret) megfelelően, a MBR is 4096 bájt terjedelmű, viszont kis mérete ellenére kulcsfontosságú információkat tárol, éspedig:

• az ugyancsak MBR nevű kis programot, mely elindít egy operációs rendszert a merevlemezről; ezt a kis programot betöltő kódnak vagy rendszerindító kódnak (boot code) is nevezik;
• a partíciós táblát, mely a merevlemez-partíciók elhelyezkedési adatait tárolja.

A partíciós tábla felfogható a merevlemezen levő partíciók ’tartalomjegyzékének’. Ahogy egy könyv tartalomjegyzéke megmutatja, hogy a könyv bizonyos fejezetei a könyv hányadik oldalán kezdődnek, úgy a Master boot record-ban (Partíciós szektorban) levő partíciós tábla is megmutatja, hogy a partíciók a merevlemezen hol találhatóak. A partíciós tábla egy vagy több bejegyzésből áll. Mindegyik bejegyzés egy partíciót ír le. A MBR partíciós táblája legfeljebb négy bejegyzést tartalmazhat, ugyanis a partíciós tábla csak az elsődleges partíciók és a kiterjesztett partíció adatait tartalmazza. (Ezekből pedig egy merevlemezen összesen 4-nél több nem lehet.) A kiterjesztett partíció által tartalmazott logikai partíciók táblázata nem a MBR-ben, hanem a kiterjesztett partícióban található.

Forrás: https://hu.wikipedia.org/wiki/Master_Boot_Record

#132 arch alatt a grub-install /dev/sda paranccsal kerül az MBR-be, ahogy irtad. Megnézni csak vasárnap este tudom a Bunsenlabsos telpitést, akkor leszek gépközelben ez telo.

#106 Ki honnan nézi (vélemények): https://hup.hu/cikkek/20200729/boothole_grub2_sebezhetoseg_nyithat_utat_...

#105 A frissítés a nem EFI bootos rendszereken az alábbi "grub rescue" problémát okozhatja:

symbol 'grub_calloc' not found

A megoldás a GRUB újratelepítése. Módszerei:

1) https://linuxmint.hu/blog/2017/09/a-grub-ujratelepitese-beallitasa-live-...

2) https://sourceforge.net/p/boot-repair-cd/home/Home/

#137 Ugyanazok, mint az én rendszeremen. Ha.a Bunsenlabs Lithium kiadás tükreit használod - írtad, azt - akkor nem csoda, mert az a Debian 10 Buster(ami az LMDE 4 Debbie alapja is), vagyis a jelenlegi stabil Debian kiadás. Lassacskán nekem is telepíteni kéne egy Bunsenlabs-ot, régen használtam.

Minden GRUB-ot használó Linux terjesztésen frissítették a GRUB alkalmazást, a biztonsági folttal (például Red Hat, Arch Linux). Ami rossz volt, már jó ... https://m.youtube.com/watch?v=l2puvI4IfG0

#132 Nekem ez jött le:

$ dpkg -l | grep grub*
ii  grub-common                            2.02+dfsg1-20+deb10u2               amd64        GRand Unified Bootloader (common files)
ii  grub-pc                                2.02+dfsg1-20+deb10u2               amd64        GRand Unified Bootloader, version 2 (PC/BIOS version)
ii  grub-pc-bin                            2.02+dfsg1-20+deb10u2               amd64        GRand Unified Bootloader, version 2 (PC/BIOS modules)
ii  grub2-common                           2.02+dfsg1-20+deb10u2               amd64        GRand Unified Bootloader (common files for version 2)

Azóta sok minden történt a Bunsenlabs házatáján, volt kernelcsere is. (Csak én nem értem rá géppel foglalkozni, majd.)

A különféle képalkotó-eszközöket, nyomtatókat és fényképezőket gyártó Canon vállalat a legutóbbi jelentős áldozata annak a kiberbűnözői csoportnak, akik a Maze nevű zsarolóvírus (ransomware) mögött állnak. A támadások során a hackerek nem csupán titkosítják és zárolják a fertőzött eszközökön található fájlokat a kártevővel, de egyben el is lopják az adatcsomagokat.

A kiberbiztonsági történésekkel foglalkozó BleepingComputer forrása szerint a Canontól több mint 10 terabájt adatok sikerül elszipkázni. A cikk írásának pillanatában az incidens körülbelül 25, a gyártóhoz köthető doméncímet és pár belsős alkalmazást érint, többek közt levelező-, és kollaborációs-szolgáltatásokat.

A Canon szóvivője a Computer Weekly számára megerősítette, hogy a vállalat amerikai részlegének belsős rendszerét és weboldalait érinti a támadás. A Canon még vizsgálja az ügyet, arról további részleteket nem közölt.

Nemrég a Garmint, előtte pedig a Hondát támadták meg kiberbűnözők zsarolóvírussal: https://24.hu/tech/2020/06/16/honda-japan-gyar-zsarolovirus-tamadas-leal...

Forrás: https://24.hu/tech/2020/08/07/canon-zsarolovirus-tamadas-ransomware/

Honda (https://www.youtube.com/watch?v=HnGX5jL-lhg )

(https://www.youtube.com/watch?v=vi8W93aJG_U )

Az FBI és az NSA közös elemzést adtak ki a Drovorub (magyar fordításban nagyjából “favágó”) névre keresztelt káros kódról, amelyet a hírhedt Fancy Bear (APT28) orosz állami hacker csoporthoz kötnek. Drovorub alatt egy eszközkészlet értendő, amelynek része egy kernel rootkit, egy fájl-átviteli modul, egy port frowarding modul, valamint egy vezérlőszerver (C2). Az amerikai ügynökségek Linux adminok számára javasolják a 3.7, vagy ennél frissebb kernel verzióra történő frissítést, amely már védett a káros kód rootkit moduljával szemben. Az elemzés fertőzésre utaló indikátorokat, Snort és Yara szabályokat is tartalmaz, amelyek segítségével detektálható a fertőzés. Emellett javaslatot tesz a Volatility nevű, memória forensic tool alkalmazására.

(securityaffairs.co)

Forrás: https://nki.gov.hu/it-biztonsag/hirek/orosz-apt-altal-alkalmazott-linuxo...

#148 Igen, ismerem (én). RSS is van.
Manapság az a probléma, sok weboldalnak nincs hírlevél vagy RSS csatornája. Ha lenne, akkor e-mailben, hírlevélben, vagy RSS-t olvasásó alkalmazásban napi szinten összegyűjtené magának az ember.
A Google döntése sem volt jó (kitérő, persze, kapcsolódik) ... leállította az új videók értesítéseit, mondván, nem niytotta meg szinte senki. Erről másik topikban írtam.

Fris hírek olvashatók az alábbi linken, az információbiztonság világából.

https://biztonsagportal.hu/index.php

 

#149 Például ezt megtaláltad?
https://en.wikipedia.org/wiki/Lynis
https://linux-audit.com/lynis/
https://gbhackers.com/lynis-open-source-security-auditing-tool-a-detaile... )

• Lynis – ingyenes kiberbiztonsági audit szoftver

#146 1) nem konkrét egy cikkre írtam, hanem azon összes cikkre, amik 2018-ban és 2019-ben jelentek meg és most lettek feltöltve.

Egyet, kettót linkelj légy szíves az általad „kifogásolt” cikkekből (hozzászólás címe => egér jobb gombos - környezeti - menü => Hivatkozás címének másolása). Innen, a fórumról, topikból.
Én nem látok ilyet.

2) igen elértem. heti szintű scan megy a teljes hálózatomra, ami során a hálózatra kötött eszközök sérülékenységei is vizsgálatra kerülnek, és a feltérképezett hiányosságokat javítom is. (e miatt már pl. cseréltem Rooter-t is, mert már nem volt hozzá új kiadású Firmware)

Arra lennék kíváncsi - és gondolom, a fórumtársak is - hogy melyik alkalmazással vagy alkalmazásokkal oldottad meg a heti szintű vizsgálatot. Ha az alkalmazás(ok) használatába is beavatsz, az még jobb. Minél részletesebben.
Ugyanis erről kérdeztél korábban, és ezek szerint natív Linuxos megoldást találtál. Egy mindenkiért, mindenki egyért: megosztunk mindent, amit tudunk, megosztasz mindent, amit tudsz. Ez a fórum, a „support”, azaz a támogatás lényege.

Új, veszélyes számítógépes vírus terjedésére figyelmeztetnek kiberbiztonsági kutatók: a KryptoCibule nevű kártevő a torrentfájlok révén kerülhet rá a PC-kre, amiket ezután kriptopénz bányászatára használhat. A vírus ezt úgy éri el, hogy a számítógép erőforrásait lassítja, illetve a fő feladatának tekintett pénzbányászatra állítja át azokat. A HackRead szerint a KryptoCibule főleg a Monero és Ethereum digitális pénzeket bányássza,

-- melyhez a számítógép processzorát, illetve videokártyáját használja.

A KryptoCibule teljesen újnak nem mondható, a létezéséről ugyanis legalább két éve tudnak a szakemberek; az elmúlt időszakban viszont új funkciókat is megtanult, így ma már okosabb kártevőről van szó.

Forrás: https://m.hvg.hu/tudomany/20200907_torrent_virus_kriptopenz_kryptocibule...

Improper input validation in BlueZ may allow an unauthenticated user to potentially enable escalation of privilege via adjacent access," Intel notes in its advisory for CVE-2020-12351. BlueZ is found on Linux-based IoT devices and is the official Linux Bluetooth stack.

Google has detailed the bugs on the Google Security Research Repository on GitHub. Nguyen's description of the BleedingTooth vulnerability sounds more serious than Intel's write-up.

Részletek: https://www.zdnet.com/google-amp/article/google-warns-of-severe-bleeding...

A feltételezett hiba az 5.8 kernel verziókat érinti, az 5.9-es kernelt már nem.

@#157 Nyugodtan allhatok :)

uname -r
5.7.0-0.bpo.2-amd64

#158 Van. Feltehető a

• Linux Minthez az UKUU alkalmazással például
  https://teejeetech.in/ukuu/
• és az LMDE 4-hez a Debian Backports tükrön a fenti, de lehet forgatni az 5.9-est.
  Sőt, az  5.9.1-es verzió immár stabil. ;)
  https://www.kernel.org/
  https://linuxmint.hu/blog/2018/02/kernel-forgatas-4152
• ... mindkettőhöz egy turbózott: https://liquorix.net/ (hasonló, mint a lowlatency a tükrökről)

#156 Hú, már van 5.9-es kernel is? lemaradtam...

#160 Az LMDE 4 megkapta a foltot.

#159 Kicsit tovább kutattam...

Affected version: All Linux kernel versions that support BlueZ.
https://github.com/google/security-research/security/advisories/GHSA-h63...

A javítófolt elkészült. Itt már jelen:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Branch	Commit message	Author	Age
linux-4.4.y	Linux 4.4.240	Greg Kroah-Hartman	12 hours
linux-4.9.y	Linux 4.9.240	Greg Kroah-Hartman	12 hours
linux-4.14.y	Linux 4.14.202	Greg Kroah-Hartman	13 hours
linux-4.19.y	Linux 4.19.152	Greg Kroah-Hartman	13 hours
linux-5.4.y	Linux 5.4.72	Greg Kroah-Hartman	13 hours
linux-rolling-stable	Merge v5.8.16	Greg Kroah-Hartman	13 hours
linux-5.8.y	Linux 5.8.16	Greg Kroah-Hartman	14 hours
linux-5.9.y	Linux 5.9.1	Greg Kroah-Hartman	15 hours

Kis idő, mire a disztribúciók beteszik a tükrökről elérhető kernelbe.

Nálam a szolgáltatás nem fut:

systemctl status bluetooth.service --no-pager
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:bluetoothd(8)

Kiberbiztonsági kérdőív 2020 (lakossági)
https://ec.europa.eu/eusurvey/runner/kiberbiztonsagi_kerdoiv_lakossagi

Te már kitöltötted az online kérdőívünket?
Az Európai Kiberbiztonsági Hónap (ECSM) keretein belül arra vállalkoztunk, hogy megnézzük - szigorúan anonym módon -, hogy mit gondoltok Ti a biztonságos internethasználatról.
Segítsétek munkánkat az alábbi kérdőívek kitöltésével! Kattintsatok a megfelelő ablakra! Köszönjük!
-- Nemzeti Kibervédelmi Intézet

Kiberbiztonsági kérdőív 2020 (közigazgatási szervezetek és gazdasági társaságok)
https://ec.europa.eu/eusurvey/runner/kiberbiztonsagi_kerdoiv_gazdasagi_tarsasagok

„Köszönjük, hogy a kérdőív kitöltésével hozzájárult Magyarország kiberbiztonsági felkészültségének felméréséhez!”

Néhány hetente megjelenik egy-egy újabb biztonsági történet, amely azt mondja el, mennyire sebezhető a Linux rendszer. A legtöbbjükkel csak egy probléma van: hamis hírek. Az igazi probléma az alkalmatlan rendszergazdák létezése.

Mint minden operációs rendszer, a Linux sem tökéletesen biztonságos. Semmi sem az. Mint a biztonsági guru, Bruce Schneier elmondta: "A biztonság folyamat, és nem termék." Csak általában véve, a Linux biztonságosabb, mint versenytársai. A legutóbbi címsorokból nem lehetett megmondani, hogy melyik hárfa a Linux biztonsági sebezhetősége. De ha jobban megnézi, akkor ezeknek a történeteknek a legtöbbje - nem mind, de a legtöbb - hamis.

A problémák gyakran nem a Linux rendszerrel kapcsolatosak. A problémák a teljesen életképtelen adminisztrátorokkal vannak. És amikor azt mondom, hogy "teljesen alkalmatlan", pontosan erre gondolok. Nem a finom, apró hibákról bszélünk , amelyeket bárki elkövethet. Alapvető baklövésekről beszélünk.

Akár Windows Server, akár Linux, akár NetBSD rendszert futtat, és bármi is legyen a kritikus fontosságú rendszerein, ha a teljes biztonságban kudarcot vall, akkor nem az számít, mennyire "biztonságos" az operációs rendszere. Ez olyan, mintha egy kulcsot nyitott autóban hagynánk, feltörnék a rendszerét, ellopnák az autóját.

Szóval, elég legyen a Linux hibáztatásából. Hibáztassuk az igazi problémát: ami egyszerű rendszergazda alkalmatlanság (PEBKAC).

https://www.zdnet.com/article/enough-with-the-linux-security-fud/

(https://translate.google.com/translate?sl=auto&tl=hu&u=https://www.zdnet... )

https://www.youtube.com/watch?v=UrhNRYbgq6c

-----

Év elején kezdtem használni a Stubby-t, de akkor még ezt a leírást néztem:
https://www.linuxbabe.com/linux-mint/dns-over-tls-stubby

Nyilván a videó hozzá is tesz valamit, a névszolgáltató választásának kényszerítését, beállítását és ennek azért eléggé örülök, és élek is ezzel.
... már éppen javasolni szerettem volna a TAB használatot, de feltűnik később. :)

Ezek és a hasonló videók számomra a rádiózás aranykorát hozzák vissza: csak beszélnek és beszélnek, úgy tűnik, „szinte a semmiről”, és a lényeg mégis benne van (más videóikra inkább jellemzőbb ez, a másfél, két órásakra). ;)

-----

A DNS over HTTPS (DoH) a Firefoxban állítható be:

Beállítások > Általános > Hálózati beállítások > Beállítások > HTTPS-en keresztüli DNS engedélyezése > itt a Cloudflare az alapértelmezett beállítás

Leírás: https://support.mozilla.org/hu/kb/firefox-dns-over-https

A fenti leírásban említett „about:config > network.trr.mode ... és hasonlóak magyarázata:

https://wiki.mozilla.org/Trusted_Recursive_Resolver

https://www.ghacks.net/2018/04/02/configure-dns-over-https-in-firefox/

https://lifehacker.com/how-to-enable-firefoxs-more-secure-dns-over-https...

Kicsit küzdős, egyszer nekifutottam, de aztán abbahagytam, más elfoglaltság miatt.

A biztonság egyre fontosabb, nézelődni kell, olvasni, beállítani, amit feltétlen érdemes, élni a lehetőségekkel.

Teszt oldal: https://1.1.1.1/help

Hack és Lángos: https://hackeslangos.show/

Canonical published a new Linux kernel security update for all supported Ubuntu releases to address yet another Linux kernel vulnerability that could allow unintended access to data in some environments.

Affecting Ubuntu 20.10 (Groovy Gorilla), Ubuntu 20.04 LTS (Focal Fossa), Ubuntu 18.04 LTS (Bionic Beaver), Ubuntu 16.04 LTS (Xenial Xerus), and Ubuntu 14.04 ESM (Trusty Tahr), the new security vulnerability (CVE-2020-28374) was discovered in Linux kernel’s LIO SCSI target implementation.

https://9to5linux.com/another-linux-kernel-vulnerability-was-patched-in-...

Megoldás (teljes frissítés a javított csomagokra):

sudo apt-get update

sudo apt-get dist-upgrade

(a cikkben részletezett „full-upgrade” az aptitude-ra jellemző)

Biztonságos Internet Nap, 2021. február 9.

OS - A Nemzetközi Gyermekmentő Szolgálat Magyar Egyesület közleménye

Idén február 9-én tartották világszerte a Safer Internet Dayt,
vagyis a Biztonságos Internet Napot, melyre a Nemzetközi
Gyermekmentő Szolgálat (NGYSZ) mint a Safer Internet Program (SIP)
magyarországi konzorciumvezetője online rendezvényeket szervezett.
A Nemzetközi Gyermekmentő Szolgálat által szervezett SID
magyarországi együttműködő partnerei voltak a Microsoft Magyarország
Kft., a Nemzeti Kibervédelmi Intézet (NBSZ NKI) és az Országos
Rendőr-főkapitányság (ORFK).

A Safer Internet Day (SID) – Biztonságos Internet Nap hazai online
programjai:

Közös (online) sajtótájékoztatót tartott a Nemzetközi Gyermekmentő
Szolgálat (NGYSZ), a Nemzetbiztonsági Szakszolgálat Nemzeti
Kibervédelmi Intézet (NBSZ NKI) és az Országos Rendőr-főkapitányság
(ORFK), "Gondolkodj, mielőtt kattintasz" címmel. Kurkó-György
Zsuzsánna (NGYSZ), a Safer Internet Program projekt magyarországi
koordinátora kiemelte, hogy a mára már hagyománnyá vált Safer
Internet Day célja, hogy felhívjuk a figyelmet az internet helyes
használatának fontosságára, és arra, hogy ennek elsajátítása
mindannyiunk közös felelőssége. Ez a tudás egész életünket
befolyásolja. Ugyanilyen fontos, hogy akárcsak a valós életben, az
internet virtuális, arctalan tereiben is tiszteljük egymást.

Kurkó-György Zsuzsánna ezután röviden beszámolt a SIP 2020-as
oktatási és kutatási eredményeiről. A járvány miatt sajnos jóval
kevesebb oktatást tudtak megtartani, mint az azt megelőző évben.
2020-ban 5632 felhasználóhoz – 766 gyerekhez és 4866 pedagógushoz és
szülőhöz – jutottak el a SIP-oktatók személyesen vagy online
előadások, foglalkozások keretében. Összesen 166 alkalommal, 476
órát tartottak, 120 különböző helyszínen, 59 budapesti és 61 vidéki
iskolában.

A SIP 2020-ban hatástanulmányt is végzett, melynek során több mint
20 kérdést tett fel az internetbiztonságról szülőknek és
gyerekeknek. Ezt 260 szülő (87 papír alapú, 173 online), 1170 tanuló
(738 papír alapú, 432 online) töltötte ki.

A beérkezett szülői (260) és a tanulói (1170) válaszokból az alábbi
következtetések vonhatók le:

- 2020-ban a lakosság csökkenése ellenére a digitális eszközök
száma 2,2%-kal nőtt Magyarországon.

- A válaszadók 91,27%-a válaszolta azt, hogy otthon, a családban 3
vagy annál több okoseszköz (számítógép, notebook, tablet,
okostelefon) áll rendelkezésükre.

- A 13 év alattiak 86%-ának szabályozzák a szülők a képernyő előtt
eltölthető idejüket, míg 14%-uk időkorlát nélkül használhatják az
okoseszközöket. Meglepően nagy arányban (31%) van jelen a közös
megegyezésen alapuló szabályozás.

- A szülők mindössze 26,7%-a telepített a gyermeke digitális
eszközére szűrőprogramot.

- A megkérdezettek 20,35%-a volt 12 év alatti. A 12 év alattiak
76,97%-ának van más saját okoseszköze. A saját okoseszközzel
rendelkező 12 év alattiak 87,81%-ának korlátlan hozzáférése van az
internethez, és ebben a korcsoportban a megkérdezettek mindössze
2,1%-a nem rendelkezik egyáltalán internetes eléréssel.

- A megkérdezett gyerekeknek – akiknek az átlag életkora 14,57 év
volt – csak a 3,67%-a nem ismeri a cyberbulling fogalmát, 27,25 %-uk
még nem, 69%-uk pedig már hallott az iskolában vagy a baráti körben
történt internetes zaklatásról.

Az idei SID kerekasztalánál Bor Olivér, a Nemzetbiztonsági
Szakszolgálat Nemzeti Kibervédelmi Intézet szóvivője, Csanak
Gabriella, a Microsoft Magyarország marketing és operatív
igazgatója, Ságvári Bence, az MTA Társadalomtudományi Központ
tudományos főmunkatársa és Vezér-Kovács Dorottya r. főhadnagy, az
ORFK Bűnmegelőzési Osztályának főelőadója beszélgetett 2020
tapasztalatairól és a 2021-es év terveiről. Beszélgetésük mottója:
"Mit tehetünk együtt egy jobb internetért?"

További információk a Gyermekmentő Szolgálat weboldalának hírek
aloldalán találhatók: https://www.gyermekmento.hu/#news-section
Kiadó: Nemzetközi Gyermekmentő Szolgálat Magyar Egyesület
-------------------------------------------------------------------
Kérjük előfizetőinket, hogy az Országos Sajtószolgálat anyagait
minden esetben OS jelzéssel használják fel.
Az MTI szó szerint, minden változtatás nélkül továbbítja az OS-be
beadott közleményeket, a szövegekért minden esetben a közleményben
jelzett közlő a felelős.
(c) Copyright MTI Nonprofit Zrt.