☰

» »

Linux varnost

Linux varnost

«
1
2

poweroff ::

Katero programje obstaja za preverjanje varnosti (okužbe z rootkitom) za Linux?

Jaz v bistvu poznam samo tele tri:
chkrootkit
rkhunter
unhide (forensic tool to find hidden processes)

Imam pa občutek, da so tele zadeve precej zastarele (predvsem chkrootkit). Obstaja še kaj, kar bi preverilo še če se hashi inštaliranega softwera ujemajo s tistim, kar je v repozitorijih? Tripwire poznam, ampak a obstaja kakšen podoben post-check...?
sudo poweroff

ABX ::

Težka bo.

Rootkit je zelo težko odkrit.


Lahko kontroliraš mrežo če se izpostavlja kakšna nepričakovana povezava.
Vaša inštalacija je uspešno spodletela!

Zgodovina sprememb…

  • spremenilo: ABX ()

poweroff ::

Jup:

netstat -an | grep EST

Pa potem recimo:
...
tcp 0 0 xxx.xxx.xxx.xxx:42672 xxx.xxx.xxx.xxx:80 ESTABLISHED
...

lsof -nP | grep 42672
firefox 26566 user 69u IPv4 2316081 TCP xxx.xxx.xxx.xxx:42672->xxx.xxx.xxx.xxx:80 (ESTABLISHED)


Še recimo tole:
netstat --inet -p

ali tole (z vsemi unix socketi)
netstat -p

Ali brez resolvinga:
netstat --inet -pn

Še kakšna ideja?

P. S. Nimam problema (vsaj ne da bi vedel :D ), rad bi samo malo predebatiral dobre strategije.
sudo poweroff

CCfly ::

Recimo kakšen IDS sistem, npr. Snort.
"My goodness, we forgot generics!" -- Danny Kalev

darkolord ::

Na isti mašini ni nič čisto zanesljivo, glede na to da je lahko tudi netstat (al pa kar kšn network stack) mal modificran.

denial ::

Darkolord ima prav. Če imaš ring0 rootkit je hookanje sistemskih klicev trivialno. Izpis ring3 ukaza je torej lahko modificiran.

Za IC poglej EICS ali AIDE. Za rootkite poglej zeppoo, vendar je verjetno outdated. There are no rootkits on Linux :)
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

terryww ::

ja kaj pa recimo kak deep packet inspection na gatewayu?
It is the night. My body's weak.
I'm on the run. No time to sleep.

CCfly ::

Tudi monitoring prek SNMP-ja bi lahko nakazal na vdor, če seveda mašina ne miruje.
"My goodness, we forgot generics!" -- Danny Kalev

darkolord ::

ja kaj pa recimo kak deep packet inspection na gatewayu?
Čist odvisno, kolk pametna je zadeva. Lahko sploh zelo redko komunicira prek neta, lahko komunicira takrat, ko je na povezavi "gužva" (se skrije med ostali promet), lahko komunicira prek navidez nedolžnih protokolov (DNS requesti), itd.

jype ::

Saj zato pa je deep inspection tako drag špas, ker ti nič ne pomaga, če se skriješ kamorkoli.

Če je odd looking, ne pride skoz - je pa to pogosto združeno s support requesti.

darkolord ::

Ja, ampak stvar še zdaleč ni perfektna.

Zgodovina sprememb…

  • spremenilo: darkolord ()

poweroff ::

Varianta bi bila livecd, pa preverjanje hashov binaryev...

Za IC poglej EICS ali AIDE. Za rootkite poglej zeppoo, vendar je verjetno outdated. There are no rootkits on Linux :)

Evo, točno o tem govorim! To je posledica tega Linuxaškega spanja na lovorikah.

Kje je zdaj COKS? 8-)
sudo poweroff

poweroff ::

Aja, pa še tole... Kako pa tripwire dela? Mislim, kako rešuje problem Ring 0 rootkitov?
sudo poweroff

ABX ::

ja kaj pa recimo kak deep packet inspection na gatewayu?
Čist odvisno, kolk pametna je zadeva. Lahko sploh zelo redko komunicira prek neta, lahko komunicira takrat, ko je na povezavi "gužva" (se skrije med ostali promet), lahko komunicira prek navidez nedolžnih protokolov (DNS requesti), itd.


+1

Jaz v službi bežim ven čez port 443. :)
Vaša inštalacija je uspešno spodletela!

jype ::

Matthai> Kako pa tripwire dela?

Tko da checksuma fajle. Nothing a decent rootkit can't handle.

Kostko ::

Ja, če checksume ali bilokaj preverjaš na sistemu, ki je lahko kompromitiran, potem rezultatom pač ne moreš zaupati. Zaradi tega so vsi te utilsi omejene uporabne vrednosti čim gre za ring 0 rootkite (razen seveda, če lahko izklopiš zadevo in audit laufaš na drugem sistemu nad istimi podatki - seveda za to mora že obstajati sum, da je gor kako sranje). Verjetno bi šlo to lažje v kolikor bi mel vse te sisteme znotraj virtualcev (pač verjetnost da nekdo exploita kernel v virtualcu potem pa mu rata heknit še hypervisor in kompromitirat host sistem je manjša, ni pa seveda nič:).
Human stupidity is not convergent, it has no limit!

darkolord ::

Pri checksumih je lahko problem pri kakšnih skriptah, ker se nekatere kar pogosto spreminjajo in nimaš njihovega "zdravega" cheksuma.

Glede virtualca, če imaš rootnjenga virtualca, maš v vsakem primeru precej dela, če na njem laufa še karkoli drugega uporabnega (oz potrebnega)

BigWhale ::

Hm. Kaj pa ce bi do device-a dostopal mimo file sistema, ko delas checksume?

Brane2 ::

Če se ne motim, je v bolj svežih kernelih omenjena podpora checksummingu.

Mogoče bi moral prešnofat menuconfig in si pogledati dokumentacijo...
On the journey of life, I chose the psycho path.

poweroff ::

Problem je to kar je rekel Darkolord - skripte se lahko pogosto spreminjajo.

Drugi problem je, da je najbolj zanesljivo zadeve preverjat offline (npr. z liveUSB), vendar za serverje, ki zahtevajo 24/7 to ne pride ravno v poštev. Razen... če bi izkoristil RAID in začasno odklopil en disk, preveril in potem hotpluggal nazaj. Samo je precej riskantno...
sudo poweroff

Brane2 ::

Problem je to kar je rekel Darkolord - skripte se lahko pogosto spreminjajo.


Zakaj je to problem ob podpori v kernelu ?
Če skripto spreminja aplikacija, ki ji verjameš, bo pač hash updatan ob vsakem vpisu.
On the journey of life, I chose the psycho path.

darkolord ::

Kaj pa če jo spreminjaš ročno? Al pa če jo spreminja druga skripta?

Brane2 ::

Kako pa jo spremeniš ročno mimo kernela ?

Skozi neposreden dostop disku ( "raw sectors") etc ?

To lahko preprečiš.
On the journey of life, I chose the psycho path.

darkolord ::

Če delaš checksum binarijev, to narediš ob namestitvi in ob raznih updejtih itd in hashe pol spraviš na neko varno lokacijo (točnega mehanizma v linux ne poznam, a je tako nekako logično). Glede na to, da je preverjanje hashev treba izvest offline, se izvaja precej redko in ima zalega lahko tudi dovolj velik time window, da počaka na naslednje updejtanje in se takrat infiltrira na FS.

Če skripto spreminja aplikacija, ki ji zaupaš, pol se ta hash pač updejta, ko se fajl spremeni. Tle maš že en problem, da težko zagotoviš, da je aplikacija, ki ta fajl spreminja, še vedno intaktna.

Ko boš pa fajl ročno popravljal, boš pa moral pri vsakem popravku tut ročno sprožit hashanje tega fajla, kar je najprej zelo nepriročno, poleg tega lahko rootkit (ker lahko predpostavljaš, da zadeva skozi v ramu čaka na pravo priložnost) commita svoje spremembe tik preden sprožiš hashanje in nevede pohashas se rootkitove spremembe (lahko so tudi v istem fajlu, ki ga ti popravljaš)...

Zgodovina sprememb…

Brane2 ::

Če imaš mehanizem za izračun in vpis hasha izpeljan v kernelu, potem edino rabiš dovoljenje za dostop trusted aplikacije do tega mehanizma.

Ni videti pametnega vzroka, zakaj bi ti preračunaval tam neke SHA zadeve, če ti kernel verjame.

Ti toej dobiš dovoljenje za updejt hasha na fajlu, ki bi ga rad vpisal in ko zapreš fajl, kernel preračuna hash in ga vpiše kot kak attribut fajla.

Pri execu in loadu knjižnice pa zahteva, da ta ima hash in da je ta veljaven.

Kar pa se posega rootkita tiče- valjda je predpogoj, da lahko zaupaš svoji pooblaščeni aplikaciji.

Če ta odpre fajl in dobi deskriptor zanj, ni videti mehanizma kako bi že preko tega kak rootkit prišel do možnosti vpisa svojega hasha...
On the journey of life, I chose the psycho path.

poweroff ::

V primeru, da ročno popraviš skrito se tega sicer res ne da mimo kernela, vprašanje pa je ali lahko zaupaš uporabniku.

Ker če ti nekdo ukrade/ugane geslo in potem rootne kišto bo imel kernel problem: ne ve ali si to naredil ti, ali nekdo, ki je zlorabil tvoje geslo.
sudo poweroff

darkolord ::

Če pride do exploitanja, je namesto "ti/nekdo" lahko tudi "nekaj"

terryww ::

vsak prog v svoj jail pa bo mir
It is the night. My body's weak.
I'm on the run. No time to sleep.

fiction ::

Checksum naredis ob instalaciji potem pa spravis to nekam offline (recimo na USB kljuc) in tam to tudi ostane dokler nekdo ne posumi, da je nekaj narobe. Takrat moras nujno bootati nek trusted kernel (ali pa odklopiti disk), ker sicer ne mores vedeti ali sploh dobivas prave podatke o tem kaksni so binaryi (lahko ti samo jedro laze o tem da je vsebina taka da bo checksum ok). Za kriticne masine rabis v vsakem primeru nek backup.

Ce je itak kernel pohekan najbrz ni smiselno, da so se programi, ampak vseeno. Ce imas "cisto sliko" o tem kaj je na disku lahko naredis forenzicno preiskavo in morebiti najdes kaksne sledi od napadalca (sniffer logi, exploiti). Checksumi ti pomagajo samo do te mere, da se ti ni treba ubadati s tem kaj vsak program dela, ampak enostavno na podlagi whitelista reces to je pa sigurno ok. Druga stvar, ki ti pomaga je, ce lahko zaupas timestampom.

Zakaj bi moral karkoli popravljati? Ce namestis novo verzijo dolocenih binaryjev to ves in si lahko loceno shranis njihov checksum. Za skripte ali nekaj kar pogosto popravljas ponavadi niti nima smisla preverjati ali so ok ali ne (nek backdoor v tistem glede na to, da pogosto saris po tistem tako ali tako hitro odkrijes). Kakor hitro dovolis da se nekam avtomatsko shranjuje (ali se huje popravlja) checksum, je ta zelo verjetno brez pomena. Jedro namrec ne more vedeti "to zdaj je pa administrator", "zdaj je pa nekdo shekal administratorski racun".

To je problem DAC. S tem, ko samo ob dolocenem casu vstavis medij za shranjevanje checksumov to do neke mere (ce odmislimo razne race-conditione) resis. Ce hoces vec, lahko uporabis MAC, kjer je uporabnik omejen se z globalno varnostno politiko. Ta lahko definira, da proces, kljub temu da je root, lahko dela samo to in to in nic drugega. Zdaj je problem samo se v tem kdo lahko ta pravila popravlja.

Tako bi sicer lahko naredil nek trusted checksum updating postopek, ampak vseeno je lazje ce samo definiras kaj naj vsak proces dela in s tem otezis vdor.

Gandalfar ::

Takrat moras nujno bootati nek trusted kernel (ali pa odklopiti disk),


Hitro podvprasanje, kako ves da lahko zaupas firmwaru diska? :)

darkolord ::

Za skripte ali nekaj kar pogosto popravljas ponavadi niti nima smisla preverjati ali so ok ali ne (nek backdoor v tistem glede na to, da pogosto saris po tistem tako ali tako hitro odkrijes).
Ma, na to, da boš s sokoljim očesom odkril spremenjeno skripto, se ni za zanašat - lahko je samo l zamenjan z 1 pa tega ne opaziš in se požene čisto nekaj drugega...

ampak vseeno je lazje ce samo definiras kaj naj vsak proces dela in s tem otezis vdor
No ampak do vdora lahko vseeno nekako pride, kar spet pripelje nazaj do glavnega vprašanja te debate: ali je možno na kakšen način (najboljše brez milijonskega HWja) 100% zaznati vdor? Naštetih imamo kar nekaj potencialnih rešitev, a imajo vse kakšno slabost, ki bi se jo teoretično dalo izkoristit - trenutno je namreč problem že pri odkrivanju vseh koščkov bolj osnovnih rootkitov

Zgodovina sprememb…

fiction ::

Hitro podvprasanje, kako ves da lahko zaupas firmwaru diska? :)
Good point. V bistvu gre vse lahko bolj in bolj globoko. Lahko imas ze malware kar v firmwaru in ta potem ob vsakem bootu "popravi" kernel pa si screwed. Samo tudi za napadalca je tako delovanje tezje, ne samo zate.

darkolord ::

Hitro podvprasanje, kako ves da lahko zaupas firmwaru diska? :)
Težko, lahko pa s kriptografijo načeloma preprečiš, da bi disk oz. kontroler imel direkten dostop do raw podatkov. Maš pa potem problem s ključi/passkeyi, če je firmware kakšnega drugega dela plate "zloben"

Zgodovina sprememb…

fiction ::

No ampak do vdora lahko vseeno nekako pride, kar spet pripelje nazaj do glavnega vprašanja te debate: ali je možno na kakšen način (najboljše brez milijonskega HWja) 100% zaznati vdor?
Kako pa sploh definiras vdor? Z neko precej visoko verjetnostjo najbrz lahko zaznas odstopanje od standardnega delovanja na doloceni masini. Takrat lahko zazenes paniko (IDS / IPS) ali pa samo poskrbis da do cesa takega ne bi smelo priti (stroga pravila). Samo karsnokoli tako "anti hacker opremo" vedno lahko (bolj ali manj tezko) preslepis. Imam filing, da je to da bi nek stroj za drug stroj povedal, ce je shekan neodlocljiv problem. :)

fiction ::

Maš pa potem problem s ključi/passkeyi, če je firmware kakšnega drugega dela plate "zloben"
Dosti da je ze ta od diska "zloben". Sej ni nujno, da je njegov edini namen spreminjanje tega kar vidis / napises na disk. V takem primeru pac ne zaznas vdora. Komplicirati se ti splaca samo do te mere, da manj zapravis za to kot so vredni podatki, ki jih varujes.

darkolord ::

Kako pa sploh definiras vdor?
Recimo nepooblaščen dostop (človeka ali drugega stroja) do mašine...

Z neko precej visoko verjetnostjo najbrz lahko zaznas odstopanje od standardnega delovanja na doloceni masini.
En problem je ugotovit standardno delovanje, drugi problem je monitoriranje - če je sistem kompromitiran, se na samo-monitoriranje sistema ne moreš zanašat in moraš uporabiti nekaj zunanjega (kaj?).

ali pa samo poskrbis da do cesa takega ne bi smelo priti (stroga pravila).
Preventiva je boljša kot kurativa, ja, ampak do sedaj ni bilo še nobenih tako strogih pravil (ki seveda ne omejujejo osnovne funkcionalnosti), ki bi bila 100% zanesljiva.

Takrat lahko zazenes paniko (IDS / IPS)
No, to (panika) je že naslednja faza... Ko in ČE ugotoviš, da neki ne štima.

jype ::

jmakov> vsak prog v svoj jail pa bo mir

Slišal sem že za security model, v katerem ima vsak program svoj filesystem (reklo se jim je namespaces) in so ACLji narejeni tako, da dovoliš dostop do (dela) enega namespaca drugi aplikaciji.

Reč je bila podrobno razdelana za interaktivno uporabo, za strežnike pa ne, sem pa prepričan, da bi se tako reč dalo implementirat kot zelo učinkovit sistem ločevanja privilegijev.

darkolord> En problem je ugotovit standardno delovanje, drugi problem je monitoriranje

AppArmor recimo to odlično rešuje.

poweroff ::

Evo, svež primer ownanja Ubuntuja: http://ubuntuforums.org/showthread.php?...
sudo poweroff

poweroff ::

Hidden ports on Linux: http://www.ossec.net/dcid/?p=87

If you ever had trouble with hidden ports on Linux (2.4 and 2.6), I may have figured out one of the possible causes today (and no, it is not a rootkit). To keep the story short: if you bind any TCP port, but do not listen on it, netstat will not show it at all (the same does not happen with UDP ports).

Here is the idea. If you get this simple C program, it will attempt to bind every TCP port from 1025 to 1050, but it will not listen on them. After it is done, if you do a netstat (or fuser or lsof) nothing will be shown. However, if you try to use the port, you will get an error saying that it is already in use.


Tole se mi zdi kot napaka v varnostnem designu...
sudo poweroff

fiction ::

Meni se tole zdi bolj nepoznavanje delovanja TCP/IP-ja :)
UDP je connectionless - takoj ko naredis bind() lahko nekaj sprejmes, medtem ko moras pri TCP-ju na strani clienta narediti connect(), na strezniku pa listen() in kasneje accept() za novega odjemalca. Torej, ce naredis samo bind() na TCP socketu ne bo nic - s tem samo reces eksplicitno hocem uporabiti ta naslov.
Bind() lahko naredis na strani clienta (hocem uporabiti ta izvorni IP in port) ali pa na strani serverja
(poslusal bom na tem IP-ju in tem portu). Ampak dejansko po tem se nic ne "poslusa", torej jasno tega tudi ne vidis v netstat. Ne moreta pa dva uporabiti istega TCP porta. Ni tole tako, da bi lahko neka stvar skrito cakala na povezave od zunaj ali kaj si predstavljas.

Zgodovina sprememb…

  • spremenil: fiction ()

poweroff ::

JA, razumem. Vseeno bi raje videl, da netstat izpiše tudi bindinge...
sudo poweroff

fiction ::

Pomoje tega niti ne more, ker Linux kernel ne exposa teh podatkov. Sem pogledal /proc/net/tcp in prebral include/net/tcp_states.h in izgleda kot da to, ali je TCP socket bind()-an ali ne, ni posebno stanje. Bind() naceloma, da citiram manual, samo da ime socketu. Je pa afaik mozno tak podatek dobiti na Solarisu.

Z varnostnega stalisca je mogoce lahko problem, ker bi nekdo s tem lokalno izvajal DoS napad (stevilo pametnih sockaddressov je na masini precej omejena dobrina) in admin ne bi imel pojma kaj se dogaja. Ampak po drugi strani pa ne mores enega socketa ponovno bind()-ati, kar pomeni, da rabis za izvedbo tovrstnega napada vec procesov oz. vec odprtih fd-jev - to pa se da precej dobro limitirati oz. odkriti.

Najbrz se razvijalcem ni zdelo smiselno na ven razlikovati med socketi z imenom in takimi brez, ker vsak socket itak rabi "svoje ime", da lahko z njim kaj smiselnega pocnes. Torej stanje, ko socket() ni implicitno ali eksplicitno bindan je najbrz praviloma zelo kratkotrajno.

Je pa se zmeraj malo nadlezno, da do takega podatka ne mores priti. No mogoce pa pozna kdo kaksen workaround?

BlueRunner ::

Jp. Sem ravnokar pogleal na Solarisu. Tam netstat lepo pokaže "BOUND".

Na Linux-u pa lsof sicer najde fd, o njemu pa ne more prebrati podatkov (can't identify protocol). Tako, da je na voljo neka minimalna diagnostika, oz. iskanje osumljenih procesov, ni pa možno to, kar je možno na Solarisu.

fiction ::

Sem probal se na FreeBSD-ju. Tam se dejansko v "netstat -a" prikaze cisto vsak TCP socket. Njegovo stanje je po defaultu CLOSED. Ce naredis bind() se spremeni samo to, da Local Address ni vec *.* ampak nekaj drugega.

denial ::

Dave Aitel speaks: KLIK. Any opinion about topic?
SELECT finger FROM hand WHERE id=3;

poweroff ::

Tip ima prav. Če se bo tak center res ustanovil, bo to the right way. Če ne, se bo lekcije treba naučiti the hard way.
sudo poweroff

denial ::

Še en način minimalne diagnostike za odkrivanje hidden portov:
ls -l /proc/$pid/fd | grep socket
SELECT finger FROM hand WHERE id=3;

denial ::

All Linux 2.4/2.6 versions since May 2001 are believed to be affected... KLIK

Spender je objavil exploit: KLIK

Patch: KLIK
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

terryww ::

heh, pri de Raadtu morjo bit zdaj židane volje :) (schadenfreude)

edit: sosedov Raison d'être
It is the night. My body's weak.
I'm on the run. No time to sleep.

Zgodovina sprememb…

  • spremenil: terryww ()

denial ::

Ubuntu 9.04 is not vulnerable. vm.mmap_min_addr is in place... skoraj vedno. V nasprotnem primeru...

SELECT finger FROM hand WHERE id=3;
«
1
2

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Največji problem še vedno PEBKAC

Oddelek: Novice / Zasebnost		475472 (3481) MrStein
»

Linux - konfiguracija domene

Oddelek: Omrežja in internet		221770 (1551) EagerWolf
»

IPTABLES in TCP flags problem

Oddelek: Operacijski sistemi		171452 (1281) Bojan xxxx
»

iptables + forward

Oddelek: Operacijski sistemi		332332 (1907) tx-z
»

FXP problemi

Oddelek: Omrežja in internet		91241 (1120) darh

Več podobnih tem