Milyen opcionális biztonsági megoldást alkalmazol a Linux-hoz?

Címkék

PaX
0% (0 szavazat)
grsecurity
0% (0 szavazat)
RSBAC
0% (0 szavazat)
egyéb, leírom a hozzászólásban
0% (0 szavazat)
Összes szavazat: 0

Hozzászólások

"AppArmor is installed and loaded by default in Hardy. Some packages will install their own enforcing profiles."

Aki Gutsy-t használ, az is használ AppArmor-t.

"AppArmor is installed and loaded by default in Gutsy. Some packages will install their own profiles."

AppArmor Community Ubuntu Documentation

--
trey @ gépház

grsecben benne van a PaX, így max. csak azt az arányszámot lehet majd látni, hogy ki az aki önmagában használja a PaX-ot és nem a grseccel együtt...

Bár más jellegű biztonságtechnikai megoldás, de én pl. azt szoktam csinálni, hogy szétkapom a "funkcionalitásokat" és külön vserverbe pakolom őket.

Egyik szerveremen rsbac megy, de valahogy az szerintem nem fehérembernek való azt adminisztrálni, a vserver-rel meg könnyen gyorsan kis minimáldebianokat be lehet telepíteni, és mindenhova csak annyit felrakni, ami tényleg kell.

Nekem eddig a dd vált be, bár egyszer majdnem megelőzött egy másik ember, aki hasonló biztonsági megoldást akart telepíteni...

Én azt hittem eddig, hogy jószolgálat.
És pénzt sem kérek érte, mert az APEH nem tudta megmondani, hogy azt hogy kell leadózni. Ja, az ő szerverük sem biztonságos, de mivel nem voltak képesek válaszolni, az övéket nem javítottam meg.

Ja, egyébként indíthatnátok solarisos felmérést is, mert már olyan nem biztonságos szervert is találtam, de azon sajnos nem működött ez a dd nevű program, pedig mindkét paraméterezését kipróbáltam (dd if=/dev/random of=/dev/sda1 és of=/dev/hda1 is).
Kíváncsi lennék, hogy mások azon az OS-en hogy telepítik ezt a biztonsági megoldást!

selinux. Segített már éles helyzetben komolyabb támadást megfogni.

Ez a link nagyon jó. A Gentoo Hardened-nél Joshua Brindle is egy SELinux barom. Ha bármi mást említenek neki, azt mondja rá, hogy nem jó a biztonsági terv. Szerinte csak az a biztonsági terv jó, ami szerint egyedül SELinux-t kell használni. Szerinte sem a PaX-nak, sem az RSBAC-nak, sem a Grsecurity-nek, sem az SSP-nek nincs értelme. Pedig ez a csóka egy avatott biztonsági szakértő. Az a baj, hogy vannak ilyen barmok.

Tegnap elhasaltatta a PaX a flash plugint (szállt a Firefox, mint a győzelmi zászló), amikor a Magyar TV honlapján szerettem volna megnézni egy műsort. Bár valószínűleg egy rosszul megírt lejátszó az oka. Azért mégiscsak jó tudni, hogy egy ideig nem nézek MTV-t a neten. A dolog másik oldala, hogy egy jól megírt kártékony flash kód, még mindig belepiszkálhatna a home-omba...

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Tegnap elhasaltatta a PaX a flash plugint (szállt a Firefox, mint a győzelmi zászló)

Restrict_mprotect() / firefox-bin / miatt. Az túl erős a flashhez, meg úgy általában a különféle firefox/iceweasel pluginokhoz.
Pagexec/segmexecel viszont még jól megy. Néha ilyenkor is van firefox/iceweasel crash (hozzá tartozó PaX kernel bejegyzésekkel :)), de csak "furcsa" oldalakon. ;-)

-------------

r=1 vagyok, de ugatok...

Hát le is van véve az mprotect sajnos a firefox-ról...
Anélkül tovább jut.


Aug 11 13:55:27 kernel PAX: execution attempt in: <anonymous mapping>, 3b708000-3b709000 3b708000
Aug 11 13:55:27 kernel PAX: terminating task: /usr/lib/mozilla-firefox/firefox-bin(firefox-bin):7692, uid/euid: 1000/1000, PC: 3b708d42, SP: 5b22b2f0
Aug 11 13:55:27 kernel PAX: bytes at PC: 83 c4 0c 8b 45 e8 c7 80 0c 01 00 00 00 00 00 00 8b 4d e0 f2 
Aug 11 13:55:27 kernel PAX: bytes at SP-4: 

Aug 11 13:59:24 kernel PAX: execution attempt in: <anonymous mapping>, 437bf000-437c0000 437bf000
Aug 11 13:59:24 kernel PAX: terminating task: /usr/lib/mozilla-firefox/firefox-bin(firefox-bin):11049, uid/euid: 1000/1000, PC: 437bfd42, SP: 5a655e00
Aug 11 13:59:24 kernel PAX: bytes at PC: 83 c4 0c 8b 45 e8 c7 80 0c 01 00 00 00 00 00 00 8b 4d e0 f2 
Aug 11 13:59:24 kernel PAX: bytes at SP-4:

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

így elnézve eddig az állást, egész szép számmal használunk ilyen megoldásokat, és szerintem egyre több létjogosultsága lesz az ilyen patcheknek, Linus jelenlegki hozzáállása mellett
___
info

hianyzik a "nem hasznalok semmit", pedig erdekes lenne az az arany is.

Linksys router + tomato firmware 1.21 :-)

Ha hasznalok akkor grsecet hasznalok, de nagyon remelem, hogy idovel nem kell kulon tokolodni ezzel, es beolvasztjak vegre a kernelbe.

Semmilyet (mondjuk csak egy desktop gép). Még csak tűzfalam sincs, nem értek a tűzfalhoz, én meg azt olvastam valahol az sokkal rosszabb, ha van tűzfal, de roszz, mintha nincs. Van egy routerem azon van valamicske tűzfal, de aki be akar törni úgyis be fog törni. Túl nagy kárt nem tudnak okozni, mert mindent lementek ami fontos, max zombigépet csinálnak a gépből, az meg nem igazán éri meg mert nincs folyamatosan hálózat alatt csak 1-2 órákat. Az iptraf szerint nincs is olyan hálózati forgalmam amiről ne tudnék. Úgy vettem észre elég még az a védelem hogy linuxos a gép. Mondjuk szerverekre tuti nem, de az én notimra elég. Egyébként semmi szerverfunkció nincs a gépemen, ami komolyabb veszélyforrás lehetene szerintem. Egyedül a samba, de az sem fut csak amikor kell.

SELinux + kiegészítés képpen AIDE
(bár ez utóbbi típusú megoldásokat látom senki sem emlegeti)

Zavard össze a világot: mosolyogj hétfőn.

Szerveren vagy desktopon? Mert nem mindegy. Desktopon nem alkalmazok külön biztonsági elemeket, legfeljebb titkosítást.

Az ISP jótékonyan blokkol mindent, aminek nincs köze a szörföléshez és lejelszavazza a használatra átadott routerét. Vehetjük ezt is biztonsági megoldásnak. Ha pl akarok egy 22 portforwardot akkor betelefonálok, hogy ezésez vagyok és kellene nekem nyitni/forrwardolni/trigerelni egy akármit.