LAN-ban (céges, nem otthoni) ki mennyire figyel a TLS/SSL-re?

Linux-haladó

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 ?

( Kayapo | 2024. 09. 17., k – 20:29 )

"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

----
올드보이

( Proci85 v | 2024. 09. 17., k – 20:45 )

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.

?

 

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.

Van érvelési hibád, mert két szélsőség között akarsz kényszerűen választani.

a gond, hogy szerinted az adat - ilyenten - ertektelen.

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.

titkositatlan, ergo 0 darab kulcsparral dolgozol. nyitott ajtokat tetszik dongetni. :)

titkosítatlan != nem biztonságos

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.

De a processzornak igen = bloat.

ebbol is latszik mennyire nem vagy kepben.

Hozod a szokásos szélsőségesen idealista, fősodratú, csőlátású formádat, ebben is.

na mi van? nem erted miert fontos a titkositas?
hint: ugyanaze' amie' belepteto rendszerteket meg kulcsrazart ajtokat hasznalunk. meg amie' nem rakjuk ki a jelszavinkat a postitcetlire a monitorra. aze'. :D
(megpl aze', hogy biztos lehess benne, hogy e2e kozt senki nem mokolt bele az infoba, aze', meg aze', h ne lehessen egy koszos kezi radioval lehallgatni a mobilbeszelgeteseket, mint a 90-es evekben. aze'. meg ne lehessen 2G-n sms fraudolgatni. aze'. a lista tetszolegesen folytathato. hazi feladat. :D)

Sokáig tartott az az elengedés, dorsyka. :P

nem erted miert fontos a titkositas?

Te nem érted, hogy miért bloat bizonyos esetekben.

hint: ugyanaze' amie' belepteto rendszerteket meg kulcsrazart ajtokat hasznalunk. meg amie' nem rakjuk ki a jelszavinkat a postitcetlire a monitorra. aze'. :D

Két teljesen külön dolog. A titkosítás meg egy harmadik.

h ne lehessen egy koszos kezi radioval lehallgatni a mobilbeszelgeteseket, mint a 90-es evekben

Csak világvevővel vagy speciális, 450 MHz-et is fogó más rádiókkal lehetett lehallgatni és csak a környezetedben lévőket. Mezei koszos rádiókkal nem lehetett, csak direkt túlzol.

meg ne lehessen 2G-n sms fraudolgatni. aze'

Mindegyik G-n lehet fraudolgatni, de van egy olyan szempont, ami jelentősen csökkenti a lehetőségeket: oda kell menni a célszemély közelébe. A másik népszerű támadás a SIM swapping, amit sokan szeretnek a 2G számlájára írni, pedig ahhoz az ég világon semmi köze. Ez egy emberi tényező általi támadás.

a 99-ben gyartott cnc gep ne logjon a networkon, arra ott az rs232 meg a 3.5-es flopidiszk.
ugyanakkor a G kodos progit nem feltetlen kene titkositatlanul tartolni. 1999-es gyartasu cnc gep ide vagy oda...
felteve, hogy ezek a cegnek ernek is valamit.

Eleve minek 2 zár? Egy is elég. ;-) Illetve ugye a másik kérdés, hogy milyen minőségűek a zárak?

De tegyük fel egy pillanatra, hogy nem lenne kötelező a biztonsági övet becsatolni a kocsi első ülésén.

Ha van légzsák az autóban, akkor a korábbiak szerint nem kötnéd be a biztonsági övet - hogy ezzel ne lassítsd a mindennapi rutint - mert a légzsák majd megvéd?

Az már egy ideje érdekel, hogy mit értesz túltitkosítás alatt. Le tudod írni egzakt módon vagy akár százalékosan? Illetve melyik rész zavar? Proceszor, memória, hálózati átvitel?

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.

Mindig lehet olyan példát kitalálni, ahol nem ad jelentős pluszt a titkosított kapcsolat. Az, hogy ez mennyire valós, életszerű, az már más kérdés.

De itt nem is az a lényeg, hogy van-e kockázat ilyen esetben, hanem az, hogy aki úgy gondolja, hogy inkább titkosít minden forgalmat, mert lehet, hogy nem gondolt (nem ismeri) az összes sebezhetőségre, az ne legyen már kikiáltva hülyének.

Adott esetben audit elvárás volt, hogy az r-parancsok kerüljenek letiltásra, tehát a "követelmény" az adott volt - viszont a kockázatelemzés is adott volt, hogy azon a kapcsolaton sem a vizsgálat idején, sem később (a két gépet más okból egy gépteremben, egy rackben kellett üzemeltetni) nem jelent kockázatot a titkosítatlan adatforgalom, pláne, hogy by design így működött a rendszer, illetve minden titkosítás (akkor még) full szoftveresen volt megvalósítva, és igen sok adatot kellett átlapátolni azon az egy szál dróton, ami akkor (hajbi kedvéért: évtizedekkel ezelőtt) CPU-ban is látható terhelést jelentett volna.

 

kockázata ugyanis ott és abban a fizikai kialakításban NULLA

Igen, ezzel egyetértek. De ha már átköltözik egyik szerver másik rackbe / adatközpontba, akkor egyből borul a biztonság. Márpedig egy költöztetéskor nem biztos, hogy fognak az ilyen titkosítatlan kapcsolatokra gondolni és áttervezni őket.

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.

ehh, megint egy csodalatos okossagot hallotunk mindenheziserto kollega szajabol :D

legalabb olvasnal utana egy kicsit mielott ekkora faszsagokat mondasz. Mondjuk neked nem szokasod :D

Nalam otthoni kornyezetben is megy az mTLS minden szerviz kozott, a let's encrypt meg ingyen adja. A jelszavak/secretek egy vault-ban vannak, se a kodokban, sem file-okban sehol sem talalhatoak meg.

Mindenhol (otthon/iroda) "Least privilege" van mindenkinek IAM-mal ha tobb kell akkor short live token-t kell kernie (otthoni szervizek is igy kommunikalnak), Openpolicy, SSO mindenhol.

Persze van amiert fizetek, mert felhos szolgaltatast vettem igenybe/integraltam, de a sajat szamlam 7$ korul alakul havonta. A ceget meg nem tudom, nem erdekel, megoldjak hogy biztosnag legyen.

Te tobbet koltesz a szinonimaszotaraidra mint en a biztonsagos infrastrukturmra aramszamlammal egyutt kiscsaj :D 

( x-daemon | 2024. 09. 17., k – 22:13 )

csak TLS1.3

es otthon is :)

neked aztan fura humorod van...

( hajbazer v | 2024. 09. 17., k – 22:42 )

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.

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 (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 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ő.

A biztonság növelésével csak a kényelem csökken.

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.

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

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/

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.

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

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.

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

A számítógépek ugyan ilyen eszközök. Amikor elavul és/vagy a feladat megköveteli, akkor le kell cserélni.

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.

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.

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.

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.

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.

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.

https://a.te.ervelesi.hibad.hu/allito-kerdes

Se nem biztonságosabb, se nem kevésbé biztonságos.

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.

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:

  • Nem azért hagyom a francba, mert nincs több érvem és/vagy nem tudom cáfolni amit írsz, hanem azért, mert felesleges időtöltés, és már nem is szórakoztató
  • Attól, hogy nem folytatom a vitát veled, mert értelmetlen, még nem lett igazad. Sem előttem, meg valószínű más előtt sem.

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).

🤦‍♂️ 🤦‍♂️ 🤦‍♂️

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

🤣 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 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?

Amekkora a library-jé, ami véletlenül elfelejti használni.

Pentium 3-on pedig nagyon szépen látszik az az overhead.

Ohh, látszik, hogy nem ismersz. Elég skót vagyok én ahhoz, hogy ne pazaroljak. Több ismerősöm is tőlem tanulta a skótoskodást. Nem viccelek.

IT-ra fordítva: Pusztán hajlandó vagyok picit számolni. Ha valami megoldható 100 Ft-ból 200 helyett, akkor azt a megoldást fogom használni. Nem fogom elutasítani az értelmes fejlődést. Ilyen például az energiahatékonyság javulása.
2024-ben Pentium 3-mal dobálózni egy szakmai IT fórumban, mint PÉLDA, az nettó faszság. Nem szépítem a kicsi lelkednek. A P3 egy 20-25 éves technológia. Ha valami 5-10 éves cuccot mondtál volna, akkor azt még elfogadtam volna. Csak megint átesel a ló túloldalára.

A gépemben i7-7820HQ CPU van. Elégedett vagyok a gépemmel, nem dobom ki (Dell Precision). Nem fogom upgradelni Win11-re, inkább megyek FreeBSD-re vagy Linuxra, ahogy korábban is írtam. Ez még a józan határon belül van véleményem szerint.

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.

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

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.

Raynes évek óta azt kérdezi tőlem, miért nem Linuxot használok, terminálban.

A válasz ugyanaz: Mert számomra a Windows XP a HP-Compaq 6715b-men AMD Turion 64-gyel adja meg azt a rendszert, funkcionalitást és felhasználói élmény, amire szükségem van. Sem a DOS, sem a terminálos Linux nem adja ezt meg.

jóval kisebb CPU overhead elfogadhatatlan számodra a kommunikáció biztosítására

Alapvetően az a bloat, ami felesleges overhead. A bloat önmagában hordozza a feleslegesség definícióját. Ahol szükséges a titkosítás, ott definíció szerint nem bloat titkosítani, mivel szükséges. Én a szükségességet vitattam, pl. LAN-on. Mondom, olvasd el a web túltitkosításáról nyitott topikomat. Túltárgyalt téma. Abból talán megérted a mondandóm lényegét.

Nem kötekedésképp: Van olyan "betegség", amikor valaki valamilyen tárgyhoz túlságosan vonzódik. Bemerevedsz. Lehet a korodból fakad (50+), lehet, hogy elválási problémáid vannak, lehet, hogy a fiatalságod után vágyakozol. Talán szorongsz is. Nem tudom. Nem is akarom tudni. Azért a helyedben beszélgetnék egy pszichomókussal. (no offense)

Hogy picit IT szakmai is leszek: Mit csinálsz majd, ha tönkremegy a HP-Compaq 6715b? Van már terved rá? Mi lesz az utódja, ha tönkremegy a gép pl: alaplap hibás lesz?

Nincs ilyen problémám. Azokhoz a használati eszközökhöz (tehát nem konkrét tárgyakhoz) ragaszkodom, amiknél eddig még nem találtam számomra jobbat.

Ha holnaptól egy másik 6715b-t kéne használnom, vagy egy nem 6715b-t, de ugyanilyen jól használható gépet, teljesen oké lennék vele.

Egyszerűen nem cserélek le valamit azért, mert "le szokás cserélni". Tudom, ez furcsa egy fogyasztói társadalomban, de ez a fogyasztói társadalom fenntarthatatlan.

Mit csinálsz majd, ha tönkremegy a HP-Compaq 6715b? Van már terved rá? Mi lesz az utódja, ha tönkremegy a gép pl: alaplap hibás lesz?

Bármikor vehetek bele másik alaplapot a használt piacon. Szerintem arra vagy inkább kíváncsi, hogy mi lesz, amikor eljön Raynes jövendölése és elhagyom a Windows XP-t, meg ezt a hardvert is. Nos, erre egyelőre konkrét tervem nincsen, de ötleteim vannak.

Ugye ha az alaplap típushibás lesz - pl: forrasztási hibák jönnek ki, netalán XY chip tönkremegy, mert rosszul tervezték meg a gép hűtését, akkor nem biztos, hogy egy másik alaplap megoldás lesz, mert azon is ki fog jönni a típushiba nagy valószínűséggel. A sorozatgyártás már csak ilyen.
Találkoztam már olyan laptoppal, ahol csak a SATA vezérlő ment tönkre, semmi más. Kiváltani csak USB-s külső SATA házzal lehetett, de ez a usernek annyira nem tetszett - habár gyakorlatilag sose hordozta a gépet. Ezért a gépet fél évnyi nyünnyögés után szanálni kellett és újat venni. Viszont a user új gépe sokkal gyorsabb volt, alkalmas volt a gyors munkavégzésre is (munkára és szórakozásra is használta). Tehát a user élmény javult.

Nos, erre egyelőre konkrét tervem nincsen, de ötleteim vannak.

És mik az ötleteid, ha nem szupertitkos? Kíváncsi vagyok, hogy miben gondolkozol.

A válasz ugyanaz: Mert számomra a Windows XP a HP-Compaq 6715b-men AMD Turion 64-gyel adja meg azt a rendszert, funkcionalitást és felhasználói élmény, amire szükségem van.

Tehát, ha Te egy ilyen kövület gépen futó kövület op. rendszerhez ragaszkodsz, mert azt tudja, _amire szükséged van_, az okés. Hiába mindja mindenki, hogy elavult, nem biztonságos, stb. Ez Téged nem érdekel.
Sőt, lebeszélni sem akarnak róla, csak annyit szeretnénk sokan, hogy lásd be (magadnak, nem nekünk), hogy saját felhasználásodon kívül vállalhatatlan kockázatokat jelent ez a maradiság, amivel rajtad kívül senki nem akar kínlódni, és nem tesz jót az IT világnak, ha ezt a maradi gondolkodást nyomod annak, aki még esetleg tájékozatlan, nem ismeri a kockázatait eléggé. De ezt sem igazi elvárás, mert itt legtöbbünket valójában nem érdekel, hogy mivel keseríted az életed, aki pedig még kezdő, az a többi, nagy mennyiségű ellenvélemény hozzászólásból leveszi, hogy nem az a követendő irány.

Viszont ha egy fórumtárs (vagy akár az összes többi Rajtad kívül) a _számára megnyugtató szintű_ biztonság miatt minden kommunikáció TLS titkosítását választja, az viszont bloat túltitkosítás, ami profitmultis újravásároltatást okoz, akkor hülye mindenki.

De tovább megyek, ahogyen Te is: a számodra megfelelő, mindenki más szára viszont nem megfelelő gépre is azt mondod, csak a Te utadst szabadna követni, mert minden ezen felüli pénzköltés, minden újabb dolog csak bloat, profitmultis újravásároltatás.

Alapvetően az a bloat, ami felesleges overhead.

Óriási különbség van a _felesleges bloat_ és a _szerinted felesleges bloat_ között. De folyamatosan úgy kommentelsz, hogy Te ismered az Egyetlen Igazságot, és ha Te azt mondod valamire, hogy az bloat, akkor az axióma szinten, megkérdőjelezhetetlenül bloat, és mindneki hülye, aki szerint nem az. Ha mindenki más szerint nem az, akkor mindenki hülye.

Nem érzed úgy, hogy durván kettős a mércéd? Költői kérdés, mert nyilván nem érzed úgy, mert akkor nem harcolnál ennyire a világ ellen, folyamatosan.

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.

Milyen az a "jól switchelt LAN"?

Leírtam: Hogy a kliensek csak a saját csomagjaikat kapják meg.

És mit szólsz a Wifihez, ahol minden kliens megkap minden keretet a közeg adottságai miatt?

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.

Nincs olyan fogalom, hogy túltitkosítás.

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.

Leírtam: Hogy a kliensek csak a saját csomagjaikat kapják meg.

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.

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.

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.

De igen, van ilyen fogalom.

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?

Multicast / broadcast mond valamit?

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 csomagokat kereteket. Én azonban azokról a keretekről beszéltem, amik alapvetően két kliens között közlekednek.

switch port mirroring.

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.

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.

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.

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?

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.

Rögzítheted Asteriskből is, vagy bárhonnan, ahol hozzáférsz a forgalomhoz.

🤣 🤣 🤣 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.

Ú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.

É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ó.

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.

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. 😉

Tudod, az IP telefonok egyik jellemzője, hogy a teljes forgalom nem feltétlen megy át a központon.

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.

a switch port mirroring egy támadási faktor, ami ellen védekezni kell

De nem feltétlenül alkalmazási rétegben.

Igen, ennek a támadási vektornak is vannak előfeltételei.

Amik jelen esetben nem adottak.

Én értem, amit írsz.

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.

Másrészt 2024-t írunk, nem 2004-t.

Mindkettő csak egy évszám. Divatból, trendből, évszámbuziskodásból nem titkosítunk, mert az túltitkosítás (bloat).

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).

Helyesen: nagyvállalati környezetben.

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.

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.

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!

Így igaz. Vagyis, nem tartozik a témához. Tehát offolsz.

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.

Szintén nem tartozik a témához. Megint offolsz.

Hajbi, néha egyetértek veled. Csak gyakran túltolod a butaságot.

Á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.

Na meg kérlek, IT securityval ne foglalkozz.

IT vezetőként foglalkoznom kell vele. :)

Láthatóan nem értesz hozzá.

Láthatóan a másik leminősítésével, szavak kiforgatásával, offolással szeretnél vitát nyerni.

Még. Tanulj, fejlődj, képezd magad. 😉

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. 😇

Szavak kiforgatását csinálod épp, nagyjából Zeller Mérnök Úr módra.

Nyilván kiforgatom a szavaid, ha butaságot írsz vagy értetlenkedsz. Ne érezd magad kitüntetve.

Amik jelen esetben nem adottak.

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.

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.

Erőltetem vagy csak a valóságban élek 2024-ben? Szerintem az utóbbi.

Mindkettő csak egy évszám.

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.

Helyesen: nagyvállalati környezetben.

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.

Tehát a MACSec túltitkosítás.

🤦‍♂️ 🤦‍♂️ 🤦‍♂️

Mindenféle overhead-eket rátesz a titkosítás.

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.

IT vezetőként foglalkoznom kell vele. :)

Hát izé.... Csak a többi CxO, tulajdonosok meg ne tudják, hogy mennyire korszerűen gondolkodsz. 🧏‍♂️

Láthatóan a másik leminősítésével, szavak kiforgatásával, offolással szeretnél vitát nyerni.

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.

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

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).

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.

Gipsz Jakab felhasználónak nem dolga a titkosítással bajlódni.

Erőltetem vagy csak a valóságban élek 2024-ben? Szerintem az utóbbi.

Erőlteted.

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.

Kevesebbe, mivel kevesebb eszköz volt világszinten, beleértve a nem PC kütyüket is.

Már mikro / KKV környezetben is hagymaszerűen érdemes felépíteni az IT védelmet.

Ebben nincs vita, ugyanakkor túltitkosítani nem érdemes.

Minden pusztán kockázat értékelés- és elemzés kérdése.

Így igaz.

🤦‍♂️ 🤦‍♂️ 🤦‍♂️

A MACSec túltitkosítás. Ízlelgesd.

Számszerűsítenéd kérlek, hogy mennyi overheadje van az SSL / TLS-nek?

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 mekkora költséget jelent egy cégnek?

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.

Csak a többi CxO, tulajdonosok meg ne tudják, hogy mennyire korszerűen gondolkodsz. 🧏‍♂️

Ne aggódj, mindent tudnak. :)

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.

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)

Az utóbbi egy minősíthetetlen ipari hulladék lett véleményem szerint.

Végre valamiben egyetértünk ebben a threadben.

Az előbbi még nem akkora hulladék, bár vannak próbálkozások, hogy azzá tegyék.

A Wayland-idealizmus erőltetése végett nyugodtan tekinthetjük ugyanakkora hulladéknak. Ha most nem, jövőre már mindenképp.

Gipsz Jakab felhasználónak nem dolga a titkosítással bajlódni.

Nem igaz. Olvasd el a céged IT szabályzatait. Az IT biztonság mindenki közös feladata is egyben.

Erőlteted.

Fordulj neurológushoz vagy irány a sebészet. Ott biztos tudnak neked segíteni. 😅

A MACSec túltitkosítás. Ízlelgesd.

Szerinted. Te vagy erős kisebbségben.

Ezt te is tudod, hogy erősen rendszerfüggő, így semmi értelme számszerűsíteni

Köszönöm. Megint igazam volt / van.

Ne aggódj, mindent tudnak. :)

Ebben nem vagyok annyira biztos.... Ha tudnák, akkor már rég kirúgtak volna. (no offense)

Igen, természetesen Kína és Oroszország miatt kell itt is aggódni. Véletlenül sem a cloud-multi miatt....

Teljesen mindegy, hogy az illetéktelen fél egy ország, titkosszolgálat, műveleti egység, versenytárs vagy épp egy cloud provider. Akinek nincs köze az adatokhoz, az elől védeni kell titkosítással. Pont.

Nem igaz. Olvasd el a céged IT szabályzatait.

Nagy részét én írtam. :)

Az IT biztonság mindenki közös feladata is egyben.

Igen, általánosságban, de nem specifikusan. Gipsz Jakabnak továbbra sem kell azzal bajlódni, hogy alkalmazásrétegben túltitkosítson.

Fordulj neurológushoz vagy irány a sebészet. Ott biztos tudnak neked segíteni. 😅

A jó öreg pszichiáterkártya. Elkopott már nagyon.

Szerinted. Te vagy erős kisebbségben.

https://a.te.ervelesi.hibad.hu/kozvelekedesre-hivatkozas

Köszönöm. Megint igazam volt / van.

Nincs, de az egód nagyon szeretné.

Ebben nem vagyok annyira biztos.... Ha tudnák, akkor már rég kirúgtak volna.

Én meg biztos vagyok benne.

(no offense)

Kaptam már cifrábbat is, no problem.

Akinek nincs köze az adatokhoz, az elől védeni kell titkosítással. Pont.

De ugye főként a kínaiaktól. 🤡

"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.

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.

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!

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( zrubi v | 2024. 09. 18., sze – 11:41 )

Szerkesztve: 2024. 09. 18., sze – 11:42

Belso halozatban lehet komolyabb veszelyforras a plain text ?

Í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és az volt , ki, mennyire veszi ezt komolyan. Nem az, hogy én hogyan viszonyulok hozza, azt nem kérdeznem, mert azt tudom :)

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( chx | 2024. 09. 18., sze – 12:44 )

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

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

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.

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.

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..... 🤦‍♂️ 🤦‍♂️ 🤦‍♂️

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/

Ü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:

On 10+ yr old cpu I was reaching gigabit speeds with site to site.

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.

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.

Nem erről beszéltem, hanem arról, hogy a matematika tudománya, illetve a számítási kapacitások, erőforrások fejlődése teszi de facto elavulttá, nem biztonságossá a korábban megfelelőnek tekintett módszereket.
Az, hogy x eszköznek milyen lehetőségei vannak naprakész biztonsági szintet elérni, az irreleváns - a tudomány és a technológia gyorsabban fejlődik, és azt vagy követed, vagy elfogadod(!) hogy az eszközöd csak korlátozottan tudja védeni az adatforgalmadat.

Ja, senki sem mondta, hogy a TLS1.3 _kell_, ugyanis a TLS1.2 _jelenleg_ elégséges biztonságot nyújt a civil életben előforduló esetekben (hint: adott protokoll/eljárás adatfolyamának feltöréséhez/visszafejtéséhez várhatóan szükséges időtartam és a védett adat értékes élettartamának az egymáshoz való viszonya); de vannak olyan adatok, amikhez ennél magasabb szintű védelemre van szükség.
 

Én meg azt mondtam, hogy a titkosítási protokollokat is felhasználják a multik a mesterséges elavultatásra úgy, hogy triviálisan frissíthető legacy rendszereket szándékosan nem frissítenek. Tehát, ki kell dobnod pl. egy appliance-t, mert nem jön rá új firmware, amiben benn van a TLS 1.3, meg a nem lejárt root certek. Miközben az eszköz önmagában nincs elmaradva a kriptográfia fejlődéséhez képest, és simán tudná az új titkosítási algoritmusokat is. Nagyjából ez a helyzet a 8 évnél régebbi Android telefonokkal is.

Ki fizetné ki a frissítést?

Az eredeti támogatás tart valameddig, erre az időre benne van az árban a frissítés és az alkatrész ellátás. Eltelik sok év, kiderül egy titkosítási módról, hogy az aktuális technológia mellett már nem biztonságos. Ki fogja kifizetni a régi eszközök szoftverének a frissítését, amik már kifutottak a gyártói támogatási időszakukból? Az oké, hogy meg lehetne csinálni, sohasem ez volt a kérdés. Hanem az, hogy ki állja a számlát? Aztán ha megcsinálják a frissírést, és elromlik benne az alaplap, ami már nem kapható, mert már nincs gyártói támogatás alatt az eszköz, akkor mi lesz? Vagy szerinted örökre tartani kellene minden gyártónak minden alkatrészt, amit valaha forgalmazott?

Ha ingyen frissítenének mindent örökké, akkor csődbe mennének a gyártók. Ha meg pénzt kérnének a támogatásból kifutott eszközök szoftver frissítéséért, akkor jössz a pénzéhes profitmulti dumáddal.

Ráadásul egyáltalán nem érted azt a koncepciót, hogy minden eszköznek van egy tervezett élettartama, ami alatt a gyártó támogatást nyújt hozzá. A vevő ez idő alatt lehet benne biztos, hogy ha a hardver elromlik, lesz cseredarab, ha a szoftver hibás, kijavítják. Emiatt a felhasználók ütemezetten cserélik az eszközöket, így mindig van hardver-szoftver támogatásuk, biztosított a folyamatos üzletmenet, nem kell hirtelen, váratlanul megoldani valami kiesést.

A Te kitalált világodban hogyan működne a fejlődés, ha a gyártó egyszer legyártana valamit, majd aztán örökkön örökké frissítené (mert bizonyos felhasználói kör igényeit örökre kielégíti a tudása), és e mellé hardver utánpótlást is biztosít? Miből élne a gyártó, miből finanszírozná a támogatást? Könnyen belátható, hogy ez az üzleti modell nem működik, mert nincs bevétel ami finanszírozza a fejlesztést, de még a működést sem. Amikor meg egy hardver előfizetéshez kötött lesz (hogy a gyártó biztosítsa a folyamatos életben tartását, meg a saját működését is), akkor egységes a felháborodás, hogy dehát kifizettem egyszer, miért adnék érte még havi díjat is, nekem a vásárlástól számítva jár a frissítés, javítás további pénz fizetése nélkül.

Én megértem az összes gyártót, akár hardver, akár szoftver, hogy legyen előfizetéses minden. Így a gazdaság is működőképes marad, és az egyes rendszerek is hosszabban életben tarthatók, mindenkinek gazdaságosan. Persze az árazást nem könnyű megállapítani, de a fenntarthatóság adott lesz.

Te meg jössz ezzel a megvettem valamit, és soha többet nem veszek másikat, mert ez nekem jó. Ráadásul fizetni sem akarsz semmiért, mert téged ne húzzanak le a profitmultik, de nem lemondasz a fizetős dolgokról, hanem ellopod inkább trükkökkel a netről ami kell, és alátámasztod az igazad, általad direkt félremagyarázott törvényekkel. Mindezt a fenntarthatóság és a kevesebb szemét zászlaja alatt teszed, miközben ez csak a maradiság és a smucigság kombinációja már ezen a szinten művelve.
Akkor miből fog mindenki élni dolgozóként, ha fogyasztóként így gondolkodik mint te? És nem vagyok a mostani felpörgetett fogyasztói társadalom mellet (sőt), de azért be kell látni, hogy a világ működéséhez elengedhetetlen a fogyasztás.

mondtam, osztriganak csillagaszatrol beszelsz. Eleteben nem latott meg normalisan mukodo ceget legyen az egy sima cukraszda vagy IT ceg, fingja sincs a technologiakrol csak bofog rajuk valami ektelen hulyeseget teljes meggyozodessel, hogy mindneki mas hulye. 

Teged elkapott :D (feleslegesen irod le a betuket meg ertelmes osszeszedett gondolatokat, egyreszt nem is erti meg, masreszt csak onmagara akarja ugyis kiverni, ne add meg neki ezt :D)

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

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.

( kubi | 2024. 09. 18., sze – 16:06 )

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.

( micsa v | 2024. 09. 18., sze – 16:07 )

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...

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.

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)

Nem hiszem. Annak idején vagy huszonsok évvel ezelőtt próbáltak nekünk eladni egy MPLS hálózatot (talán ATM-ekhez, már nem emlékszem). Amikor rákérdeztünk konkrétan, hogy mennyire biztosítja ez az átvitelben a titkosságot, akkor elkezdődött a hadoválás, hogy más úgyse fér hozzá (legalábbis a provideren kívül), aztán később jött a tényleges válasz, hogy titkosítást nem biztosít, de jó pénzért megoldják. (nem vettük igénybe).

Annak idején szintén vagy tizensok éve voltam egy MPLS tanfolyamon, ott erre nem tértek ki, de gyakorlatilag az MPLS nem csinál mást, mint rátesz egy plusz tag-et a forgalomra, és az alapján routol, illetve keresi meg az MPLS végpontot. Az adat többi részéhez nem nyúl. Tehát igen, az MPLS csomagok továbbításához magán az MPLS felhőn belül nem kell más adat. Viszont ez nem jelenti azt, hogy ne lehetne olvasni a teljes adatcsomagot.

( Vamp | 2024. 09. 18., sze – 19:45 )

Szerkesztve: 2024. 09. 18., sze – 19:48

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.

( kassaiviktor | 2024. 09. 18., sze – 20:41 )

é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.

( Kayapo | 2024. 09. 19., cs – 21:02 )

Szerkesztve: 2024. 09. 19., cs – 21:02

Én ahogy látom, ezzel kapcsolatban (is) táborokra szakad a szakma:

  1. Belső hálón minek? Magamtól féltsem az adatokat? (Ezt én picit naivnak tartom, de lehet létjogosultsága [nagyon nagyon ritkán])
  2. Csak a Zero Thrust elég biztonságos és még a rendszergazda (root) se tudjon semmit átállítani (ennek általában az a vége, hogy a külsős [indiai] supportnak több joga [szava] van mint a cégen belüli rendszergazdának)
  3. Én tudok egy sokkal jobb megoldást... (Ők azok akiknek csak kalapácsuk van és nekik minden szög)
  4. Tegyünk meg minden észszerű óvintézkedést, legyünk költség hatékonyak, de ugyan akkor kritikusak, még a saját megoldásainkkal kapcsolatban is (Én remélem ez a tábor a legnagyobb)

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:

  • IDS / IPS / SIEM
  • Staging / CICD
  • OS / SQL / AKARMI hardening
  • 2FA / MFA
  • Vírus kergető

----
올드보이

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Amúgy a pornó oldalaknak pont semmi közük nincs a hálózati securityhez

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).

( dorsy v | 2024. 09. 20., p – 12:17 )

Szerkesztve: 2024. 09. 20., p – 12:33

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".

( igor | 2024. 09. 20., p – 13:54 )

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.

( Sixday v | 2024. 09. 23., h – 14:35 )

Engem megnyugvással tölt el hogy manapság egy interjún ha közlöd hogy az end-to-end TLS egy babzsákfejlesztők által kitalált overhype meg "túltitkosítás" akkor úgy köszönnek el másodpercek alatt ahogy az a nagykönyvben meg van írva.

Az meg hogy létezik valami olyan kispistike bt. egy "szerverteremmel" a spájzukban ahol hajbi ezzel a tudással állítólagos it vezető lehet az legyen az ő bajuk :)

> babzsákfejlesztők által kitalált overhype

Pont a fejlesztés az, akik csak egy működhetőnek esetleg-talán nevezhető bármit adnak át, bármi áron. Patchelés nem kell, DB tablespace méretezés nem kell, verziókövetés nem kell, encrypction nem kell, Java xms&xmx méretezés nem kell, next project van.
Bármiféle security-t, LDAP auth-ot, logolást, auditot, egyebet az infra supportnak/compliance-nek kell kierőszakolnia. 2 KKV, 5 multi, ugyanez a lemez volt.
(TLS párti vagyok, még mielőtt...)

echo crash > /dev/kmem