Linux-security

Az SG.hu cikke szerint a Pentagon és a Légierő közösen kifejlesztett egy biztonságos Linux telepítőkészletet. A rendszer a működése során nem ment háttértárra semmilyen adatot.
Bárki letöltheti innen: http://www.spi.dod.mil/lipose.htm
Kétféle változat létezik. Az egyik egy alap, a másikban van OpenOffice és Adobe Reader is. A telepítőkészletek iso formátumban léteznek és ezeket le lehet tölteni tömörített formában is. A rendszer alapvetően CD-ről fut de USB-kulcsról is működik. Használható szinte minden Intel processzoros PC vagy Mac számítógépen. Nem kell rendszergazdai jogosultság és a rendszer nem telepít semmit a merevlemezre. A rendszer főleg neten keresztüli ügyintézésre és munkára készült. Ha a fölhasználó olyan weblapra téved amit a rendszer kockázatosnak ítél akkor a rendszer önmagától újraindul hogy az esetleges fertőzés lehetőségét kizárja. (Nem tiszta hogy ezt mikor teszi meg: A lapra való belépéskor vagy annak elhagyása után.)

Tegyuk fel, hogy - mivel nem vagy elegedett a vendor altal szallitottal - sajat RPMet csinalsz az Apache httpdbol.

Kerdesek:
- Upstreambol vagy SRPMbol forditanal? Milyen szempontok alapjan?
- Milyen core modulokat raknal bele es miket nem? Miert?
- Az osszes modult egy nagy RPMben szallitanad vagy minden modult kulon RPMbe raknal? Miert?

Nyilvan megvan a sajat velemenyem is, de a tieteket is szeretnem hallani :)

Sziasztok!

Van egy szerverünk, ahol a userek szabadon adhatnak hozzá cron-okat, annyi megkötéssel, hogy csak PHP scripteket tudnak futtatni.
A kérdésem az lenne, hogy meg lehet-e oldani valahogy, hogy ezeket a folyamatokat bechroot-oljuk valahogy?

Előre is köszi minden segítséget!

Sziasztok,

Ti milyen eszközöket használtok Linuxos szerverek biztonsági tesztelésére? Külső és belső eszközök is érdekelnének. Esetleg olyanok is érdekelnek, amelyek a telepített webes appok biztonságát is megpróbálják ellenőrizni.

Köszi,
KAMI

Sziasztok,

néhány napja az egyik gépem elérhetetlenné vált. Bementem a szerverparkba, és átnéztem a gépet. Látszólag elfogyott a memória, és szépen kilőtte a rendszer a folyamatokat. Muninban látszott egy magas load (25 körül azt hiszem). Ezután nem lehetett a szervert semmilyen formában elérni. Csak a ping működött.
Ujraindítás után látszólag minden rendben volt. De ma ismét jelentkezett a szituáció, így kértem rá egy újraindítást. Belépés után igazából semmi gyanúsat nem láttam a naplófileokban. Figyeltem a memóriát, load-ot, de nem volt vészes egyik sem most. A fizikai memória nagyrészt ki volt használva, de a swap majdnem üres volt.
Aztán egyszer minden jel nélkül ismét megzűnt a kapcsolat. Ekkor futott a top, de nem voltak furcsa jelek itt sem.
Újraindítást követően beléptem ssh-n, majd pár másodperccel később ismét megszűnt a kapcsolat.
Innen elég gyanús a külső beavatkozás.

Abban szeretnék segítséget kérni, hogy kiderítsem, tényleg külső beavatkozás -e, vagy esetleg valamilyen szoftveres/hardveres hibáról van -e szó.

Feltettem a grsecet (High modra van allitva) a gondom az hogy elolvastam dokumentaciojat es keresgeltem is neten de nemnagyon ertem pontosan hogy mukodik a tanulas-ACL generalos dolog.

Alapbol a targyban emlitett shutdown al van gondom, nem jarhato nalam, hogy csak felhasznaloi beavatkozasra alljon le a rendszer mert korlatozott aksiju szunetmentesrol megy a cucc, szal ha kigyogy szufla szunetmentes soros porton leallitja gepet, csakhogy ha GRSEC enabled eppen akkor nemfogja tudni leallitani.
Erre weben olyan megoldast irtak, hogy meglehet tanittatni a leallitas folyamatot is, esakkor lefogja tudni allitani... (meg irtak meg vlmi olyat hogy vlmi jogosultsagot kell adni a shutdown futtatashoz meg vlmi rejtett fajl, mittomen azt nem ertettem :)

gradm -F -L learn.log

Ezzel lehet folyamatosan a megfigyelt szabalyokat learn.log ba rakni, de ha en pl. ujraindotom gepet akkor ha mar korabban megvolt a learn.log akkor folytatja a szabalyok feljegyzeset, vagy nyakonvagja ? (ugy vettem eszre folytatja)

Amikor a logbol ACL eket keszitek (gradm -F -L learn.log -o /etc/grsec/policy) akkor doksi szerint az uj szabalyokat a policy vegere teszi, nade ebbol gondok lehetnek, mert pl. vlmi "role admin" ra panaszkodik hogy az mar korabban benne volt es ugy nem tudja elinditani.
Most akkor hogyan kell:
- egyreszt ugy automatikus tanitast csinalni hogy esetleg tobb reszletben csinalok learn logot, es ujra meg ujra hozzarakom policy ACL hez
- hogy lehet megoldani hogy konkretan az apcupsd le tudja allitani rendszert normal modon.

Elore is tx

Sziasztok,

a w00tw00.at.* valamilyen botnet?
Milyen hatékony módszerekkel lehet védekezni a hasonló szimatolgatásokkal szemben?

Az apache access logjában a nevére szűrve ennyi látszik:

208.109.191.74 - - [31/Jan/2011:18:28:56 +0100] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 383 "-" "-"
77.70.54.66 - - [11/Feb/2011:14:13:34 +0100] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 383 "-" "-"
91.121.243.113 - - [11/Feb/2011:22:38:25 +0100] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 413 "-" "ZmEu"
89.136.100.192 - - [13/Feb/2011:04:47:04 +0100] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 383 "-" "-"
213.199.197.134 - - [14/Feb/2011:09:33:16 +0100] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 413 "-" "ZmEu"
121.248.63.102 - - [14/Feb/2011:18:52:36 +0100] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 383 "-" "-"

az error.log-ban pedig egy adott IP-re szűrve ehhez hasonló sorozatok:

[Mon Feb 14 09:33:16 2011] [error] [client 213.199.197.134] File does not exist: /var/www/w00tw00t.at.blackhats.romanian.anti-sec:)
[Mon Feb 14 09:33:20 2011] [error] [client 213.199.197.134] File does not exist: /var/www/admin
[Mon Feb 14 09:33:20 2011] [error] [client 213.199.197.134] File does not exist: /var/www/admin
[Mon Feb 14 09:33:20 2011] [error] [client 213.199.197.134] File does not exist: /var/www/admin
[Mon Feb 14 09:33:21 2011] [error] [client 213.199.197.134] File does not exist: /var/www/db
[Mon Feb 14 09:33:21 2011] [error] [client 213.199.197.134] File does not exist: /var/www/dbadmin
[Mon Feb 14 09:33:21 2011] [error] [client 213.199.197.134] File does not exist: /var/www/myadmin
[Mon Feb 14 09:33:21 2011] [error] [client 213.199.197.134] File does not exist: /var/www/mysql
[Mon Feb 14 09:33:22 2011] [error] [client 213.199.197.134] File does not exist: /var/www/mysqladmin
[Mon Feb 14 09:33:22 2011] [error] [client 213.199.197.134] File does not exist: /var/www/typo3
[Mon Feb 14 09:33:22 2011] [error] [client 213.199.197.134] File does not exist: /var/www/phpadmin
[Mon Feb 14 09:33:25 2011] [error] [client 213.199.197.134] File does not exist: /usr/share/phpmyadmin/scripts
[Mon Feb 14 09:33:25 2011] [error] [client 213.199.197.134] File does not exist: /var/www/phpmyadmin1
[Mon Feb 14 09:33:28 2011] [error] [client 213.199.197.134] File does not exist: /var/www/pma
[Mon Feb 14 09:33:28 2011] [error] [client 213.199.197.134] File does not exist: /var/www/web
[Mon Feb 14 09:33:28 2011] [error] [client 213.199.197.134] File does not exist: /var/www/xampp
...


de vannak olyan logrészletek is, ahol nem "azonosítja magát" a sniffer:

[Sat Feb 12 13:51:13 2011] [error] [client 89.133.73.105] File does not exist: /var/www/_vti_bin
[Sat Feb 12 13:51:13 2011] [error] [client 89.133.73.105] File does not exist: /var/www/MSOffice
[Sat Feb 12 13:51:36 2011] [error] [client 89.133.73.105] File does not exist: /var/www/_vti_bin
[Sat Feb 12 13:51:36 2011] [error] [client 89.133.73.105] File does not exist: /var/www/MSOffice
[Sat Feb 12 14:00:55 2011] [error] [client 89.133.73.105] File does not exist: /var/www/_vti_bin
[Sat Feb 12 14:00:55 2011] [error] [client 89.133.73.105] File does not exist: /var/www/MSOffice
[Sat Feb 12 14:01:42 2011] [error] [client 89.133.73.105] File does not exist: /var/www/_vti_bin
[Sat Feb 12 14:01:42 2011] [error] [client 89.133.73.105] File does not exist: /var/www/MSOffice
[Sat Feb 12 14:07:36 2011] [error] [client 89.133.73.105] File does not exist: /var/www/_vti_bin
[Sat Feb 12 14:07:36 2011] [error] [client 89.133.73.105] File does not exist: /var/www/MSOffice


Blacklistre kerülnek ezek az IP-k valahol és lehet IP alapján szűrni? Ki hogyan kezeli a hasonló próbálkozásokat?

Hulye cim, tudom :) Amugy a kovetkezo erdekel:
Adott egy konyvtar, alkonyvtarakkal, szabvanyos felepitessel, csak mondjuk a 3. szinten valtozik a nev.
pelda:
/var/www/domain1/
/var/www/domain2/
/var/www/domain3/

A fenti alatt mindegyik alkonyvtar szabvanyos, vagyis

/var/www/domain1/etc
/var/www/domain1/home
/var/www/domain1/log
/var/www/domain2/etc
/var/www/domain2/home
/var/www/domain2/log

Namost, logrotate tudja a kovetkezot:
/var/www/*/log/*
Es ilyenkor a /var/www/ alatti osszes alkonyvtar log konyvtaraban az osszes filet rotalja.
Hogyan lehet ugyanezt megoldani tripwire policyban? (* nem mukodik :)

# tripwire -m c
Parsing policy file: /etc/tripwire/tw.pol
*** Processing Unix File System ***
Performing integrity check...
### Warning: File system error.
### Filename: /var/www/sites/*/etc
### No such file or directory
### Continuing...
### Warning: File system error.
### Filename: /var/www/sites/*/cgi-bin
### No such file or directory
### Continuing...

Sziasztok! Nemrég készítettem mentést egy Ubuntu 8.04.4 LTS rendszerről (a fontosabb könyvtárakat egy még évekkel ezelőtt készített szkripttel bepakoltam egy tar.gz-be), aztán leszedtem a gépemre, ahonnan archiválhatom. De gondoltam, előtte mégiscsak kicsomagolom, és átnézem, van-e benne olyan, amit felesleges menteni... Aztán kicsomagolás közben szólt az Avira, hogy rootkit rejtőzik a fájlok között:

Az rkhunter és chkrootkit nem talált semmit, ellenben a "rai" könyvtárban van egy pár fájl, amiben román nyelvű szöveg is akad :S Első körben nem jutottam nyomára, mi a franc lehet ez, ha bárki útbaigazít, annak nagyon megköszönöm!

Sziasztok!

A szerver logjait nézegetve a következő iptables logokat találtam benne; 13mp-es időközönként egy-egy 4 és fél órán keresztül:


Dec 9 21:14:29 ... SRC=222.73.227.230 ... LEN=40 TOS=0x00 PREC=0x00 TTL=254 ID=5745 PROTO=TCP SPT=29049 DPT=22 WINDOW=0 RES=0x00 RST URGP=0
...
Dec 10 01:42:04 ... SRC=222.73.227.230 ... LEN=40 TOS=0x00 PREC=0x00 TTL=254 ID=10841 PROTO=TCP SPT=39088 DPT=22 WINDOW=0 RES=0x00 RST URGP=0


A csomagokat az alábbi iptables szabályok dobják el (az INPUT láncon ezek előtt csak a loopback engedélyezése van)


iptables -A INPUT -m state --state INVALID -j LOG --log-prefix "Firewall : DROP Inp.Inv "
iptables -A INPUT -m state --state INVALID -j DROP


Jól feltételezem, hogy ez valamilyen "RST Flood" kísérlet?

Egyik honlapon azt olvastam az RST bitről, hogy: "Egy hoszt összeomlása, vagy más okból összezavart összeköttetés helyreállítására szolgál"

VS