IT szakemberként dolgozom és a számítógépes biztonsághoz ...

egyátalán nem értek.
5% (19 szavazat)
valamennyire értek, van telepített tűzfalam stb.
23% (95 szavazat)
értek, van tűzfalam, amit magam konfigurálok stb.
42% (175 szavazat)
magas szinten értek, biztonsági szakemberként dolgozom, tűzfalakat készítek stb.
11% (46 szavazat)
magas szinten értek, biztonsági megoldások kijátszásából élek.
1% (6 szavazat)
egyéb, leírom kommentben.
3% (14 szavazat)
Csak az eredmény érdekel.
14% (60 szavazat)
Összes szavazat: 415

Hozzászólások

[ ] magas szinten értek, a NAT az egyik legjobb módja a belső hálózat védelmének

> A gond az, hogy ezt nem csak egy user mondta mar akkor sem ezt a "NAT -> safety" dolgot :(

A baj az, hogy ilyenkor kinevetés, meg facepalm, meg hasonló reakciók mellett nem jut idő (vagy kedv?) beszélgetni arról, hogy ténylegesen mi a baj a fenti állítással, így aki nincs képben, nem is fogja megtudni, csak elmegy a kedve a fórumozástól :)

Be tudok configolni egy tűzfalat de ez qrvára nem fog egy zero-day nginx vagy apache bugon segíteni..

Van telepített tűzfalam (vírusirtó hozza), de nagyon alap szinten értek csak hozzá. Inkább fejlesztői szemszögből értek a biztonsághoz.
Mi a szavazás célja?

Teljesen maskepp kell egy fejlesztonek, egy tesztelonek, es uzemeltetonek, es egy white hat/black hat hackernek (ebben az ertelemben hasznalva) ertenie a "szamitogepes biztonsaghoz". A fejlesztonek nem szabad bugot betenni a kodba, vagy ha mar elkerulhetetlen, akkor minel kevesebbet - es lehetoleg nem sulyosat, plane nem tavolrol is kihasznalhatot (mondjuk az instabilitast okozo bugok sem kellemesek, meg ami adatvesztest okoz, az sem..). Egy tesztelonek ezt eszre kell vennie, vagy hasznalnia/keszitenie kell olyan toolt, ami eszreveszi ezeket (pl. majom, valgrind, coverity). Az uzemelteto az, aki a tuzfallal bohockodik, IDS-t telepit, figyel a frissitesekre, a hacker (megintcsak a koznyelvi ertelemben veve) meg megprobalja megtalalni ami ezutan bennmaradt, es vagy dokumentalja vagy kihasznalja kalapszin fuggvenyeben.

Fejlesztokent - nyelvtol es kornyezettol fuggoen - pl. ha tudja, hogy miert gaz ha tulcimez egy tombon, vagy ha tudja, hogy az XSS elkerulesehez mit kell betartania, az - nehany hasonlo tarsaval egyutt - mar eleg. Nem kell hozza tuzfalat konfigolni vagy ARM asm-ben shellcode-ot irni. Ez nyilvan nyelvfuggo, mert van olyan nyelv, amiben nem fogsz tulcimezni, illetve ha nem webre fejlesztesz, XSS-rol sem beszelhetunk. Ha nem hasznalsz DB-t, SQL injectionnel sem tudnak tamadni, de ha hasznalsz, akkor is eleg, ha betartasz par szabalyt (vagy jol valasztasz hozza libet).

Jo, most kicsit leegyszerusitettem a dolgot, de kb. errol van szo. Ja, es a szerepek nincsenek ennyire elkulonitve: pl. fejleszto is irhat automata teszteseteket, az uzemelteto-fejleszto lehet ugyanaz (devops), es a hacker is ir programokat.

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

Inkább a nagyon sajnálatos Status Quo leírása. "Ezért tart itt ez a világ!" :)

A fő probléma ezzel a hozzáállással, hogy utólag egy rendszerbe nem lehet beletervezni a biztonságot. Ez nem olyan, hogy bemész a boltba, veszel két kiló SECURITY-t, és utána kívülről rákened :)

Tuti megoldást én sem tudok, elvileg már a rendszer tervezésénél kellene ezeket a szempontokat is rögzíteni, és mind a fejlesztés, mind az üzemeltetés során ennek megfelelően eljárni. Azonban a legtöbb esetben a biztonság kimerül abban, hogy "csak érvényes, összetartozó usernév / jelszó párral lehessen belépni", ez azonban kb. annak felel meg, hogy amikor a betörő lenyomja a bejárati ajtó kilincsét, akkor nem nyílik ki neki -- erre ő odébb áll.

Azonban nyilván minden ilyen "extra" - nem konkrét üzleti funkciót fejlesztő tevékenység árnövelő tényező is, és a megrendelőt meg pont nem fogja érdekelni, hogy a te rendszered biztonságosabb, ha 2-3x annyiba kerül.

Fontos, hogy ismerjük el: a jelenlegi helyzet rossz, és vesztésre állunk. A közelmúlt IoT alapú DDOS támadásai nagyon is jól mutatják, hogy egy látszólag jelentéktelen, de lyukas rendszer mekkora problémákat tud okozni. Ne próbáljuk meg megideologizálni, hogy miért nem a mi (fejlesztők) dolgunk a biztonságos rendszerek építése.

Mindenkinek javaslom, hogy nézze meg Jonathan Corbet előadását (The Kernel Report), ami nagyon szépen bemutatja, hogy hogyan nem kéne ezt az egészet csinálni...csak kár, hogy ők ezt sikernek könyvelik el...:(

Szerk: Nem azt mondom, hogy a fent leírt példák, pl. buffer overflow és sql injection elkerülése nem kellenek, azt mondom, hogy ez nem elégséges egy biztonságos rendszerhez.

Vagy inkább a saját szakterületén mélyüljön el a tudása ahelyett hogy mindent csak felületesen ismer. Mindent nem lehet tudni.

Ráadásul mit értesz IT szakember alatt? Volt amikor az IT simán információval kapcsolatos szakterületet jelentett, és a számítástechnikához csak annyi köze volt, hogy az az eszköze volt az információhoz hozzáférésnek.

Hogyne persze, meg meta tagekkel. Még mit nem. Érdekes módon komplett regényeket meg tudtak írni az elmúlt néhány évezredben egyetlen egy darab szmájli és <sarcasm> tagek nélkül. És mintha irodalom órán kifejezetten tanítanák is, hogy észre kell venni azt, hogy valaki irónikus, szarkasztikus, cinikus, stb.

Felejtsük már el ezt a jelezzük szmájlival elmeroggyantságot.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Érdekes módon komplett regényeket meg tudtak írni az elmúlt néhány évezredben egyetlen egy darab szmájli és tagek nélkül.

azert a hup kozonseget es a szepirokat elvalaszto vekony hatart azert ne mossuk el. Btw. ugy tunik, hogy bizonyos underground korokben nagyon mennek a szmajlik, meta tag-ek, na meg a hashtag-ek: https://www.youtube.com/watch?v=57dzaMaouXA

És mintha irodalom órán kifejezetten tanítanák is, hogy észre kell venni azt, hogy valaki irónikus, szarkasztikus, cinikus, stb.

noha a 'php-ben tuzfalat' nyilvanvaloan az, de azert nem feltetlen van elegendo info annak eldontesehez, hogy az illeto az ironia/szarkazmus/nihilizmus/whatever eszkozeivel el, vagy csak egyszeruen pszichopata. Meg azert hrgy84-et sem kellene ilyen megugorhatatlan feladat ele tenni...

Tekintve, hogy PHP-ben éppeszű ember nem kezd el tűzfalat írni, milyen információ hiányzik ahhoz, hogy rájöjj arra, hogy ezt senki nem gondolja komolyan?

"azert a hup kozonseget es a szepirokat elvalaszto vekony hatart azert ne mossuk el. "

Nem tudtam, hogy az értő olvasás (beleértve az irodalmi stílusjegyek felismerését) csak a szépírók számára volt kötelező törzsanyag az általánosban.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Hiszed vagy sem, volt már dolgom PHP-ban írt tűzfal adminisztráló felületekkel, ezért nem gondoltam első két körben azt, hogy itt szarkazmusról van szó, illetve maga a komment sem tartalmazott elég információt annak eldöntésésre, hogy a kollega pontosan hogyan értette a dolgokat.

A másik, hogy azért egy 5-10 szavas kommentet és egy regényt összevetni egymással elég merész vállalkozás, és nem pusztán azért, mert én gyengeelméjű medvebocs vagyok, hanem azért, mert nem azonos műfajban mozognak. Ezt elvben szintén megtanították neked irodalom órán.
--
Blog | @hron84
Üzemeltető macik

#define tuzfal

Amit Linuxon tuzfalnak hivunk, az lenyegeben a NetFilter alrendszer frontendje, maga a "tuzfal" ezt konfiguralja, de az alrendszert lecserelni, elhide-olni nem tudja (max talan ha promiscous modba pakolja az osszes interfeszt, de ilyenkor elvesz egy csomo beepitett lehetoseg, mindent szoftveresen kell vegigemulalni, amit amugy maga a Linux halozati alrendszer tud). Ilyen ertelemben tehat linux alatt "tuzfalat" nem tudsz irni. Hogy magukat a NetFilter szabalyokat pontosan mivel generalod ki magadbol, PHP koddal, Java alkalmazassal, vagy bash-bol az iptables parancsot hivogatva, az egyeni szoc. problema, de itt csak ennyi lehetoseged van a "tuzfal irasra".

"Képzeld, írnak novellákat. Meg verseket is! Vagy szerinted a különféle stílusjegyek nem férnek el 100 oldalnál kevesebb terjedelemben?"

Az ominozus komment egy szimpla mondat volt. Egy vers - oke, a legtobb vers - altalaban tobb, mint egy mondat, legalabb egy bovitett mondat. Meg mindig almat a kaktusszal hasonlitasz ossze, de folytasd ezt az irodalomelmeleti fejtegetest, erdekel a vege.
--
Blog | @hron84
Üzemeltető macik

Értek, egyet is tudok érteni egyes dolgokkal de azt is látom hogy hogyan lehet (rosszul) túllőni.
Nem hiszek a tűzfalakban, nem is használok semmi extrát az oprendszerén (Windows) kívül. Egy lightos IPS-nek több értelme van.

Linuxos szerveren, routereken bekonfigurálom az alapot, de ott sem komplikálom soha túlzottan.

magas szinten értek, biztonsági szakemberként dolgozom, tűzfalakat készítek stb.

Elnézve a piacon fellelhető tűzfalmegoldások biztonságát, az nem sokat árul el egy "IT szakember" hozzáértéséről, ha "tűzfalakat készít".

> a piacon fellelhető tűzfalmegoldások biztonságát

Mennyivel tudja jobban, vagy rosszabbul bezárni egy tűzfal az adott portot, mint egy másik? Persze közben rájöttem, hogy egy tűzfal nem csak ennyit tesz, de vajon hol a határ, mi számít tűzfal funkciónak, és mi nem?

"tűzfalakat készítek, stb."

ójajj...

tuzfal lol :D

--
NetBSD - Simplicity is prerequisite for reliability

Őszintén szólva nem tudom megítélni. A tűzfal a legkevesebb, a jéghegy csúcsa. Szerintem.

Kőműves vagyok, és tűzfalakat készítek.

Fejleszto vagyok (jelenleg tavolrol nem hozzaferheto projecteken dolgozom/dolgoztam). A Hack This Site-on anno eleg sokaig eljutottam, es ismerek egy csomo olyan programozasi hibat, amit ki lehet hasznalni, meg akkor is, ha nem tudnam magam megirni az exploitot. Ezeket megprobalom elkerulni.
Tuzfalat mobilon hasznalok, ott is inkabb a kimeno keresek miatt - bat a tehen miatt kb. ott is felesleges. A gepem NATolo router mogott van (IPv6-ot nem tud).

Ha van egy szolgaltatasom, amit ki akarok engedni, onnantol tuzfalon nem lehet mindent tiltani. Ha a mogotte levo programban kihasznalhato hiba van (vagy a kernelben), a hajadra kenheted a tuzfaladat.

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

en ertek a biztonsaghoz: nincs biztonsag. Elobb-utobb amugy is mindenki meghal...

--
Te!
Annyira gyulolod a BlackPanthert!
En meg ezert gyullolek! NIncs ra szo!
Le se szarlak! Erted budos goreny?!
(abalole, a 20062. user)

[x] valamennyire értek és nem értem, mi ez a tűzfal-fetisizmus a választási lehetőségek közt.
A szervezetek határa már nagyon rég nem a tűzfalnál van és mióta a Universal Firewall Bypass Protocol-t gyakorlatilag minden tűzfal átengedi, kevéssé értem, hogy a határvédelmi tűzfalak miért lennének ennyire jelentősek magukban a konfiguráció bonyolításán, a változáskezelés lassításán és a hamis biztonságérzet biztosításán túl...

Üdv,
Marci

így van :) írták itt már páran, azért neked válaszolok mert te tudtad kultúráltan megemlíteni :)

szóval, nem értek a számítógépes biztonsághoz szinte semennyire, akik eldumpoltak a kérdéseken, kéretik a tűzfal helyére behelyettesíteni a "számítógépes biztonsági megoldások" (-at készítek, stb) kifejezést.

nahát, ilyesmivel is rég vádoltak, főleg a hupon :)

egyébként tényleg nem bántásnak szántam, csak mivel már jópáran leírták, hogy az IT biztonság jóval több a tűzfalnál (és a tűzfal jóval több a portnyitogatásnál), ezért abba már nem mentem bele, hogy mik vannak még.

Mivel nekem is cseppet gugliznom kellett, ideteszem, hátha "világosít" másoknak is valamit a "UFBP" mozaikszóról.

http://www.technospot.net/blogs/security-vulnerabilities-why-we-made-we…

És hozzáteszem, ezért jó az, ha "helyi érdekű" a webszerver csak befelé dolgozik. A többit meg adatközpontokban védjék a profik. (A fene akar a nap nagyrészében log-ok olvasásával foglalkozni.)

A baj szerintem kevéssé a webszerverekkel van. Inkább ott leledzik, hogy bármely belső végpont nyithat kifelé egy kapcsolatot, amin keresztül befelé is mehet bármi.
Tehát, ha bejuttatok egy kódot, ami simán, userként kifelé nyit, akkor már bent vagyok, a tűzfal helyeslő támogatása mellett...

Ráadásul a "helyi érdekű" webszerver egyre többször van egy nyilvános szolgáltatónál, amit az éppen a vállalati hálózattól távol lévő kliensek (okostelefonok, laptopok) közvetlenül érnek el. Eközben a peremvédelmi tűzfal önelégülten pihen.

Üdv,
Marci

"bármely belső végpont nyithat kifelé egy kapcsolatot, amin keresztül befelé is mehet bármi"

és ez a kurva nagy valóság. A kolléga https webmail hozzáférése gyakorlatilag a támadó és a legbelső már jogokkal rendelkező felhasználó, vagyis a rendszer összekötésre szolgál ha nincs alaposan szabályozva és legalább két motorral ellenőrizve, archiválva és újra ellenőrizve.
A kulcs a 0day és a polimorf, az ajtó az Adobe vagy az MS egy betűkészlete és egy outlook előnézet.
Láttam már gmail-ről ékező cryptolokkert tevékenykedni egy vírus védett kliensen, teljesen friss rendszeren ahol a felhasználó az O365 által ellenőrzött levelet csak törölte az outlook 2013-ban, az eredménye nem maradt el, azonnal elkezdte darálni a fileserver állományait. Mentés volt és korlátozott hozzáférés.

sajnos én az egyes kategória vagyok, elnézést az eretnekségért, olvasgatva a kommenteket rájöttem, hogy olyan mintha az kérdeztem volna ki milyen lyukkártyát használ programozáskor :)

köszi a hasznos hozzászólást amúgy, pont ilyenekre számítottam, hogy lesznek akik hozzák a naprakész információt

* tűzfalakat készítek

Többnyire a lemezvágással és hajlítással kezdem, valamint az előlappal mert az ügyfél leginkább azt látja. Ezek után mivel a kollégák munkáját elvették a gépek, azok előállítják a sokrétegű nyákot Na de ezután jön az igazi szopó, mire az összes smd alkatrészt felhelyezem, már azt sem tudom, hol vagyok, na de egyszer ez is elkészül. Ezután veszek hozzá még pár alkatrészt a sopban és pattintok rá némi bsd és gpl kódot amiket megfelelően konfigurálok és máris kész van :D

Na de komolyan. Régóta és változó mélységig foglalkozom ezzel is és a helyzet Magyarországon gyalázatos, gyakorlatilag még mindig a portok zárása és a nat valamint a kliens kód és portszűrés az egyetlen ide tartozó védelmi vonal amit talán az auto update egy picit még meg is tud támogatni azzal, hogy nem hagy ehetőséget.

Nagyon masszív és kétirányú ellenőrzést és szűrést kell alkalmazni a teljes átfolyó adat tartalmára valamint a hordozó protokollok helyességének ellenőrzésére ami még mindig csak a bejárat ellenőrzése, ahhoz hogy egy rendszer biztonságos is legyen, rengeteget kell tenni, rengeteg rétegben és összhangban egymással alapvetően a gyakorlati támadásokat alapul véve kiindulásnak.

A világ egy jobb hely lenne a dtrépélink és társai nélkül és sokkal rosszabb lesz az IoT (SoI,AoT) elterjedésével.

+1

+annyi, hogy nem eleg a hatart vedeni (pont a BYOD miatt) hanem monitorozni kell a belso halozatot is, meg 802.1x sem art melle. lattam en mar agyon tuzfalazott (sok millas cisco asa-k) erzekeny adatokkal dolgozo cegnel user altal feldugott tplink wifi routert mert a telojan is akart netezni (a ceges policy tiltotta a wifit ezert nem volt kiepitve)...

De az admin is, hogy mindenfele guardot nem kapcsolt be a portjain.
Ha jol emlekszem, akkor talan van dhcp guard is.

bpduguard biztosan van, arra emlekszem.

dhcp snoopingot mi is hasznaltunk, csak az volt a baj, hogy volt csomo 2950 is, ami meg nem tudta, es ha meg a 3750-eken ment, akkor meg konkret gerinc linkeket volt kepes leverni a ... fene emlexik mar a cisco feature nevere, ami ellenorzi a snooping database alapjan, hogy az adott porton levo adott mac-re van-e ervenyes lease...

.1x lett volna a tuti, csak a gepek auto deploymentjehez nem art...ott volna, ha agent nelkul be tudott volna kerulni valami fallback vlanba a deployment idejere, es a 2950-esek limitalt tudasaval megint labon voltunk love

Mindenesetre, ha eleg uj eszkozoket veszel, akkor egeszen szep iranyba fejlodtek az eszkozok tudasban. Asszem egy ideje nem volt dolgom L1/L2/L3 kornyekevel :)

+1

Ami még gyalázatos: a hozzáállás. Kulcsmondatok: "mindegy, csak működjön", "leszarom a biztonságot", "majd újrahúzom", "jó még az XP", "kit érdekel ha botnet része lesz a gépem? Amíg a Digi 20 mellett nem veszem észre, leszarom. Az afrikai éhezőket is sajnálom....", "amit nem vesznek észre, az nem fáj". Sorolhatnám. A héten ezzel akasztott ki az új "kolléga". Rendszerüzemeltetőként dolgozott vagy mi a f.. áh. Nem ért hozzá, de nem is törekszik rá. Szerencsére olyan poziba került, ahol sok bajt ezzel a hozzáállással nem okozhat.

Valamennyire értek, de nincs tűzfalam, iptables-t sem konfiguráltam. A „számítógépes biztonság” több aspektusával sem foglalkozom, de azért határozottan úgy vélem szem előtt tartom. A többi tudatosan vállalt maradék kockázat.
______________
"If you immediately know the candlelight is fire, the meal was cooked a long time ago."

Nevetseges szavazas. INkabb keszits egy tuzfalat..

Bocs, de igaza van. A halozati tűzfal önmagában lofasz, ennel egy sokkal tágabb az IT security temakore. Kezdve a mijdenfele szinten es formában elojovo authentication es authorization megoldasoktol kezdve (mint dev, mint op szemszögből), a különféle támadási technikák ismereten at (web eseten xss, sql injection, buffer overflow, es csillionyi mas) az adatvedelemig rengeteg tenakore van. Meg az is az IT security temakore, hogy Mancika egy postit cetlin kiirja-e a jelszavát a monitorara.

Tűzfal csak egy iciri-piciri szeglete az IT secnek.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

jó jó, mondjuk az "IT szakember" egy elég tág fogalom, a grafikus is mondja magára hogy IT szakember, de az IT biztonsághoz nem igazán szükséges konyítania, de egy szerverekkel foglalkozó IT szakembernek meg kötelező :)

Ma is tanultam valamit. Tűzfal = IT security.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

valamennyire értek, de nincs tűzfalam... minek bajlódni vele, ha előbb-utóbb úgy is feltör(het)ik?

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba


cat >> /etc/crontab
0 4 * * * root iptables -X && iptables -F &&  iptables -P INPUT ACCEPT &&  iptables -A INPUT -m comment --comment "Engem ne varjatok" -j DROP

--
Blog | @hron84
Üzemeltető macik