Fórumok
Onnan a kérdés, hogy a minap uzemeltem be a Semaphore UI-t, aminek ugye nincs SSL opcioja, maga a doku is azt irja, rakjam forditott proxy moge, ha https-t akarok. Mivel mar van a local haloban egy forditott proxy, nem akartam meg egyet telepiteni, hanem egy SSH tunnelel atiranyitottam az Ansible node 3000-es portjat (itt hallgat a Semaphore) a Traefik-ba. (tuzfallal meg blokkoltam az Ansible node egyeb portjait)
Mennyire "tulgondolas" ez? Belso halozatban lehet komolyabb veszelyforras a plain text ?
Hozzászólások
"Mennyire "tulgondolas" ez? Belso halozatban lehet komolyabb veszely forras a plain text ?"
Válasz egy: Igen lehet, egy felől miért ne lehetne támadó egy belsős (elégedetlen) kolléga, más felől egy bejutott támadó (vagy féreg program) gyűjthet információt a belső forgalom figyeléséből is.
Válasz kettő: Igen túl gondolod, végül is ki a fene férne hozzá a hálózati eszközökhöz, ahol érdemben lehetne dumpolni a forgalmat.
Az én válaszom: Egy belsős CA -t össze dobni nem egy nagy kaland, akkor meg már miért ne lenne minden forgalom TLS titkosított. A kollégák gépeire teríteni a Root és Intermediate CA cert -et nem nagy dolog. Pénzügyei minden cégnek vannak, ergó titkolni, megvédeni valója is, szóval igen is minden forgalom - szó szerint minden - legyen TLS titkosított. Természetesen pont - pont titkosítás legyen, tehát a reverse proxy előtt és mögött is (DB connection is, localhost -on is).
Pár betűszó (és igen tudom, hogy bankra, biztosítóra, pénzügyi szektorra találták ki, meg céloznak velük): DORA, NIS2
----
올드보이
NIS2 elott allunk szal... (Tisax mar megy, ISO 27001 felkeszul :) )
OK, akkor nem gondoltam annyira tul :)
+1
Annyit tennék hozzá, hogy elég a root CA-t feltenni minden gépre, mert a (web)szerver úgyis el kell küldje a saját tanúsítványát és az összes intermediate CA-t is a kliensnek (a root CA-t viszont fölösleges).
A Zero Trust többek közt erről szól. Az, hogy kapun belül vagyunk (iroda, vpn) már rég nem szabad, hogy biztonságérzetet adjon.
Szóval forgalmat elszeparálni, vlanozni, csatornát titkosítani érdemes és kell is.
A Zero Trust arról szól, hogy mindenféle túlárazott biztonsági™ szutykot eladjanak ezzel a címkével. Buzzword.
?
ingyen van, csak tudnod kell mit csinálj. Példa mi ellen j
Hagyományos adatközpontban felnőtt fejlesztő szokás szerint nem, vagy csak látszólag védi az API-t, mert majd jól megoldja a sok infra. Cég fejlődik, költözik felhőbe, környezet is már szoftverből definiált, csak épp egy apró paraméter be lett nézve, és így mégsem zárt hálózatba kerül a szolgáltatás. Minden működik ugye, így senkinek nem tűnik fel. Amíg.
Na ezért van, hogy minden réteg, minden komponens lesz szíves magát védeni, és nem válaszolni mindenféle azonosítatlan kérésre, azonosítás lehetőleg az eredeti hívó féltől végig vezetve a láncon = zero trust, sose bízz abban, hogy védett környezetben futsz, vagy megbízható helyről kapsz kérés.
Ebben teljesen igazad van, csak itt a tákoláshoz szokott magyar KKV van felülreprezentálva.
Szerintem meg inkább a divatmotivált, buzzwordökben gondolkodó, mindent is túltitkosító, szélsőségesen idealista, fősodratú mérnök úr.
Én is szoktam mondani a kollegáknak, hogy a svájci sajtokat szeretem. Ha nem értik, akkor el szoktam nekik küldeni a "Swiss cheese model" szócikket a Wikipédiából.
Ahol en olvastam ott sokkal inkább egy modell, egy szemlélet. Szerintem egy termek nem volt megjelölve. Nem is tudnék erre univerzális termeket felsorolni. Ez egy szemlélet tényleg és minden cégnél más az illeszkedés.
Kicsit veszélyesebb terület lett az internet és sajnos a ceges LAN az elmúlt 20 evben.
Egy alap példa: Régen elég volt az intrában futó adatbázist úgy hagyni ahogy. Ma már jó ha külön subnetben van, külön vlanban és jó ha van tűzfala, ami LAN irányból is szűr és lehetőleg csak a cél alkalmazást szolgálja ki SQL porton és ssh-n csak az adminik IP címeire válaszol.
csak TLS1.3
es otthon is :)
neked aztan fura humorod van...
Jól switchelt LAN-on, ahol mindenki csak azt kapja meg, amit kell neki, ott nem fontos a TLS/SSL, gyakorlatilag túltitkosítás = bloat.
Felmerül a kérdés ugye, hogy mi van azzal az esettel, amikor adott gépen futtat egy támadó sniffert, és plaintextben lenyúlja az érzékeny adatokat a hálózati forgalomból. Nos, ez ellen pont nem véd a titkosítás, ugyanis a támadónak már megvan a root joga, amivel a sniffert futtatja, közvetlen low-level hozzáféréssel a hálózati interfészhez.
Szóval nem, én nem titkosítanám túl a LAN-t.
Malware-ek és kis gazdáik lájkolják ezt
FUD cikkek bértollnokai meg a te hozzászólásod, hogy benyaltad az üres riogatást, konkrét támadási vektorok végiggondolása nélkül.
Azért az kemény, hogy egy topikon kelül beszélsz arról, hogy a zero trust egy fölösleges buzzword meg arról, hogy "támadási vektorok végiggondolása"...
A Zero Trust pont azoknak a babzsákbiztonsági szakértőknek™ a vallása, akik nem szeretik végiggondolni a támadási vektorokat és mindent is fossá-húggyá titkosítanak, korlátoznak, hogy végül aztán dolgozni se lehessen már.
> Jól switchelt LAN-on, ahol mindenki csak azt kapja meg, amit kell neki
marmint 802.1x ?
Milyen az a "jól switchelt LAN"? Szerinted az IP telefonoknál a hangrögzítés hogy működik?
És mit szólsz a Wifihez, ahol minden kliens megkap minden keretet a közeg adottságai miatt?
Nincs olyan fogalom, hogy túltitkosítás. Minden titkosítás más-más támadási forma ellen véd és más-más funkciót nyújt. Egy MACSec, egy 802.1x, egy VPN, egy TLS/SSL teljesen másra való, más ellen véd, más layerben működnek.
Leírtam: Hogy a kliensek csak a saját csomagjaikat kapják meg.
Nem egészen. Az, amit snifferrel tudsz támadni, már csak a saját csomagjaid lesznek. Az, hogy a WiFi-s közeget támadod, már egy másik támadási vektor és OP nem beszélt WiFi-s közegről, csak LAN-ról. Kettőt kéretik nem összemosni, pláne hogy a WiFi-nek van saját titkosítása is, ami továbbra sem teszi szükségessé a LAN alkalmazási rétegben való túltitkosítását.
De igen, van ilyen fogalom. Amikor adott használati esetben az a támadási forma nem kivitelezhető, ami ellen a titkosítás véd™. Ilyenkor teljesen feleslegesen titkosítunk. Ettől még maga a titkosítás nem lesz felesleges, más esetekben igenis van értelme. Csak LAN-on, az OP által felvetett használati esetben nincs. Több értelme van az egyes gépek védelmének.
Ez így marhaság. Multicast / broadcast mond valamit? Na meg nem csomagok közlekednek LAN-on, hanem keretek.
Nem válaszoltad meg: Szerinted az IP telefonoknál a hangrögzítés hogy működik? Segítek: switch port mirroring.
Bocs, de ez egy újabb marhaság. A Wifi titkosítás csak a 2 rádió között véd valamit. Nem E2E. És nincs olyan, hogy LAN alkalmazási réteg.
Egy nagyon egyszerű kérdés: Mi a különbség a MACSec, 802.1x, VPN és TLS/SSL között titkosítási módok között?
https://a.te.ervelesi.hibad.hu/hamis-kompozicio-vagy-felosztas
A broadcastnak, multicastnak az a szerepe, hogy minden kliens (vagy egynél több kliens) megkapja a
csomagokatkereteket. Én azonban azokról a keretekről beszéltem, amik alapvetően két kliens között közlekednek.https://a.te.ervelesi.hibad.hu/hamis-kompozicio-vagy-felosztas
Irreleváns, hogy milyen alkalmazott megoldások vannak VoIP rögzítésre. Rögzítheted Asteriskből is, vagy bárhonnan, ahol hozzáférsz a forgalomhoz.
Captain Obvious strikes again. OP azt kérdezte, hogy alkalmazási rétegben titkosítson-e. Úgy látom, szándékosan nem akarod megérteni, amit mondok, amellett, hogy egyébként egymástól független, valid dolgokat írsz le.
Más-más rétegben mennek, de ez sem kapcsolódik szorosan az OP-nál felmerült kérdéshez, amire az a helyes válasz, hogy nincs értelme LAN-on átmenő forgalmat alkalmazásrétegből túltitkosítani.
🤣 🤣 🤣 Megint butaságot írtál. Tudod, az IP telefonok egyik jellemzője, hogy a teljes forgalom nem feltétlen megy át a központon.
Próbáltam finoman felhívni a figyelmed, hogy a switch port mirroring egy támadási faktor, ami ellen védekezni kell. Igen, ennek a támadási vektornak is vannak előfeltételei.
Én értem, amit írsz. Nagyon is. Egyszerűen triggerelted nálam a "faszság mérőt per hozzászólás" alapon és reagáltam a mondandódra. Nyugi, nem ellened szól, Trey és mások is kapják tőlem az ívet, ha arról van szó.
Látom, nem sikerült megérteni a mondandómat. Igyekszem kifejteni bővebben.
Egyrészt az OP céges hálózatról írt.
Másrészt 2024-t írunk, nem 2004-t.
Továbbá a védelmet hagymaszerűen érdemes felépíteni. Céges környezetben nem tudni, hogy hol milyen védelmek aktívak, milyeneket törtek már meg (csak nem tud róla az illetékes). Ezért kellenek a héjak. Az SSL/TLS is csak egy réteg a sok közül.
A kedvenc oprendszered (Windows XP) is ismeri az SSL/TLS-t - igaz, hogy gyárilag csak az elavult verziókat. Viszont lehet okosítani mondjuk egy stunnellel.
Csak hogy picit képezzelek dióhéjban:
- Adott egy cég 2 épülettel egymás mellett, összekötve optikával. L2-ben itt célszerű bekapcsolni a MACSec-t, ezzel védve a 2 épület közötti forgalmat illetéktelenektől - habár az optikai kábel észrevétlenül lehallgathatatlan elviekben.
- Biztosítanod kell, hogy a switchre csak a megfelelő kliensek kapcsolódhassanak L2-ben. Nem akarsz port security-val küzdeni - ami mellesleg átverhető, nem ad valós védelmet. Fogod, bevezeted a 802.1x-t EAP alapon. Ez csak authentikáció, nem pedig titkosítás!
- Távoli klienseknek kell biztosítanod a céges erőforrások elérést. Jéé, erre találták ki a VPN-t. Ez már ad authentikációt, titkosítást is.
Hajbi, néha egyetértek veled. Csak gyakran túltolod a butaságot. Na meg kérlek, IT securityval ne foglalkozz. Láthatóan nem értesz hozzá. Még. Tanulj, fejlődj, képezd magad. 😉
Tehát változatlanul: Rögzítheted Asteriskből is, vagy bárhonnan, ahol hozzáférsz a forgalomhoz. Triviális, hogy ha nem megy el a hívás az Asteriskig, akkor ott nem férsz hozzá a forgalomból. Szavak kiforgatását csinálod épp, nagyjából Zeller Mérnök Úr módra.
De nem feltétlenül alkalmazási rétegben.
Amik jelen esetben nem adottak.
Ennek örülök, de csakazértis ideerőlteted a világ összes támadási vektorát és a túltitkosítási idealizmusát.
Mindkettő csak egy évszám. Divatból, trendből, évszámbuziskodásból nem titkosítunk, mert az túltitkosítás (bloat).
Helyesen: nagyvállalati környezetben.
Tehát a MACSec túltitkosítás. Ugyanakkor, ha ezt hardver valósidőben megcsinálja és nem okoz semmilyen lassulást vagy fogyasztásnövekedést az eszköznek, akkor akár érdemes is lehet bekapcsolni. Az alkalmazásréteg túltitkosítására, amiről OP érdeklődött, ez messze nem igaz. Mindenféle overhead-eket rátesz a titkosítás.
Így igaz. Vagyis, nem tartozik a témához. Tehát offolsz.
Szintén nem tartozik a témához. Megint offolsz.
Általában én is egyetértek veled. Nem mondtam butaságot. Azt mondtam, hogy LAN hálózatban nincs értelme az alkalmazási réteget túltitkosítani, mert bloat.
IT vezetőként foglalkoznom kell vele. :)
Láthatóan a másik leminősítésével, szavak kiforgatásával, offolással szeretnél vitát nyerni.
Mindig tanulok és fejlődöm. Tudod, ezt Windows XP-ről is lehet, nem csak béta stabilitású Fedoráról, meg Windows 11-ről. :P
Tök jó veled eszmecserét folytatni. Írok 1 mondatot és arra te írsz legalább 3-at. Zseniális tőlem. 😇
Nyilván kiforgatom a szavaid, ha butaságot írsz vagy értetlenkedsz. Ne érezd magad kitüntetve.
Miért is nem adott? Egy céges hálózatban neked, mint Gipsz Jakab felhasználónak halvány lila dunsztod sincs, hogy ki férhet hozzá a switchekhez, ki konfigurálja, milyen kábelek vannak bekötve, honnan hová megy a forgalom. Ergo Gipsz Jakab nem bízhat meg 100%-ig a fizikai hálózat biztonságában.
Az egy másik történet, ha Gipsz Jakab beszélget Sótlan Sándorral (ő az IT üzemeltető, rendszergazda a cégben) a céges étkezdében, és megosztja Sándor Jakabbal, hogy hogyan épül fel a fizikai hálózat, milyen védelmi technikák vannak.
Erőltetem vagy csak a valóságban élek 2024-ben? Szerintem az utóbbi.
Most direkt nem hivatkozom a kedvenc oldalad (https://a.te.ervelesi.hibad.hu/). Tudod, azt akartam mondani, hogy 2004-ben sokkal több energiába (CPU, ram, tanúsítvány beszerzés, adminisztráció stb.) került az SSL/TLS megvalósítása E2E, mint 2024-ben.
Ez marhaság. Már mikro / KKV környezetben is hagymaszerűen érdemes felépíteni az IT védelmet. Minden pusztán kockázat értékelés- és elemzés kérdése.
🤦♂️ 🤦♂️ 🤦♂️
Számszerűsítenéd kérlek, hogy mennyi overheadje van az SSL / TLS-nek? Ez mekkora költséget jelent egy cégnek? Hogyan változik pusztán ettől a CAPEX / OPEX mértéke?
Hogy konkretizáljuk picit: 1000 céges felhasználó, 50 fizikai szerver, 300 VPS, 100 alkalmazás SSL/TLS-sel, 2 db DV wildcard tanúsítvánnyal, 10 db alkalmazáshoz dedikált DV tanúsítvánnyal.
Hát izé.... Csak a többi CxO, tulajdonosok meg ne tudják, hogy mennyire korszerűen gondolkodsz. 🧏♂️
Nem. Csak megállapítottam egy tényt. Sértő? Talán. Akkor lenne igazad, ha otthoni hálózatról beszélnénk - mondjuk IP kaputelefonról. Bár azért ott se árt külön VLAN, hogy ne továbbítsa az adatokat könnyen Kínába.
Nem használok sem Fedorát, sem Windows 11-t. Az utóbbi egy minősíthetetlen ipari hulladék lett véleményem szerint. Az előbbi még nem akkora hulladék, bár vannak próbálkozások, hogy azzá tegyék.
Windows 10-est használok. Még. De hamarosan átállok FreeBSD-re vagy Linuxra (Slackware / Alma).
Gipsz Jakab felhasználónak nem dolga a titkosítással bajlódni.
Erőlteted.
Kevesebbe, mivel kevesebb eszköz volt világszinten, beleértve a nem PC kütyüket is.
Ebben nincs vita, ugyanakkor túltitkosítani nem érdemes.
Így igaz.
A MACSec túltitkosítás. Ízlelgesd.
Ezt te is tudod, hogy erősen rendszerfüggő, így semmi értelme számszerűsíteni, mert nem lesznek általánosan érvényes számok, még százalékosan sem. Egyszer viszont majd próbálj meg egy gigabites hálózaton egy gyengébb géppel letölteni egy több tízgigás fájlt HTTPS-en keresztül, meg aztán HTTP-n keresztül. Vajon melyik fog lényegesen kevesebb CPU-t zabálni?
Hint: http://zingaburga.com/2015/02/tlsssl-cpu-usage-for-large-transfers/
Ez ugyanaz a kérdéskör, minthogy a többi software bloat, a bürokrácia, a mindenféle felesleges idalizmusok mennyi költséget jelentenek egy cégnek? Tipikusan az a kategória, ami a szélsőségesen idealista menedzsmentet nem szokta érdekelni.
Ne aggódj, mindent tudnak. :)
Igen, természetesen Kína és Oroszország miatt kell itt is aggódni. Véletlenül sem a cloud-multi miatt, akinek való továbbítás nélkül működni sem hajlandó. 🤡🤡🤡 (ha már emojizunk:D)
Végre valamiben egyetértünk ebben a threadben.
A Wayland-idealizmus erőltetése végett nyugodtan tekinthetjük ugyanakkora hulladéknak. Ha most nem, jövőre már mindenképp.
"Másrészt 2024-t írunk, nem 2004-t."
Nekem pont 2004-ben volt ebben vitám, mikor átvettem az üzemeltetést valakiktől egy ügyfélnél, bár amit csináltak azt nem nevezném üzemeltetésnek.
Na ott felhúztam egy mail szervert a meglévő semmi helyére és pont ezen kezdtek el rugózni, hogy minek az imapra és az smtp-re titkosítás a belső hálózatról, fölösleges terhelés a szervernek és a gépeknek :D :D : D (merthogy akkor még helyben lett ott a mail szerver az irodán belül)
Ekkor már kilógott a rúdjuk, aztán szép lassan ők lekoptak és én maradtam azóta is. Szóval már ekkor is lehetett ezen vitatkozni.
Elfelejtettem. Gondold meg... nyolcvanötször!
off: azért ne hordjunk már össze marhaságokat. Kíváncsi vagyok arra a rögzítőre ami egy SRTP-t kibogoz. Igen, volt ilyen, 20 éve divat volt, pláne h. nem volt SDES-se, de manapság azért remekül lehet PBX-en rögzíteni (igen, az ide-oda kapcsolt hívásokat is, és igen, nem megyünk direct audio-val ebben az esetben, de ezen ne álljunk neki vitatkozni)
on: kicsit kettőtök között vagyok, a titkosításnak (end-to-end) mindig van értelme, legyen az LAN v. akármi. Hogy _most_ ebben a pillanatban nem lehet épp sniffelni az jó, de lássuk be, bekerül egy managelhető switch és máris lehet ugye sniffelni. Csak reflektálok egy fentebbi "mégis hol?" megállapításra. És az ellenoldal: azért kkv-nál (de multinál is) láttam én már olyan dino appokat, ami azt sem tudta mi az h. titkosítás, ezekre nem biztos h. nekiállnék utólag máguskodni, ez egy kockázat amit elemezni kell. Vagy appot cserélsz vagy elfogadod mint létező kockázat pl. A hackelést viszont nem támogatnám én sem.
Utoljára kb. 10 éve foglalkoztam IP telefóniával. Akkor egy Siemens hibrid és több Panasonic analóg központot kellett upgradelni 1 darab hibrid Unify-re, továbbá az összes analóg és digitális készüléket lecserélni IP-re. Több telephely volt, a központ volt a központi telephelyen. Viszont azért, hogy ne kelljen méregdrága VXLAN képes switcheket venni, ezért sokkal olcsóbb volt mindegyik telephelyre külön rögzítőt tenni (DSR) + 1 db archiválót (SLDC) a központba.
A több telephely miatt nem volt egyszerű, mire belőttük a rögzítést. Nehézséget jelentett, hogy csak bizonyos mellékeket kellett rögzíteni és valahogy kezelni kellett az átkapcsolásokat is.
Attol hogy egy rendszergazdanak root joga van egy VM-en, ne adjuk meg neki azt a lehetoseget, hogy snifferelhessen egy LDAP authentikaciot hasznalo weboldal titkositatlan forgalmat, amibol kinyerheti a kollegak jelszavait plaintext formaban.
Jól switchelt LAN-on is meglehetősen könnyű arp poisoningot csinálni local subneten belül.
Ez. Ha hajbi hallott volna róla, akkor az egész buta szál meg sem született volna :)
Ne légy naiv :) megszületett volna az akkor is.
Régóta vágyok én, az androidok mezonkincsére már!
Azért várjuk meg - miután megpróbál utánanézni mi a fene ez - amint megpróbálja kifejteni, hogy az általa üzemeltetett (?) hálózatokban - aka. Jól switchelt LAN™ - hogyan védekezett ellene, avagy miért is nem volt rá szükség az XP fejlett biztonsági rendszerei mellett.
Hajbinak ez egy régi beragadt vesszőparipája, hogy "túltitkosítás". Több korábbi topic is volt: https://hup.hu/node/153022 , https://hup.hu/node/184151 ahol ugyanúgy lementek ugyanezek a viták vele. És ugyanúgy nem vezetett semmire.
Régóta vágyok én, az androidok mezonkincsére már!
Amire szintén nem az alkalmazási réteg túltitkosítása a válasz.
Nem a túltitkosítása, hanem a titkosítása. És igen. Minél kiterjedtebb egy hálózat, és minél több felhasználó van, annál inkább szükség van lehetőség szerint az end-to-end titkosításra, főként olyan kapcsolatokon, ahol az egyik végén valami felhasználó van. Egyre heterogénebbek a hálózatok, átviteli módok, még egy hálózaton belül sem lehet minden esetben kontrollálni, hogy ki mihez fér hozzá. Egy adatközponton belül maradó kapcsolat esetén - amennyiben ez megfelelően szűrve van illetéktelen hozzáférésektől - server-server közt - esetenként el lehet hagyni, de amennyiben a protokol támogatja, és/vagy érzékeny adatok közlekednek, mindenképpen érdemes bekapcsolni. Szóval a titkosítatlan kapcsolat legyen a kivétel.
Így, 2024-ben?!
Maga a kérdés felmerülése is igen nagy problémákat/hiányosságokat jelez...
szerintem.
zrubi.hu
A kérdésre adott kényszeres igen válaszok pedig még nagyobbakat.
Pláne amiket te írogattál ide...
A kérdés az volt , ki, mennyire veszi ezt komolyan. Nem az, hogy én hogyan viszonyulok hozza, azt nem kérdeznem, mert azt tudom :)
ha az lett volna a valasz, hogy igen, tulizgulom, akkor sem változtatnek a configomon :)
Céges környezetben ez nem egy emberen múlik, sokkal inkább a céges IT Security policy-n
Ahol nincs ilyen az meg nem vehető komolyan.
Egy bármilyen security related audit során egészen biztosan kiemelten figyelnek bármiféle plain-text kommunikációra. Hogy ez egyből bukó-e, az az audit céljától függ.
Szerintem.
zrubi.hu
Elvből TLS mindenhol.
De céges környezetben van olyan, amitől jobban félek mint a plain text. Pl. a jogosultságok osztogatása.
echo crash > /dev/kmem
Mindig is nagyobb kockázat lesz az emberi tényező, mint a plaintext, csak a plaintextet sikeresen démonizálták az IT-divatdiktátorok.
Ahol a naffőnöknek mindent is, meg az ájtísottanihajbbinak mindent is, nos, ott valóban lehetnek komoly adatvédelmi kockázatok... De ezeket a okckázatokat lehet _csökkenteni_ azzal, hogy a dróton csak olyan információ megy át, amivel harmadik fél nem tud mit kezdeni, mert kellően erős titkosított adatfolyamot lát belőle csak és kizárólag.
Developer pajtásnak nem lehet hozzáférése éles rendszerhez. Random ticketing toolban megkéri, mert csak.
Chaten/telefonon megy a pusholás a manager pajtinak, hogy deadlines meg milestones. Rányom.
Lesz OS reboot, lesz app deployment az appserver clusteren, lesz felhízott log file-ok törlése a developer pajtástól.
De nincs harmadik fél, hurrá. Ja de, a Developer pajtás az, full encryptálva, éles rendszerekkel játszadozva. (Nem az encryptálás ellen vagyok, még mielőtt...)
echo crash > /dev/kmem
- Mi az abszolút veszélyes?
- Naposcsibe root passworddel :)
marmint Root kiskacsa, nem?
Csak hogy belekotnyeleskedjek.
TLS helyett service csak localhostra kiengedve. Akinek el kell tudnia érni, az meg ssh tunnel.
Nem is értem ezt a TLS fétist amúgy. Hányadik verziónál járnak jelenleg (SSL-t is beleértve)? Az SSH-nál soha nem kellett ilyen sebességgel dobni a régi implementációkat.
Perpillanat 1.3-nál. Wikipedia: https://en.wikipedia.org/wiki/Transport_Layer_Security
Kis történelem dióhéjban és leegyszerűsítve - picit puskáztam a Wikipediából az évszámokat:
- SSL 2.0 (1995): Kijött vele a Netscape, ha jól emlékszem. Mindenki örült, amíg rá nem jöttek, hogy lyukas, mint a szita.
- SSL 3.0 (1996): Még mindig Netscape. Sokáig sok helyen használták. Ez is lyukas, mint a szita.
- TLS 1.0 (1999): Kis túlzással SSL 3.0 picit tupírozva és átnevezve. Meg kidobtak pár olyan ciphert, amiktől az SSL 3.0 lyukas volt (pl: RC4). Viszonylag sokáig használták. Mára nem számít biztonságosnak.
- TLS 1.1 (2006): Kis tupírozás. Mára nem számít biztonságosnak.
- TLS 1.2 (2008): Végre elkezdték feljavítani az elavult és nem biztonságos részeket (SHA-1 -> SHA-256). Manapság biztonságosnak számít, nincs formálisan se elavulttá nyilvánítva.
- TLS 1.3 (2018): Nagyon sok szoftver még nem kezeli. Nginx például sokkal régebb óta beszéli, mint Apache HTTPD - ha jól emlékszem.
Szóval mostanság legalább 1.2-t kell használni - ellenjavallt az 1.2 tiltása. Ha 1.3 is megoldott oda-vissza, az még jobb a jövőre nézve.
Hova vezet ez a nagy rohanás...?
Általában jól működő eszközök újravásárlásához.
Azt, hogy jól, azt tessék idézőjelbe tenni... Egy SSLv2-only szerver is titkosít, meg kiszolgál, azaz működik. Csak épp a titkosítási-biztonsági oldalról nem mondható el róla, hogy "jól működik".
Nem ezekről beszéltem, hanem azokról az eszközökről, aminek a gyártó multikája túl milliárdos kompatíbilitási frissítéseket kiadni SSLv3-ra, ezért az egészet újra kell vásárolni, pedig az SSLv2-t leszámítva egyébként kifogástalanul működik.
Hajbi, mutass nekem olyan működő eszközt 2024-ben, ami csak SSLv2-t tud, de nem tud SSLv3-t és aktívan használják azt az eszközt.
Gondolom a 3G-only vadkamerák, amikből valaki nagyon bevásárolt, és hajbinak az most qrvára fáj... :-P
160x120-as felbontásban? Mert abban az időben (1995) még ilyenben is dolgoztak. És nem a hőkamerák szenzoráról beszélek. 😉
Ha SSLv3-ra,alias TLS1-re frissülne, az is régen rossz lenne, de sebaj... TLS 1.2 megfelelő algoritmusokat használva tekinthető manapság megbízhatónak,mindaz,ami ennél gyengébb, az nem.
"az SSLv2-t leszámítva egyébként kifogástalanul működik."
Helyesen: "a biztonságos hálózati kommunikációt leszámítva kifogástalanul működik". Csak ugye ahol hálózati forgalom van. és titkosítással _kell_ védeni az adatokat, ott pont a biztonságos hálózati kommunikáció az egyik igen lényeges funkció, ami bizony nem "kifogástalanul működik", hanem finoman és illedelmesen fogalmazva "nem az elvárásoknak megfelelően működik" (röviden: sz@r. Pláne ha SSLv2...)
Egyrészt a világ változik. Ami 10 éve még biztonságos volt, az mára nem biztos, hogy még mindig az.
29 év (1995-2024) alatt 6 verzió. Ezt nem nevezném rohanásnak.
Másként kezelik a verziókat. Algoritmusok, kulcstípusok rendesen változtak, mióta SSH2 van, időről időre meglepetést is tud okozni egy sima ssh upgrade, mert régi algoritmust default már nem fogad el, jó esetben ssh(d)_configban módosítható, rossz esetben úgy sem.
mindehol TLS -
mert, most LAN - de holnap ki tudja és 1x megcsinálni.
WOKEBUSTERS
https://www.cpachungary.com/wokebusters
Mindenhol is: data in transit, data at rest. Ha van barmi adatod, informacio csered, azt titkositod, es hozzaferest szablyozod szemely/ter/ido alapon, majd loggolod (lasd: audit log) stb.
Az adott kerderdeshez... Mit ersz el az UI-n keresztul jelenleg, es mi a terv a kesobbiekben? Van-e/lesz-e koztuk barmi erzekeny info, pl. gyoker ansible playbook credentialokkal (amugy is botozas jarna erte), kulonfele kulcsok stb.? Mi van, ha valaki vicces kedveben van, epp felmondtak neki, vagy csak szorgalmas hulye, es "megjavit" valamit az atjarohazon keresztul? Mi van, ha ezen kereszul piszkaljak meg a menedzselt rendszert, ott milyen adatokhoz ferhetnek hozza (ah, csak az SAP)?
A kerdes nem az, hogy http:// vagy https://, hanem az, hogy hogyan veded meg az egeszet, hogyan jossz ra, hogy valami nem ugy van, ahogy lennie kene, es vegul miert nem fizet kotbert vagy karteritest a ceged customerei es partnerei fele, ha megis gaz van.
anno megkérdeztem a hetzner supportot, hogy a "vSwitch" szolgáltatásukban tudják-e garantálni, hogy más nem kapja el a csomagjaimat... és azt mondták, hogy nem tudják...
szóval, az egymás melletti szerverek között is vpn lett...
olyan, hogy "túlgondolt security" nem létezik...
Ha már LAN-on belüli titkosítás szerverek között.
MACSec-et nem probálta valaki úgy hogy a köztes switch nem tud MACSec-t.
Elvileg úgy van kitalálva hogy működik így is.
https://developers.redhat.com/blog/2016/10/14/macsec-a-different-soluti…
Távoli vonalakon (cseh, szlovák, stb.) irányokban használtunk MACSecet, fene se tudja, hogy a providerek hálózata hogy épül fel, de mivel nem sotétszál, biztos volt közte több switch is. Működött, de emlékszem arra, hogy volt vele időnként szívás, de mivel én közvetlenül nem találkoztam a konfig részleteivel, ennél többet nem tudok.
akkor már wireguard
Másra való. Úgy is mondhatnám, teljesen más szint. Maga a MACSec mindent átvisz, amit átroute-olnak rajta, nincs korlátozás címtartományra, protokolra (v4/v6), vagyis teljesen transzparens, csak épp titkosítja az átmenő forgalmat.
ha jol latom ez ket gep kozott jo. n gep eseten eleg nehez beallitani, nem?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ubiquiti airfiberen átment
Tisztázáskepp. A configom en így csináltam , titkosítva mindent . Nem akarok rajta változtatni , nem azért írtam ki , mert tanácsokat kerek ( ezt nem nagyképűségbol írom , egyszerűen azért mert tudom, jelenleg full titkosítva van )
a topic címe “LAN-ban (céges, nem otthoni) ki mennyire figyel a TLS/SSL-re?” Tehát az érdekel , ki hogy áll hozza. Tehat mennyire kell LAN ban egyesek szerint komolyan venni a plain text et.
Itt írok, mert kicsit túlfűtött a fő szál.
Szerintem fontos, és egyre fontosabb. A titkosító zsarolóvírusok után/mellett az adatlopás az új illegális pénzforrás, amivel zsarolni lehet az adat eredeti gazdáját. Emiatt mindent ellopnak amit csak lehet, hátha egyszer értékes lesz (már rég nem csak célzott támadások vannak értékes célpontok ellen). Szerintem inkább menjen pár CPU ciklus pluszba titkosításra, minthogy el lehessen lopni az adatot, amiből később baj lehet.
Ez LAN-on is ugyan így igaz, mert sok céghez beférkőznek különböző módokon, elrejtenek valami figyelő/adatgyűjtő szoftvert/rendszert, és csak hetek-hónapok után lendülnek akcióba, mikor már van elág infó a belső rendszerről. Ha titkosítottak a kommunikációk, nagyságrendekkel nehezebb dolguk van a támadóknak a felderítéssel, hozzáférés szerzéssel.
Mi is, mint a legtöbb hazai mikro- és kisvállalkozás, nagyon gyerekcipőben járunk ilyen védelmi téren, de erősen rá vagyunk állva, hogy javítsunk ezen.
én nem csak cégesben, hanem otthon is. sőt a local devszerveremen is
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
A tanúsítvány kezelését hogy/mivel oldjátok meg? Van valami központi eszköz erre? Minden eszköznek van domain neve ?(Úgy rémlik, nem feltétlen kell, de ajánlott) Lejárati idők, root cert? Nem hajbi féle kötekedés, tényleg érdekelne, hogy érdemes otthoni eszközöknél megoldani. Szeretek bíbelődni a kütyükkel, de jó lenne olyan rendszer, ami akkor is elvan, ha nem tutujgatom és nem kell aggódni, mikor jár le a cert.
Nekem az otthoni LAN-on saját CA-m van.
Ehhez persze nem árt kicsit érteni, hogy értelmes végeredmény legyen belóle ;)
- TLS cert (ellenőrzés) nem csak domain alapján lehet, megy az IP-vel is, csak bele kell tenni megfelelően a tanúsítvány (request) be.
- Ha saját CA-d van akkor te döntesz a lejárati időkről. Nálam pl. server tanúsítványok: 10 év, VPN végpontoké csak 1.
Persze a végponotkkal néha meg kell küzdeni, mobiltelefonok is (gyártótól függően) hisztiznek a privát cert-ek miatt, IoT-n meg van ahol a titkosítás is ismeretlen fogalom :D szóval elég nagy a szórás, és a végeredmény gyakorlati haszna erősen megkérdőjelezhető (hacsak nem a tanulás és tapasuztalat szerzés az)
zrubi.hu
https://github.com/FiloSottile/mkcert
egyszer kellett a CA, utána lehet kiállítani a certeket. otthon a gépek gepnev.otthon.sajatdomain.hu alakban vannak, dns ez alapján van feloldva
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
Én ahogy látom, ezzel kapcsolatban (is) táborokra szakad a szakma:
De ha már Zero Thrust ki hogy áll a lokális tűzfalazással? Van? Kifelé / befelé is szűr? Közvetlen internet elérés?
Aztán pár buzzword:
----
올드보이
Az a baj, hogy már 2024-t írunk. Sokkal több eszközre, technológiára és technikára, hozzáértésre van szükség a sikeres védekezéshez. Mert tudjuk: a támadó mindig előnyben van. Mindig.
Habár ezek buzzwordnek tűnhetnek, sajnos jó okuk van a terjedésüknek. Amikor a kedves IT fejlesztő kolléga odajött hozzám, hogy hát nem megy az internet én meg az orra alá nyomtam az IDS/IPS logokat a munkaidőben, munkahelyi gépen, munkahelyen nézett pornóról, örömlányos weboldalakról.... (megtörtént eset, 2013-ban)
Véleményem szerint.