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.
a lakasodhoz meg a ceges irodahoz is a labtorlo alatt tarolod a kulcsod (termeszetesen kiirva az ajtora az infot)? ha nem, akkor szimplan kettosmerces faszsagokat beszelsz. :)
https://a.te.ervelesi.hibad.hu/hamis-dilemma
nincs ervelesi hibam. ha szerinted barmelyik ertektelen, minek kene vedeni?
a gond, hogy szerinted az adat - ilyenten - ertektelen. ez pedig a te ervelesi hibad. #kettsomerce.
Van érvelési hibád, mert két szélsőség között akarsz kényszerűen választani.
https://a.te.ervelesi.hibad.hu/hamis-okozat
Nem értéktelen, csupán a LAN-on átmenő forgalmat nincs értelme alkalmazásrétegből túltitkosítani. Én ennyit mondtam. Ez nem a kulcs lábtörlő alá rakása, hanem annyi, hogy 2 zár mellé nem rakok be felelegesen egy harmadikat, ha a másik kettő is zárja az ajtót, csakhogy lassítsam a mindennapi rutinomat (bezárás, kinyitás).
nincs ket szelsoseg.
csupán a LAN-on átmenő forgalmat nincs értelme alkalmazásrétegből túltitkosítani > ez meg butasag.
Ez nem a kulcs lábtörlő alá rakása > de, az.
hogy 2 zár mellé nem rakok be felelegesen egy harmadikat > titkositatlan, ergo 0 darab kulcsparral dolgozol. nyitott ajtokat tetszik dongetni. :)
csakhogy lassítsam a mindennapi rutinomat (bezárás, kinyitás). > attol, hogy a zsebedben van az auth token(TLS), az ajto magatol nyilik. user oldalrol 0 dolgod van ezzel. biztos jartal mar a https://hup.hu-n, ott sem kell semmit nyitogatni meg csukogatni.
ebbol is latszik mennyire nem vagy kepben.
titkosítatlan != nem biztonságos
De a processzornak igen = bloat.
Hozod a szokásos szélsőségesen idealista, fősodratú, csőlátású formádat, ebben is.
titkosítatlan != nem biztonságos > na innentol engedtem el :) orulj csak a plaintext jelszavaidnak es a titkositatlan adataidnak.
Jól van, dorsyka.
Ez a dzsolidzsókered? Ha valami nem tetszik előhúzod? :D
Nem akkor, ha valami nem tetszik, hanem akkor, amikor valaki két szélsőség közötti hamis dilemmát állít fel.
Itt a két szélsőség: mindent is titkosítani, semmit se titkosítani (lábtörlő alá tett kulcs)
Ráadásul van még egy csúsztatás is a dilemmában, mégpedig az, hogy a titkosítás hiányát dorsyka a lábtörlő alá tett kulccsal teszi egyenlővé, amivel azt állítja (hamisan), hogy semmilyen körülmények között nem biztonságos a plaintext.
Ó, te kedves, nyári gyermek.
Blog | @hron84
via @snq-
É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.
Meg azoknak az egyszerű üzemeltetési, ITsec, stb. szakiknak a "vallása", akik nem képzelik magukat istennek, és úgy gondolják, hogy nem ismerik az összes lehetséges támadási módot és lehetőséget, így a számukra ismeretlen módszerek ellen a zero trust elv használatával védekeznek.
Örülök, ha Neked végtelen tudásod, és hasonlóan sok időd van egy komplex rendszer esetében az összes támadási vektor végig elemzésére, hogy ki tudj zárni néhány kapcsolatot a titkosításból.
A mai hardverek (ide értem a most 10 éveseket is...) mellett a biztonság növelése, titkosítás bevezetése nem észrevehető a munka során a teljesíményen.
A biztonság növelésével csak a kényelem csökken. Az üzemeltetés kényelme, mert a biztonság plusz munka, és olykor a felhasználó kényelme, mert a biztonság plusz "munka".
Mondj egy releváns, való életből vett példát, amikor a kapcsolat SSL/TLS titkosítása a munka rovására megy, vagy érdemi plusz költséget okoz, és ha nem lenne SSL/TLS titkosított a kapcsolat, akkor sem lenne jobban támadható a rendszer, könnyebben megszerezhető az adat. Előre szólok, hogy ezt a topikot mostanra aránylag sokan olvassák, és így a példádnak elég sok okos ember tudását kell kiállnia a megmérettetés során.
A mai hardverek, amiken csak akkor futnak a biztonsági™ megoldások™, ha a régi hardvereket kidobjuk és újravásároljuk mai hardverekre. Ami fenntarthatatlan és éppen ezért kerülendő.
Meg a bloat növekszik. Az üzemeltetés kényelme pedig nő az olyan megoldások által, ahol minden is túl van titkosítva.
A költségeket 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?
http://zingaburga.com/2015/02/tlsssl-cpu-usage-for-large-transfers/
https://a.te.ervelesi.hibad.hu/tekintelyre-hivatkozas
Okos emberek is szoktak trendbuziskodni. Okos ember általában azt is tudja, hogy egy legacy rendszer (pl. Windows XP) is használható biztonságosan netre kötve, mégis sok okos ember ezt nem meri elmondani egy fórumon, mert fél, hogy veszít a reputációjából. Ergo, okos ember ugyanúgy vélekedhet trendből, divatból vagy félelemből, mint egy nemokos IQ=80 ösztönlény.
Azt gondolom, hogy nem Trabanttal vagy Ladával jársz, és a munkahelyed sem használt Zsuk-ot vagy Izs-t vagy IFA W50-et teherszállításra.
Ha igaz az állításom, akkor az azért van, mert van helyettük modern alternatíva, és költséghatékonyság okán le lettek már cserélve. Pedig a legnagyobb részük némi tutujgatással a mai napig működik, vagy működne, és pont ugyan úgy elvinne Téged is meg az árut is.
A számítógépek ugyan ilyen eszközök. Amikor elavul és/vagy a feladat megköveteli, akkor le kell cserélni.
Arra hivatkozni nagyon gáz, hogy azért ne legyen titkosított a forgalom, mert egy régi gyengébb géppel, gigabites halózaton túl sok CPU erőforrást fog igényelni az átvitel. Ezen felül nem életszerű, hogy HTTPS kapcsolaton rendszeresen többtíz gigás állományokat töltesz le régi, erőforrásban szegény géppel. Mert ugye ha a gép régi és gyenge, akkor mi a bánatot csinál majd a letöltött többtíz gigás állománnyal?
Ráadásul ebben a pédádban a kérésemmel szemben nem tértél ki arra, hogy miért is biztonságos TLS nélkül, kevesebb CPU erőforrással letölteni az a többtíz gigát a régi gépre. Arra hivatkoztál, hogy a gép nem bírja erőforrással, ezért kell nélkülözni a titkosítást, nem arra, hogy nem szükséges a titkosítás, mert az adat e nélkül is biztonsában marad az átvitel során. https://a.te.ervelesi.hibad.hu/mazsolazgatas
Tehát, ha Te írsz egy példát, ahol szerinted nem kell SSL/TLS és a kapcsolat úgy is biztonságos, és ezt itt sokan megcáfolják, akkor Ők mind rosszul tudják, és a Te verziód marad a helyes, mert az a sok cáfoló mint épp trendbuziskodik ahelyett, hogy okos lenne. Erre melyik szócikk érvényes kedvenc érvelési hibás oldaladról? Mondjuk pl. a https://a.te.ervelesi.hibad.hu/lenyegtelen-konkluzio
Nem egészen. A személyi számítógépek az elmúlt 10-15 évben alig fejlődtek. A szándékos elavultatás, a bloat, a szoftverek megnövekedett erőforrásigénye miatt vásárolják újra őket. Lásd a legújabb fiaskó a Windows 11-gyel, amiben a Microsoft tollvonással avultatja el a 8. generációnál régebbi, egyébként kifogástalanul működő számítógépeket. Mindeközben amúgy a rendszer pontosan ugyanarra lesznek használva, mint elődei.
Egy IFA teherautó és egy modern kamion között akkora különbség van, mint egy Videoton TV Computer és egy 2. generációs Intel processzorral szerelt PC között. Egy 2. generációs és egy 10. generációs PC között nincs ekkora különbség.
Nagyonis életszerű, pláne ha az ég világon semmi szükség nincs adott erőforrás titkosítására, hiszen azt a hálózaton definíció szerint mindenki elérheti.
Kerülgeted a lényeget. A titkosítás a szoftverfrissítésekkel egyre bonyolódik, egyre bloat-abb, lassabb és erőforráspazarlóbb lesz. Így előbb-utóbb már nem csak a régi gépen lesz overhead-je.
https://a.te.ervelesi.hibad.hu/allito-kerdes
Se nem biztonságosabb, se nem kevésbé biztonságos.
https://a.te.ervelesi.hibad.hu/szalmabab
Nem mondtam, hogy mindenki más rosszul tudja. Azt mondtam, hogy előfordul, hogy trendbuziskodásból titkosít, ami nem egy racionális döntés, hanem pont ugyanolyan hívő gondolatmenet, mint a laposföld.
Az az igazság, hogy most ebbe belefáradtam, mert szemmel láthatólag Te tudod jól a világot, mi meg mind rosszul, bárki bármit ír, mond, érvel. Úgyhogy én ezt itt most el is engedem.
Kettő dolgot azért leszögezek. Nem Neked, mert Téged nyilván nem érdekel, hanem másnak, aki olvassa ezt a szálat:
^ Az egód kötelező sorai, finomított rage quit után.
Ez milyen gyakori esemény?
Az adatátvitel elég gyakori esemény egy hálózaton. :D
Akkor még egyszer megkérdezem: Milyen gyakori esemény, hogy egy gyengébb gép egy gigabites hálózaton több tízgigás fájlt tölt le?
Bármilyen adatátvitel, ami létjogosultságot ad a gigabites hálózatnak.
Ne terelj! A kérdésre felelj: Milyen gyakori esemény, hogy egy gyengébb gép egy gigabites hálózaton több tízgigás fájlt tölt le?
Te se lovagolj a 10 gigás fájlon: Bármilyen más túltitkosított adatátvitel esetén is ott van ugyanaz az overhead.
A 10 gigás fájlt azért mondtam, mert azon könnyebben és egyértelműbben mérhető az overhead.
Tehát megint nagyot akartál mondani és még az egyszerű kérdésemre se feleltél (milyen gyakori ez az esemény). Köszönöm. 1-0 ide ebben a szubszálban.
Egy gyengébb gép nem 1 nagy fájlt (nagy fájl: 1 GB-nál nagyobb) húz le, hanem sok kicsit. Azokat is ritkán, egyenlőtlen eloszlásban. Egy böngészés, egy Word doksi olvasás/írás, egy Excel táblázat matatás tipikusan ilyen.
Egy lassú gép többnyire az alábbi esetekben húz le nagy fájlokat:
- Ha újratelepítik.
- Ha frissítik az oprendszert (többnyire Windows, mert Linux picit másabb).
- A fájlokat másolni akarják külső adathordozóra (pendrive, CD/DVD írás).
Terelés és öntömjénezés helyett inkább mondd meg, mitől kevesebb a túltitkosítási overhead-je ugyanazt a 10 GB adatmennyiséget tartalmazó sok kis apró fájlnak. Konkrétan még több is, a HTTPS felépítése miatt.
🤦♂️ 🤦♂️ 🤦♂️
1. Semmi köze a HTTPS-nek, hogy 1 darab 10 GB-os fájlról vagy 10000 darab 1 MB-os fájlról beszélünk.
2. Egyszerűség kedvéért: Mérd le kérlek mondjuk Wiresharkkal, hogy mennyi adat (bit) mennyi idő (milisec) mozog L2 szinten 2 végpont LAN-on (Ethernet, IPv4) között, ha
a.) 1 darab 1 GB-os fájlt (mondjuk Linux .iso)
b.) 1000 darab 1 MB-os fájlt (az előbbi .iso-t feldarabolni 1000 darabra)
c.) a.) verzió, de HTTPS-sel
b.) b.) verzió, de HTTPS-sel
Kíváncsian várom a mérési eredményt!
Pici segítség: https://www.keycdn.com/blog/https-performance-overhead
Pont arról a rossz végéről fogod meg a dolgot, mint a TDP-idealisták, meg a flops/Watt huszárok.
A titkosításnak, így a HTTPS-nek is, CPU-overheadje van. Minden alkalmazásrétegbeli titkosításnak CPU-overheadje van.
🤣 Terelés, mellébeszélés. Remélem, hogy IT vezetőként nem művelsz ilyet....
Tehát nem tudsz semmilyen mérést mutatni hálózati szinten - mert ugye te hoztad fel a gigabites hálózatot. Most meg már CPU-ról beszélsz. Q.E.D. 2-0 ide. 🙂
AES-NI utasításkészlet bővítmény ismerős? Szerinted miért találták ki? De ha elfelejtjük ezt - ami 2008 óta, tehát 16 ÉVE benne van az Intel CPU-kban, ARM-ben 2011 óta, IBM z9 óta, akkor is mondd már meg kérlek, hogy mekkora ez az overhead?
De, műveli, sőt, még büszke is rá.
Igen, pontosabban, büszke vagyok rá, hogy nem túltitkosítok.
Amekkora a library-jé, ami véletlenül elfelejti használni.
Pentium 3-on pedig nagyon szépen látszik az az overhead.
Miért nem DOS-t használsz? Az XP grafikus felületének iszonyú CPU overhead-ja van a DOS-hoz képest.
Van rá Lotus 1-2-3 táblázatokhoz, meg többszéle, akár TUI-s szövegszerkesztő, és még TCP/IP stack is, ha hálózatoznál. Régi (nagyon régi) gépen is jól működik. Nem értem, miért kellett kidobni a DOS-os gépet, és a profitmultitól új gépet meg új oprendszert venni, mikor mindent meg tudtál csinálni addig is.
Csak égeted a wattokat, így a pénzt a grafikus felület kirajzoltatásával, a tök felesleges CPU overhead-dal.
Helyesen: Windows 7-től a Windows-ok grafikus felületének iszonyú overhead-je van a Windows XP-hez képest.
Miért? Mert babzsákfejlesztőék jónak látták a GDI API-t szétbarmolni, kivenni évtizedek óta működő hívásokat.
A kérdés az volt, hogymiért nem DOS-t használsz, hogy elkerüld a _bármilyen_ Windows verzió grafikus felületének megjelenítése miatt jelentkező CPU overhead-et.
Kérlek, erre válaszolj.
Az nem érdekel, hogy a Windows XP-hez képest mi van az újabb Windows-okban. A kérdés az volt, a DOS-hoz képest miért fogadsz el CPU overhead-et a fancy grafikus megjelenítés miatt akkor, amikor jóval kisebb CPU overhead elfogadhatatlan számodra a kommunikáció biztosítására, ami viszont a való életben nagyságrendekkel fontosabb, mint a szép grafikus felület.
https://a.te.ervelesi.hibad.hu/mazsolazgatas
> 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.
Leírod kérlek nekem, laikusnak, hogy egy jól switchelt VLAN hogy véd mondjuk a DNS poisoning ellen, vagy a MITM támadások ellen (ami szintén faktor hálózaton belül is)?
Igazad van abban, hogy a fizikai hálózat védelme kritikus pontja a védekezésnek. Azonban rengeteg olyan támadás van, ami nem a fizikai hálózat rétegében (amire ugye a switchnek/VLAN felosztásnak kihatása van) történik, hanem sokkal feljebb, akár application layerben, amire egy normál switch nem lát rá. Ezért fontos minden layerben védekezni, mert simán van olyan támadás, ahol mindenki csak a neki szánt hálózati csomagokat/kereteket kapja meg, mégis adatszivárgás történik. A TLS/SSL az az applikációs réteg alatt biztosít védelmet, ahogy pl a L3 tűzfal meg a TCP/IP layerben véd. Mentül több rétegben van védelem, annál biztonságosabb a hálózat.
Ez kicsit hasonlít a többszörös védelemmel ellátott helyekre, mint pl a repterek. Fémdetektor, röntgen, szúrópróbaszerű emberi átnézés, okmány ellenőrzés, stb. Több rétegben, több módszerrel ellenőrzik az átmenő forgalmat. És nyilván nincs 100%-os védelem se itt, se ott, van ami átcsúszik így is.
Blog | @hron84
via @snq-
Hagyjad mar. Most jutott el odaig, hogy nem HUB-ot hasznalunk, hanem menedzselheto switcheket.
Majd meglesz a tobbi is, csak varni kell picit, hogy atszivarogjon a ver-agy gaton.
Í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
Az IT Security policy összeállítása sok cégnél 1-2 emberen múlik. És a legtöbb audit addig megy el, hogy ha ez le van céges szinten szabályzatban írva, akkor pipa, mehetünk tovább. Sok szempontból ezek az auditok nevetségesek rengeteg pénzért. Az a szerencse, hogy sok helyen dolgozik olyan informatikus, aki érti, hogy ezeknek az szabályoknak mi a tényleges célja, és beleáll abba, hogy ezt márpedig valósítsuk meg, mert fontos, mert ad a biztonsághoz.
Blog | @hron84
via @snq-
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
Ilyenkor kell a support managernek egy levelet írnia CIO, CTO, CEO, hogy ezt kérték tőlünk, ilyen joggal, megcsináltuk, mert muszáj, de ilyen és ilyen security kockázata van, bármilyen probléma esetén a döntésért ez és ez a manager volt a felelős, a support semmilyen felelősséget nem vállal ezért, üdvözlettel.
Másnap szokott jönni a levél az idézett managertől, hogy bocsi-bocsi, félreértés történt.
Blog | @hron84
via @snq-
- 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. 😉
Csak szándékosan 20 évvel többet ugrasz vissza az időben, mint amiről szó volt, hogy könnyebben megtámadhasd a véleményem.
https://a.te.ervelesi.hibad.hu/szalmabab
Azért, mert marhaságot beszélsz. Megint.
Meg ha megnézted volna a https://hup.hu/comment/3115560#comment-3115560 kommentem, akkor látnád, hogy SSLv2 az 1995-ben volt. 1996-ban már SSLv3. Ergo 20+ évet vissza kellene ugranom, hogy találjak olyan eszközt, amire te hivatkozol.
Nincs olyan aktívan használt, működő eszköz 2024-ben, ami csak SSLv2-t beszél, de nem tud SSLv3-t. Nagyot akartál mondani. Nem jött be.
De a TLS 1.1 és TLS 1.3 viszonylatában bőven van. Szóval koncentrálj inkább ezekre, ha szeretnéd megérteni a lényeget.
Ne terelj! Mellébeszélsz megint!
Ebben a szálban a https://hup.hu/comment/3115970#comment-3115970 -től az SSLv2 vs SSLv3 eszmefuttatásod van. Ki beszélt ebben a szálban TLS 1.1 és TLS 1.3-ról, ember..... 🤦♂️ 🤦♂️ 🤦♂️
Erőltetett elavulásról beszélek, amire a TLS 1.1 és a TLS 1.3 valóban jobb példa, mint az SSLv2 és az SSLv3, de azt már nem vagy hajlandó észrevenni, nehogy meg kelljen értened a lényeget.
Tehát a https://hup.hu/comment/3115970#comment-3115970 kommentedben óriási blődséget írtál. Köszönöm. 1-0 ide ebben a szubszálban.
Mennyire ismered a TLS 1.1 és 1.3 közötti nagy és apró különbségeket? Csak hogy helyre tegyük, hogy mi mennyire elavult.
Nem írtam blődséget, csak relevánsabb a TLS 1.1 és a TLS 1.3 közötti különbség, ha 2024-ben beszélünk a túltitkosításnak köszönhető gépkidobatásról.
Tudtad, hogy a TLS 1.3 gyorsabb, kevesebb erőforrást használ, mint az 1.1 például a kevesebb handsake miatt (kisebb RTT)?
Tudtad, hogy a TLS 1.3 kevesebb cipher suite-t támogat, így javítja a biztonságot, hatékonyságot, csökkenti a félrekonfigurálhatóságot?
Tudtad, hogy a TLS 1.3-ban a PFS (perfect forward secrecy) alapértelmezetten bekapcsolt állapotban van?
Igaz, hogy nem 1.1, hanem 1.2 vs 1.3. Pici olvasnivaló: https://www.ssldragon.com/blog/tls-1-2-vs-1-3/
Minden alkalmazás annyival többet zabál, amennyivel erősebb hardveren írták a kényelmes babzsákfejlesztők.
Erősebb hardver vs EOL / EOS
https://a.te.ervelesi.hibad.hu/hamis-okozat
EOL/EOS = jól működő rendszerek tervezett/szándékos elavultatása, újravásárlási kényszer
Jól működő. Definiáld ezt kérlek!
Ha X rendszerrel megoldok valamit 100 Ft ráfordítással (energia + emberi munkaidő), Y rendszerrel pedig 60 Ft ráfordítással (energia + emberi munkaidő), akkor melyik a jól működő?
Üdítő kivételek vannak, pl. a Wireguard VPN (ha már úgyis témánál vagyunk). Nagyon hatékony kód, kisebb CPU terhelés (még ASIC / AES-NI HW gyorsítás nélkül is), IPSec/OpenVPN-nél nagyobb hálózati teljesítmény. Az ilyenek nem marketingszövegek, hanem mérhető eredmények:
Nem a kód vagy a fejlesztő/eszközök modernsége határozza meg szerintem egy rendszer minőségét. Régi cuccokkal is lehetett fos kódot írni, és új ötletekkel/eszközökkel is lehet kiemelkedően jót, ahogy a mellékelt ábra mutatja.
TLS1.1 vs. TLS1.3... A matematika és a számítási kapacitások fejlődnek, igen... És ami a TLS1.1 bevezetésekor "jó ötletnek tűnt", avagy kellően biztonságosnak, mert az akkori eszközökkel a védett adatok élettartama alatt nem volt törhető, azóta fejlődött a matek (hiba az algoritmusban, egyszerűbben visszafejthető valami, stb.) és a törésre alkalmas hardverek is. Igen,. TLS1.1-ben is van olyan algoritmus-halmaz, amivel elfogadható szintű (x időtávon belül vélelmezhetően nem törhető fel) védelem alakítható ki, de ugyanekkora(!) ráfordítással TLS1.3-mal n*x időtartamra védetté tehető az adat, az információ, mert ott minimum többszöröse, de inkább nagyságrendjében más időtávban kell gondolkodni a törések kapcsán. Miközben ugyanakkora (egyébként nem releváns mértékű) erőforrást használ mindkét verzió...
Captain Obvious strikes again.
Inkább azon gondolkodj, hogy kedvenc multikáid miért nem hajlandók régebbi, kifogástalanul működő eszközökhöz TLS 1.3 frissítéseket kiadni és ezért újra kell őket vásárolni. Legyen szó akár egy Samsung Galaxy A5 vagy S5 okostelefonról.
Mondd Hajbi, te reklamáltál már emiatt ezeknél a multiknál? Mit mondtak / írtak neked?
Ugyanazt az innovációról™, fejlődésről™, költséghatékonyságról™ szóló marketing bullshitet, amit minden más esetben.
De mi volt ez? Mutass nekem kérlek ilyen leveleket. Ha postani, akkor szkenneld be, töltsd fel valahová és linkeld be. Ha email, akkor teljes fejléccel együtt írd be hozzászólásba.
Különben csak kamuzol, nem írtál te akkor egyik multinak se semmit. Még egy nyavalyás panaszlevelet se.
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...)
Pontosan ezért milliószor jobb az ssh tunnel, mert szeparálja a rétegeket a unix filozófiának megfelelően.
A TLS támogatáshoz mindkét oldalon kell a TLS aktuális verzójának a támogatása, és ha jól értem a protokollt, akkor egy PKI sem árt hozzá.
Ezzel szemben az SSH-nál az utóbbi opcionális, és az ssh tunnel egy másik rétegben valósítja meg a titkosítást, nem szükséges hozzá semmilyen támogatás a szoftverben.
Az SSH-nál is van PKI csak alapértelmezetten generál neked kulcsokat. Tájékoztatásul: az SSH a TLS-ben is használt titkosításokkal dolgozik, a PKI pedig nem a TLS hanem az adott (két kulcsú) titkosításoknak a követleménye. Az SSH is tud teljesen strict módon működni (ezért is kell elfogadnod az ismeretlen szerverek host kulcsait). Nincs olyan sok különbség a kettő között, implementation detail-ekben különbözik a TLS meg az SSH
Ráadásul a TLS külön layerként is viselkedik. Olyan, hogy HTTPS kapcsolat, technikailag nincs is, olyan van, hogy TLS kapcsolat, és efelett kiépül egy sima HTTP kapcsolat, és az abban átmenő forgalmat az alatta levő TLS kapcsolat titkosítja.
Blog | @hron84
via @snq-
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!
MACSec két hálózati eszköz közt van. Pont-pont közti, de azon a pont-pont összeköttetésen sok minden mehet. Tehát mondjuk van két adatközpontod, távol egymástól, 3rd party bérelt vonalon át. Nem szeretnéd, hogy a provider olvassa az adataidat, ezért ezt a forgalmat titkosítod az általad menedzselt két router közt. Az, hogy ezen hány gép megy keresztül, teljesen indifferens.
MPLS-nél nem az a mondás h. a provider csak a TAG-et látja, annál mélyebben nem?
(Fogalmam sincs amúgy hogy működik, ehhez kéne egy CCIE routing&switching plecsni, tanulni meg sehol nem tanultam ezt, autodidaktán pedig kicsit magas már ez nekem. Hasonlóan a VRF-hez amit szintén nerworkösöktől hallottam mindig mellékesen érintve az én területemet, de mivel otthon sosem raktam össze ilyet, érteni sem értem annyira h. bele tudjak kapcsolódni ezzel kapcsolatos side-chat-be)
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.
De ott a szabályozás is rossz, ahol elvesszük az internetet a fejlesztőtől. Le kell tiltani keyword, stb alapján ezeket az oldalakat proxyn és kész.
Amúgy a pornó oldalaknak pont semmi közük nincs a hálózati securityhez, max a munkahatékonysághoz. Az onnan származó támadási vektorokkal szemben lehet védekezni, ez lehet egy mondás, de ne akarjuk már elhitetni magunkkal, hogy ez így a biztonság miatt van. Ugyanazok a scriptek/vírusok jöhetnek egy banki(nak tűnő) oldalról is, amit hiába tolsz IDS/IPS log formájában a fejlesztő orra alá.
Blog | @hron84
via @snq-
Ez sajnos így nem teljesen igaz. Amikor a kedves IT fejlesztő kollégától napi rendszerességgel jöttek a figyelmeztetések / riasztások (IDS/IPS, víruskergető), meg elkezdett panaszkodni, hogy lassú a 2,5 millió Ft-os workstation (2013-ban!) gépe (felugró ablakok, adware-ek, spyware-ek miatt), akkor már nem csak munkahatékonyságról van szó.
A kolléga szerencséje az volt, hogy nem ADSL-en lógott a cég, hanem bérelt üvegszálon (1 GB/s).
Belso halozatban lehet komolyabb veszelyforras a plain text ? > ki kell tenni sajat VLAN-ba, forward drop. oda meg csak VPN lathat be, az folott meg mehet a crypt.
job's done.
ilyen es ehhez hasonlo szolgaltatasnak semmi helye a "belso" "dolgozoi" haloban.
amelyik csomag meg nem megy at a firewall-on (layer2), az mindig is extra problemaforras lesz ilyen tekintetben. barmi amit vedeni kell, azt route-olva illik elerni. szenzitiv adat eseten titkositott csatornan (vpn). "az a biztos".
Még az itthoni hálózaton is mindenen van TLS.
Van egy home.example.com wildcard a pi-Hole-ban, ami egy belső Traefik loadbalancer IP-re mutat. Az example.com domain Route53-ban van. Traefik DNS-01 challenge-el kéri a certeket és aggatja külön a service-ekre. maga a h ome.example.com publikusan nem elérhető és DNS bejegyzése sincs. Traefik meg labelek alapján intéz mindent, ha új Docker stacket húzok fel, már figyel is a valami.home.example.com címen valid certtel.
A tanusítvány Let's Encrypt?
Blog | @hron84
via @snq-
Igen, de bármi lehet ami ACME