Pe 25 martie am deschis înregistrarea pentru , este un joc pentru pasionații și cunoscătorii sistemului de operare Linux. Câteva statistici: s-au înscris în joc 1117 persoane, dintre care 317 au găsit măcar o cheie, 241 au rezolvat cu succes prima etapă, 123 — a doua și 70 au trecut de a treia etapă. Astăzi, jocul nostru a ajuns la final, iar noi îi felicităm pe câștigători!
- Locul întâi a fost ocupat de Alexandr Teldekov.
Alexandr a spus despre sine că este un administrator tipic. Trăiește în Volgograd, gestionează diferite sisteme Unix-like de aproximativ douăzeci de ani. A reușit să lucreze la furnizori de internet, în bănci, în integratori de sisteme. Acum lucrează de la distanță pentru o mică firmă, ocupându-se de infrastructura cloud pentru un client străin mare. Îi place să citească, să asculte muzică. Despre joc, Alexandr a spus că, în general, i-a plăcut; îi plac astfel de provocări. La un interviu în una dintre companii, s-a ocupat de ceva similar cu Hackerrank, a fost interesant. - Locul al doilea — Roman Suslov.
Roman este din Moscova. Are 37 de ani. Lucrează ca inginer Linux/Unix la compania "InfoSystems Jet". La lucru se ocupă cu administrarea și depanarea sistemelor Linux/Unix + SAN. Interesele lui sunt variate: sisteme Linux, programare, inginerie inversă, securitate informațională, Arduino. Despre joc, Roman a menționat că, în general, i-a plăcut. „M-am antrenat puțin mental și m-am distrat de la rutina zilnică. 🙂 Mi-ar plăcea să fie mai multe sarcini, deoarece nu am reușit să intru în ritm înainte să se termine jocul.” - Locul al treilea — alex3d.
Alex trăiește în Moscova, se ocupă cu dezvoltarea de software. „Mulțumesc pentru concurs, a fost interesant să-mi testez abilitățile de căutare.”
De asemenea, în clasamentul celor mai buni 10 jucători:
- Yevgeniy Saldayev
- Markel Mochnachevskiy
- Konstantin Konosov
- Pavel Sergeev
- Vladimir Bovaev
- Ivan Bubnov
- Pavlo Klets
Înțelegem că există multe variante de soluționare pentru toate sarcinile noastre; mai jos sunt descrise unele dintre posibilele soluții.
1. Prima etapă
Am numit-o "Ești sigur că ești admin?", deoarece sarcina a fost destul de simplă — să repare un serviciu călduros și prietenos.
1.1. Fapte interesante:
Doi jucători au găsit prima cheie în primele 15 minute ale jocului, iar în prima oră au apărut trei lideri care au rezolvat sarcina.
1.2. Sarcina
Ai început să lucrezi într-o companie unde nu a existat un specialist calificat în tehnologia informației pentru o perioadă îndelungată. Înainte de a începe să pui totul în ordine, trebuie să rezolvi o problemă urgentă care blochează activitatea biroului.
Îngrijitoarea a agățat cablul de alimentare al serverului cu mopul. Alimentarea a fost restabilită, dar un site web foarte important tot nu funcționează. Site-ul este important pentru că compania nu este foarte preocupată de securitatea informației, iar pe pagina principală se găsește în mod deschis parola de administrator pentru computerul directorului general.
Recent, parola a fost schimbată, iar noua a fost uitată, directorul nu mai poate lucra. Se zvonește că pe această mașină erau și chei care ne-ar putea ajuta la decriptarea backup-ului documentelor contabile.
Toată lumea așteaptă o soluție operativă!
1.3. Soluția
1. În primul rând, trebuie să schimbăm parola root pe mașina virtuală pentru a obține acces la ea. La pornire, observăm că este Ubuntu 16.04 Server.
Pentru a reseta parola root, repornim mașina, iar în momentul afișării meniului grub, intrăm în editarea opțiunii Ubuntu apăsând tasta „e”. Edităm linia linux, adăugând la sfârșit init=/bin/bash. Încărcăm cu Ctrl+x, obținând shell-ul. Ne rimontăm rădăcina cu rw, schimbăm parola:
$ mount -o remount,rw /dev/mapper/ubuntu--vg-root
$ passwdNu uita de sync, repornim.
2. În condiții se spune că serverul web nu funcționează, să vedem:
$ curl localhost
Not Found
The requested URL / was not found on this server.
Apache/2.4.18 Deci, de fapt, Apache este pornit, dar răspunde cu codul 404. Să ne uităm la configurație:
$ vim /etc/apache2/sites-enabled/000-default.confAici se află cheia — StevenPaulSteveJobs.
Verificăm calea /usr/share/WordPress — aceasta nu există, dar există /usr/share/wordpress. Corectăm configurația și repornim Apache.
$ systemctl restart apache23. Încercăm din nou, primim eroarea:
Warning: mysqli_real_connect(): (HY000/2002): Connection refused in /usr/share/wordpress/wp-includes/wp-db.php on line 1488BD nu este pornită?
$ systemctl status mysql
Active: active (running) Ce s-a întâmplat? Trebuie să investigăm. Pentru aceasta, trebuie să obținem acces la MySQL, așa cum este descris în . Unul dintre punctele din documentație ne recomandă să specificăm opțiunea skip-grant-tables în /etc/mysql/mysql.conf.d/mysqld.cnf. Aici se găsește și cheia — AugustaAdaKingByron.
Corectăm permisiile utilizatorului 'wp'@'localhost'. Pornim MySQL, facem să fie accesibil în rețea, comentând în configurație opțiunea skip-networking.
4. După acțiunile efectuate, serverul web pornește, dar site-ul tot nu funcționează, deoarece
Avertizare: require_once(/usr/share/wordpress/wp-content/themes/twentysixteen/footer.php): nu s-a putut deschide fluxul: Permisiune refuzată în /usr/share/wordpress/wp-includes/template.php la linia 562Corectăm permisiunile fișierului.
$ chmod 644 /usr/share/wordpress/wp-content/themes/twentysixteen/footer.php
Reîmprospătăm pagina, intrăm pe site și găsim cheia - BjarneStroustrup! Am găsit toate cele trei chei, directorul nostru poate lucra, am decriptat fișierele contabile. Toată lumea este fericită, iar tu ai mult de lucru pentru a organiza infrastructura, backup-urile și securitatea companiei.
2. A doua etapă
Trebuia să rezolvăm o problemă legată de colectarea analiticii. Toată lumea iubește analitica - cine și de unde și în ce cantități vin. Am inventat un caz, dar cu care se pot confrunta toți inginerii în viață.
2.1. Fapte interesante
Unul dintre jucătorii noștri a introdus cheia corectă în primele 10 minute de joc, iar în prima oră am avut un lider care a rezolvat sarcina.
2.2. Sarcina
Ai început lucrul în companie, managerii au venit la tine și te-au rugat să găsești cui au fost trimise e-mailurile din Africa. Trebuie să construiești un top 21 de adrese ale destinatarilor. Primele litere ale adreselor destinatarilor sunt cheia. O problemă: serverul de e-mail prin care au fost trimise mesajele nu se încarcă. Toată lumea așteaptă o soluție rapidă!
2.3. Soluția
1. Serverul nu se încarcă din cauza unei sectiuni swap inexistente în fstab, atunci când sistemul pornește, încearcă să o monteze și cedează. Cum putem porni?
Descarcă imaginea, am descărcat CentOS 7, pornim de pe Live CD/DVD (Troubleshooting -> Rescue), montăm sistemul, corectăm /etc/fstab. Aici găsim prima cheie - GottfriedWilhelm11646Leibniz!
Creăm swap:
$ lvcreate -n swap centos -L 256M
$ sync && reboot2. Ca de obicei, nu există parolă, trebuie să schimbăm parola root pe mașina virtuală. Am făcut deja asta în prima sarcină. Schimbăm și intrăm cu succes pe server, dar acesta se repornește imediat. Serverul se repornește atât de repede încât nu reușim să verificăm toate jurnalele cu atenție. Cum putem înțelege ce se întâmplă?
Din nou pornim de pe livecd, studiem cu atenție jurnalele sistemului și, pentru fiecare eventualitate, ne uităm și în cron, având în vedere această periodicitate. Acolo găsim problema și a doua cheie - Alan1912MathisonTuring!
Trebuie să /etc/crontab ștergem sau să comentăm linia echo b > /proc/sysrq-trigger.
3. După ce serverul s-a încărcat, putem îndeplini sarcina managerilor: „Care sunt adresele Africii?” Această informație este, în general, accesibilă publicului. Opoți găsi aceste informații pe internet căutând expresiile „ip address africa”, „geoip database”. Pentru rezolvarea sarcinii, se pot folosi baze de date de distribuție a adreselor disponibile liber (geoip). Noi am folosit ca standard o bază de date. , disponibilă sub licența Creative Commons Attribution-ShareAlike 4.0.
Vom încerca să rezolvăm sarcina noastră folosind doar utilitarele de sistem Linux, dar, în general, poate fi abordată în multe moduri: folosind utilitare de filtrare a textului și scripturi în diferite limbaje de programare.
Pentru început, să obținem pur și simplu perechile „IP-expeditor – destinatar” din jurnalul poștal. /var/log/maillog (vom construi un tabel cu destinatarii de email – IP-ul expeditorului). Acest lucru se poate face cu următoarea comandă:
$ cat /var/log/maillog | fgrep -e ' connect from' -e 'status=sent' | sed 's/[]//g' | awk '/connect from/ {ip=$11} /status=sent/ {print $10" "ip}' > log1.txtȘi înainte de a continua cu compunerea bazei de date a adreselor Africii, să aruncăm o privire asupra celor mai frecvente IP-uri ale expeditorilor.
$ cat log1.txt | cut -d' ' -f1 | sort | uniq -c | sort -r | head -n 40
5206 L2JhbjAbM67GA99jg@mail.ru
4165 iHKTBkegOQa6fIALq@mail.ru
3739 nHkcBl7BdgXxijSYD7@mail.ru
3405 SMAzPJAzbl9vp4hAXo@mail.ru
3346 xILz6d7P@mail.ru
Dintre toate, se evidențiază prin numărul de mesaje cele trei primii destinatari din top. Dacă verificăm IP-urile expeditorilor care au trimis pe adresele din acest top-3, putem observa o predominanță clară a anumitor rețele:
$ cat log1.txt | fgrep 'L2JhbjAbM67GA99jg@mail.ru' | cut -d' ' -f2 | sort | cut -d'.' -f1 | uniq -c | sort -r | head
831 105
806 41
782 197
664 196
542 154
503 102
266 156
165 45
150 160
108 165Majoritatea rețelelor 105/8, 41/8, 196/8, 197/8 sunt alocate de AFRINIC — unul dintre cei cinci registratori locali de internet care efectuează distribuția resurselor de internet. AFRINIC alocă spațiul de adrese în regiunea Africii. Iar 41/8 aparține în întregime de AFRINIC.
https://www.nic.ru/whois/?searchWord=105.0.0.0
https://www.nic.ru/whois/?searchWord=41.0.0.0
Astfel, răspunsul la întrebare se află, de fapt, în jurnalul în sine.
$ cat log1.txt | fgrep -e '105.' -e '41.' -e '196.' -e '197.' -e '154.' -e '102.' | awk '{print $1}' | sort | uniq -c | sort -r | head -n 21
4209 L2JhbjAbM67GA99jg@mail.ru
3313 iHKTBkegOQa6fIALq@mail.ru
2704 nHkcBl7BdgXxijSYD7@mail.ru
2215 uvRbp1O@mail.ru
1774 sPmMsmmFiV@mail.ru
1448 BtG3aHgQgCKuze2AKuRH@mail.ru
1233 eQpuuQ2uQdbwRL3@mail.ru
958 nJT5dpaBZ@mail.ru
862 ef4WbQiB@mail.ru
762 dQCqKL6eVminFfH7wLA@mail.ru
632 ifq6Rd1HxuCQOdO9@mail.ru
539 cFwm2ssypMmx1sA7@mail.ru
531 twtTnr4G@mail.ru
431 TSrczgYASrR11Hs3qCi@mail.ru
380 o3r3exc3OL@mail.ru
357 rzmjr2VAHK@mail.ru
348 vnPr6YjJ3ndw@mail.ru
312 anOjFXrwOtLP2Rl1Vcz6@mail.ru
289 dvny5zHmRW8fiT@mail.ru
282 sgg9jPxFDYvzw8Kr@mail.ru
274 tKSevzA7GntJ@mail.ruÎn această etapă, obținem șirul „LinuxBenedictTorvadst”.
Cheia corectă: „LinusBenedictTorvalds”.
Șirul obținut conține o greșeală în raport cu cheia corectă în ultimele 3 caractere. Acest lucru se datorează faptului că rețelele alese de noi nu sunt complet dedicate țărilor din Africa și modului în care sunt distribuite adresele de email pe IP-urile din logurile noastre.
Prin clarificarea rețelelor mai mari, dedicate țărilor din Africa, putem obține un răspuns precis:
$ cat log1.txt | fgrep -e' '105.{30..255}. -e' '41. -e' '196.{64..47}. -e' '196.{248..132}. -e' '197.{160..31}. -e' '154.{127..255}. -e' '102.{70..255}. -e' '156.{155..255}. | awk '{print $1}' | sort | uniq -c | sort -r | head -n 21
3350 L2JhbjAbM67GA99jg@mail.ru
2662 iHKTBkegOQa6fIALq@mail.ru
2105 nHkcBl7BdgXxijSYD7@mail.ru
1724 uvRbp1O@mail.ru
1376 sPmMsmmFiV@mail.ru
1092 BtG3aHgQgCKuze2AKuRH@mail.ru
849 eQpuuQ2uQdbwRL3@mail.ru
712 nJT5dpaBZ@mail.ru
584 ef4WbQiB@mail.ru
463 dQCqKL6eVminFfH7wLA@mail.ru
365 ifq6Rd1HxuCQOdO9@mail.ru
269 cFwm2ssypMmx1sA7@mail.ru
225 twtTnr4G@mail.ru
168 TSrczgYASrR11Hs3qCi@mail.ru
142 o3r3exc3OL@mail.ru
111 rzmjr2VAHK@mail.ru
96 vnPr6YjJ3ndw@mail.ru
78 anOjFXrwOtLP2Rl1Vcz6@mail.ru
56 lHzWiB7ExvRtSbAcU9@mail.ru
56 dvny5zHmRW8fiT@mail.ru
40 sgg9jPxFDYvzw8Kr@mail.ru Problema poate fi soluționată și prin altă metodă.
Descărcăm MaxMind, dezarhivăm și următoarele trei comenzi rezolvă de asemenea problema noastră.
$ cat GeoLite2-Country-Locations-ru.csv | grep "Africa" | cut -d',' -f1 > africaIds.txt
$ grep -Ff africaIds.txt GeoLite2-Country-Blocks-IPv4.csv | cut -d',' -f1 > africaNetworks.txt
$ grepcidr -f africaNetworks.txt log1.txt | cut -d' ' -f1 | sort | uniq -c | sort -r | head -n21
Într-un fel sau altul, am calculat în final statisticile, iar managerii au obținut datele necesare pentru muncă!
3. Etapa a treia
Etapa a treia este oarecum similară cu prima — trebuie să reparăm din nou serviciul cald și confortabil, dar totul este mai complicat decât în prima sarcină.
3.1. Fapte interesante
În primele 15 minute, trei jucători au găsit prima cheie, iar după 2 ore și 20 de minute de la începutul etapei, câștigătorul nostru a rezolvat sarcina.
3.2. Sarcina
Ai început lucrul la o companie unde toate documentele companiei sunt stocate pe un server intern Wiki. Anul trecut, un inginer a comandat 3 discuri noi pentru server, pe lângă unul existent, argumentând că pentru redundanța sistemului trebuie să fie instalate discuri în unele matrice. Din păcate, după câteva săptămâni de la instalare, inginerul a plecat în vacanță în India și nu s-a mai întors.
Câțiva ani serverul a funcționat fără probleme, dar acum câteva zile rețeaua companiei a fost spartă. Conform instrucțiunilor, angajații de securitate au scos discurile din server și ți le-au trimis. În timpul transportului, un disc a fost pierdut irevocabil.
Este necesar să restabilim funcționalitatea Wiki, în primul rând, ne interesează conținutul paginilor wiki. O bucată de text care era pe una dintre paginile acestei wiki este parola pentru serverul 1C și este urgent necesară pentru deblocarea acestuia.
În plus, undeva pe paginile wiki sau în alt loc se aflau parolele pentru serverul de log-uri și serverul de supraveghere video, care, de asemenea, trebuie restabilite, fără ele, investigarea incidentului este imposibilă. Așa cum este întotdeauna, așteptăm o soluție operativă la această problemă!
3.3. Soluție
1. Încercăm să ne încărcăm pe rând de pe acele discuri pe care le avem și începem să primim același mesaj:
No bootable medium found! System halted
Trebuie să ne încărcăm de undeva. Din nou, ne ajută încărcarea cu Live CD/DVD (Troubleshooting -> Rescue). La încărcare, încercăm să găsim partiția de boot, nu o găsim, ajungem în shell. Încercăm să ne uităm ce și cum cu discurile. Se știe că sunt trei. Instrumentele pentru asta sunt mai multe în versiunea 7 a CentOS, unde sunt comenzi blkid sau lsblk, care ne arată toate informațiile despre discuri.
Ce și cum facem:
$ ls /dev/sd*Se vede imediat că
/dev/sdb1 - ext4
/dev/sdb2 - часть lvm
/dev/sda1 и /dev/sdc1 - части рейда
/dev/sda2 и /dev/sdc2 - про них ничего не известно на текущий моментMontăm sdb1, și se vede că aceasta este partiția de boot CentOS 6.
$ mkdir /mnt/sdb1 && mount /dev/sdb1 /mnt/sdb1Este evident că mergem în secțiunea grub și găsim prima cheie – James191955Gosling într-un fișier neobișnuit.
2. Studiam pvs și lvs, deoarece lucrăm cu LVM. Vedem că ar trebui să fie 2 volume fizice, unul nu este găsit și semnalează uid-ul pierdut. Vedem că ar trebui să fie 2 volume logice: root și swap, iar root este parțial pierdut (atribut P la volum). Nu se poate monta, ceea ce este păcat! Ne este foarte necesar.
Mai sunt încă 2 discuri, ne uităm la ele, le adunăm și le montăm:
$ mdadm --examine --verbose --scan
$ mdadm --assemble --verbose --scan
$ mkdir /mnt/md127 && mount /dev/md127 /mnt/md127 Ne uităm, se vede că aceasta este partiția de boot CentOS 6 și un duplicat al a ceea ce există deja pe /dev/sdb1, și aici din nou aceeași cheie – DennisBMacAlistairCRitchie!
Ne uităm cum a fost adunat /dev/md127.
$ mdadm --detail /dev/md127
Vedem că ar fi trebuit să fie adunat din 4 discuri, s-a adunat din două /dev/sda1 și /dev/sdc1, acestea ar fi trebuit să fie numerele 2 și 4 în sistem. Presupunem că. /dev/sda2 și /dev/sdc2 se poate aduna și din acestora. Nu este clar de ce nu au metadata, dar aceasta este problema adminului, care este undeva în Goa. Presupunem că ar trebui să fie RAID10, deși există variante. Adunăm:
$ mdadm --create --verbose /dev/md0 --assume-clean --level=10 --raid-devices=4 missing /dev/sda2 missing /dev/sdc2
Ne uităm la blkid, pvs, lvs. Descoperim că am adunat volumul fizic de care ne lipsea anterior.
Imediat reparăm lvroot, montăm-l, dar mai întâi activăm VG-ul:
$ vgchange -a y
$ mkdir /mnt/lvroot && mount /dev/mapper/vg_c6m1-lv_root /mnt/lvroot
Și acolo este totul, inclusiv cheia în directorul home al root-ului — /root/sweet.
3. Încercăm totuși să readucem serverul la viață, astfel încât să pornească normal. Toate volumele logice de pe /dev/md0 (unde am găsit tot) le mutăm în /dev/sdb2, unde serverul a funcționat inițial.
$ pvmove /dev/md0 /dev/sdb2
$ vgreduce vg_c6m1 /dev/md0Oprim serverul, scoatem disk-urile 1 și 3, lăsăm pe cel de-al doilea, boot-ăm de pe Live CD/DVD în Rescue. Găsim partiția de boot, restaurăm bootloader-ul în grub:
root (hd0,0)
setup (hd0)
Scoatem discul de boot și ne boot-ăm cu succes, dar site-ul nu funcționează.
4. Există două variante pentru a porni site-ul: să configurăm de la zero Apache sau să folosim nginx deja configurat cu php-fpm:
$ /etc/init.d/nginx start
$ /etc/init.d/php-fpm start
În cele din urmă, trebuie să pornim MySQL:
$ /etc/init.d/mysqld start Nu pornește și soluția se află în /var/log/mysql. Odată ce rezolvați problema cu MySQL, site-ul va funcționa, iar pe pagina principală va fi cheia — RichardGCCMatthewGNUStallman! Acum avem acces în 1C, iar angajații vor putea primi salariile. Și tu ai din nou multă muncă de făcut pentru a organiza infrastructura și securitatea companiei.
De asemenea, putem împărtăși din nou lista cărților care ne-au ajutat pe noi și pe participanții noștri să se pregătească pentru joc: .
Mulțumim că ați fost alături de noi! Rămâneți la curent cu anunțurile jocurilor viitoare!
Sursa: habr.com
