25 marca otworzyliśmy rejestrację na , to gra dla miłośników i znawców systemu operacyjnego Linux. Trochę statystyk: zarejestrowało się 1117 osób, z czego 317 znalazło przynajmniej jeden klucz, 241 pomyślnie poradziło sobie z zadaniem pierwszego etapu, 123 z drugiego, a 70 przeszło trzeci etap. Dziś nasza gra dobiegła końca, gratulujemy zwycięzcom!
- Pierwsze miejsce zajął Aleksander Tieldiekow.
Aleksander powiedział o sobie, że jest typowym adminem. Mieszka w Wołgogradzie, od dwudziestu lat administruje różnymi systemami Unix-like. Pracował w dostawcach internetu, banku, integratorze systemowym. Teraz pracuje zdalnie w małej firmie, zajmuje się infrastrukturą chmurową dla dużego zagranicznego klienta. Lubi czytać, słuchać muzyki. O grze Aleksander powiedział, że bardzo mu się podobała, lubi takie zadania. W jednej z firm na rozmowie kwalifikacyjnej zajmował się czymś podobnym do Hackerrank, to było ciekawe. - Drugie miejsce – Roman Susłow.
Roman z Moskwy. Ma 37 lat. Pracuje jako inżynier Linux/Unix w firmie 'Infostemy Jet'. W pracy zajmuje się administracją i rozwiązywaniem problemów systemów Linux/Unix + SAN. Interesuje się różnymi dziedzinami: systemami Linux, programowaniem, inżynierią odwrotną, bezpieczeństwem informacji, Arduino. O grze Roman zauważył, że w sumie mu się podobała. "Trochę rozruszałem swoje szare komórki i oderwałem się od szarych dni codziennej pracy. 🙂 Chciałbym, żeby było więcej zadań, bo nie zdążyłem się wkręcić, a gra już się skończyła." - Trzecie – alex3d.
Alek mieszka w Moskwie, zajmuje się rozwijaniem oprogramowania. "Dzięki za konkurs, było interesująco sprawdzić swoje umiejętności w google-fu."
A oto również w rankingu 10 najlepszych graczy:
- Yevgeniy Saldayev
- Markel Mochnaczewski
- Konstantin Konoza
- Paweł Sergejew
- Włodzimierz Bowajew
- Iwan Bubnow
- Pavlo Klets
Rozumiemy, że istnieje wiele sposobów rozwiązania naszych zadań, poniżej opisano niektóre z możliwych rozwiązań.
1. Pierwszy etap
Nazwaliśmy go „A Ty naprawdę jesteś adminem?”, ponieważ zadanie było dość proste – naprawić ciepły, lampowy serwis.
1.1. Ciekawe fakty:
Dwóch graczy znalazło pierwszy klucz w ciągu pierwszych 15 minut gry, a w pierwszej godzinie mieliśmy trzech liderów, którzy poradzili sobie z zadaniem.
1.2. Zadanie
Zacząłeś pracę w firmie, w której przez długi czas brakowało kompetentnego specjalisty ds. technologii informacyjnej. Zanim zaczniesz wprowadzać porządek, musisz rozwiązać pilny problem, który blokuje pracę biura.
Sprzątaczka zaczepiła mopem kabel zasilający serwerowni. Zasilanie zostało przywrócone, ale bardzo ważna strona internetowa wciąż nie działa. Strona jest ważna, ponieważ firma nie przywiązuje zbyt dużej wagi do bezpieczeństwa informatycznego, a na stronie głównej można w otwarty sposób znaleźć hasło administratora komputera dyrektora.
Ostatnio hasło zostało zmienione, a nowego wszyscy zapomnieli, dyrektor nie może pracować. Krążą plotki, że na tej maszynie były jeszcze klucze, które mogą pomóc nam w odszyfrowaniu kopii zapasowej dokumentów księgowych.
Wszyscy czekają na szybkie rozwiązanie problemu!
1.3. Rozwiązanie
1. Najpierw musisz zmienić hasło roota na maszynie wirtualnej, aby uzyskać do niej dostęp. Po uruchomieniu zauważamy, że to Ubuntu 16.04 Server.
Aby zresetować hasło roota, restartujemy maszynę, w momencie wyświetlania menu grub-a, przechodzimy do edytowania pozycji Ubuntu naciskając przycisk „e”. Edytujemy linię linux, dodając na końcu init=/bin/bash. Bootujemy przez Ctrl+x, uzyskujemy bash. Przemontowujemy root z rw, zmieniamy hasło:
$ mount -o remount,rw /dev/mapper/ubuntu--vg-root
$ passwdNie zapominamy o sync, restartujemy.
2. W warunkach jest napisane, że nasz serwer www nie działa, sprawdzamy:
$ curl localhost
Not Found
The requested URL / was not found on this server.
Apache/2.4.18 To znaczy, że rzeczywiście Apache działa, ale odpowiada kodem 404. Sprawdzamy konfigurację:
$ vim /etc/apache2/sites-enabled/000-default.confTutaj znajduje się klucz — StevenPaulSteveJobs.
Sprawdzamy ścieżkę /usr/share/WordPress — takiej nie ma, ale jest /usr/share/wordpress. Poprawiamy konfigurację i restartujemy Apacha.
$ systemctl restart apache23. Próbujemy ponownie, otrzymujemy błąd:
Warning: mysqli_real_connect(): (HY000/2002): Connection refused in /usr/share/wordpress/wp-includes/wp-db.php on line 1488Baza danych nie działa?
$ systemctl status mysql
Active: active (running) W czym zatem problem? Musimy przeanalizować. W tym celu musimy uzyskać dostęp do MySQL, jak to zrobić opisano w . Jeden z punktów dokumentacji zaleca nam dodanie opcji skip-grant-tables do /etc/mysql/mysql.conf.d/mysqld.cnf. Tutaj też znajduje się klucz — AugustaAdaKingByron.
Poprawiamy prawa dla użytkownika 'wp'@'localhost'. Uruchamiamy MySQL, udostępniamy go w sieci, komentując w konfiguracji opcję skip-networking.
4. Po wykonaniu tych działań serwer www uruchamia się, ale strona wciąż nie działa, ponieważ
Uwaga: require_once( /usr/share/wordpress/wp-content/themes/twentysixteen/footer.php): nie udało się otworzyć strumienia: Odrzucono uprawnienia w /usr/share/wordpress/wp-includes/template.php w linii 562Ustawiamy prawa do pliku.
$ chmod 644 /usr/share/wordpress/wp-content/themes/twentysixteen/footer.php
Odświeżamy stronę, wchodzimy na stronę i znajdujemy klucz — BjarneStroustrup! Znaleźliśmy wszystkie trzy klucze, nasz dyrektor może pracować, odszyfrowaliśmy pliki księgowości. Wszyscy są szczęśliwi, a czeka cię wiele pracy nad infrastrukturą, backupami i bezpieczeństwem w firmie.
2. Drugi etap
Należało rozwiązać zadanie dotyczące zbierania analityki. Analitykę wszyscy lubią — kto i skąd oraz w jakich ilościach wchodzą. Wymyśliliśmy przypadek, z którym w taki czy inny sposób mogą się spotkać wszyscy inżynierowie w życiu.
2.1. Ciekawe fakty
Jeden z naszych graczy wprowadził prawidłowy klucz w ciągu pierwszych 10 minut gry, a w ciągu pierwszej godziny mieliśmy lidera, który poradził sobie z zadaniem.
2.2. Zadanie
Rozpocząłeś pracę w firmie, przyszedł do ciebie menedżerowie i poprosili o znalezienie, do kogo były wysyłane wiadomości z Afryki. Należy stworzyć top-21 adresów odbiorców na ich podstawie. Pierwsze litery adresów odbiorców — klucz. Jedno ale: serwer pocztowy, przez który wiadomości były wysyłane, nie ładuje się. Wszyscy czekają na szybkie rozwiązanie problemu!
2.3. Rozwiązanie
1. Serwer się nie ładuje z powodu nieistniejącej partycji swap w fstab, podczas uruchamiania system próbuje ją zamontować i się zawiesza. Jak się uruchomić?
Pobieramy obraz, ściągnęliśmy CentOS 7, uruchamiamy z Live CD/DVD (Rozwiązywanie problemów -> Rescue), montujemy system, dokonujemy zmian /etc/fstab. Od razu znajdujemy pierwszy klucz — GottfriedWilhelm11646Leibniz!
Tworzymy swap:
$ lvcreate -n swap centos -L 256M
$ sync && reboot2. Jak to zawsze bywa, hasła brak, trzeba zmienić hasło root na maszynie wirtualnej. Już to robiliśmy w pierwszym zadaniu. Zmieniamy i udaje nam się wejść na serwer, ale on natychmiast się restartuje. Serwer restaruje się tak szybko, że nie mamy nawet czasu na dokładne przeglądanie logów. Jak zrozumieć, co się dzieje?
Znów uruchamiamy się z livecd, dokładnie przeglądamy logi systemowe i na wszelki wypadek zaglądamy do crona, taka regularność. Tam znajdujemy problem i drugi klucz — Alan1912MathisonTuring!
Musimy w /etc/crontab usunąć lub skomentować linię echo b > /proc/sysrq-trigger.
3. Po tym, jak serwer się załadował, można wykonać zadanie menedżerów: „Jakie są adresy Afryki?” Te informacje są w zasadzie ogólnie dostępne. Można je znaleźć w internecie, używając fraz „adres IP Afryki”, „baza danych geoip”. Do rozwiązania tego zadania można użyć ogólnie dostępnych baz rozkładu adresów (geoip). Jako wzór wykorzystaliśmy bazę danych , dostępną na licencji Creative Commons Attribution-ShareAlike 4.0.
Spróbujemy rozwiązać nasze zadanie, używając tylko systemowych narzędzi Linux, choć w rzeczywistości można je rozwiązać na wiele sposobów: przy użyciu narzędzi do filtrowania tekstu oraz skryptów w różnych językach programowania.
Na początek po prostu uzyskamy pary „IP-nadawcy — odbiorca” z logu pocztowego /var/log/maillog (stwórzmy tabelę odbiorców e-maili — IP nadawcy). Można to zrobić następującą komendą:
$ 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.txtI zanim przejdziemy do tworzenia bazy danych adresów Afryki, przyjrzyjmy się najpopularniejszym adresom IP nadawców.
$ 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
Wśród wszystkich wyraźnie wyróżniają się swoimi liczbami trzy pierwsze adresy z czołówki. Jeśli użyjemy grep na adresach IP nadawców, którzy wysyłali wiadomości do adresów z tej czołówki 3, zauważymy wyraźne przeważenie określonych sieci:
$ 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 165Większość sieci 105/8, 41/8, 196/8, 197/8 jest zarządzana przez AFRINIC — jednego z pięciu regionalnych rejestratorów internetowych, które zajmują się przydzielaniem zasobów internetowych. AFRINIC przydziela przestrzeń adresową na terenie Afryki. A 41/8 całkowicie należy do AFRINIC.
https://www.nic.ru/whois/?searchWord=105.0.0.0
https://www.nic.ru/whois/?searchWord=41.0.0.0
W ten sposób odpowiedź na zadanie znajduje się w samym logu.
$ 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.ruNa tym etapie otrzymujemy ciąg „LinuxBenedictTorvadst”.
Poprawny klucz: „LinusBenedictTorvalds”.
Otrzymany ciąg zawiera błąd w porównaniu do poprawnego klucza w 3 ostatnich znakach. Jest to spowodowane tym, że wybrane przez nas sieci nie są w pełni przypisane do krajów Afryki oraz tym, jak są rozdzielane e-maile po adresach IP w naszym logu.
Przy wystarczającym doprecyzowaniu największych sieci przypisanych krajom Afryki można uzyskać dokładną odpowiedź.:
$ 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 Zadanie można również rozwiązać w inny sposób.
Pobieramy MaxMind, rozpakowujemy, a następnie trzy kolejne komendy również rozwiązują nasze zadanie.
$ cat GeoLite2-Country-Locations-ru.csv | grep "Afryka" | 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
W ten lub inny sposób ostatecznie policzyliśmy statystyki, a menedżerowie otrzymali niezbędne dane do pracy!
3. Trzeci etap
Trzeci etap jest w pewnym sensie podobny do pierwszego — również musimy naprawić ciepły, lampowy serwis, ale wszystko jest trudniejsze niż w pierwszym zadaniu.
3.1. Interesujące fakty
W ciągu pierwszych 15 minut trzech graczy znalazło pierwszy klucz, a po 2 godzinach i 20 minutach od rozpoczęcia etapu nasz zwycięzca poradził sobie z zadaniem.
3.2. Zadanie
Zacząłeś pracę w firmie, w której wszystkie dokumenty są przechowywane na wewnętrznym serwerze Wiki. W zeszłym roku inżynier zamówił 3 nowe dyski do serwera, oprócz jednego istniejącego, argumentując to tym, że dla niezawodności systemu należy umieszczać dyski w pewnych macierzach. Niestety, kilka tygodni po ich instalacji inżynier pojechał na wakacje do Indii i nie wrócił.
Przez kilka lat serwer działał bez awarii, ale kilka dni temu sieć firmy została zhakowana. Zgodnie z instrukcjami, pracownicy ochrony wyjęli dyski z serwera i wysłali je do Ciebie. W trakcie transportu jeden z dysków został bezpowrotnie utracony.
Należy przywrócić funkcjonalność Wiki, przede wszystkim interesuje mnie zawartość stron wiki. Pewien fragment tekstu, który znajdował się na jednej ze stron tej wiki, jest hasłem do serwera 1C i pilnie potrzebuje go do odblokowania.
Dodatkowo, gdzieś na stronach wiki lub w innym miejscu były hasła do serwera logów i serwera monitoringu, które również warto odzyskać, ponieważ bez nich badanie incydentu jest niemożliwe. Zawsze oczekują szybkiego rozwiązania problemu!
3.3. Rozwiązanie
1. Staramy się uruchomić system z tych dysków, które mamy, i wszędzie otrzymujemy ten sam komunikat:
Nie znaleziono bootowalnego medium! System wstrzymany
Musimy z czegoś wystartować. Znowu ratuje nas uruchamianie z Live CD/DVD (Rozwiązywanie problemów -> Ratunek). Podczas uruchamiania próbujemy znaleźć partycję rozruchową, nie znajdujemy, trafiamy na shell. Próbujemy zbadać, co i jak z dyskami. Wiadomo, że jest ich trzy. Więcej narzędzi do tego jest w 7. wersji CentOS, gdzie są polecenia blkid lub lsblk, które pokazują nam wszystkie informacje o dyskach.
Jak i co robimy:
$ ls /dev/sd*Od razu widać, że
/dev/sdb1 - ext4
/dev/sdb2 - часть lvm
/dev/sda1 и /dev/sdc1 - части рейда
/dev/sda2 и /dev/sdc2 - про них ничего не известно на текущий моментMontujemy sdb1, widać, że to partycja rozruchowa CentOS 6.
$ mkdir /mnt/sdb1 && mount /dev/sdb1 /mnt/sdb1Oczywiście idziemy do sekcji grub i znajdujemy tam pierwszy klucz — James191955Gosling w nietypowym pliku.
2. Badamy pvs i lvs, ponieważ pracujemy z LVM. Widzimy, że powinny być 2 fizyczne wolumeny, jeden nie jest znaleziony i zgłasza utracony uid. Widzimy, że powinny być 2 logiczne wolumeny: root i swap, przy tym root częściowo utracony (atrybut P u wolumenu). Nie można go zamontować, co szkoda! Bardzo go potrzebujemy.
Są jeszcze 2 dyski, przyglądamy się nim, zbieramy i montujemy:
$ mdadm --examine --verbose --scan
$ mdadm --assemble --verbose --scan
$ mkdir /mnt/md127 && mount /dev/md127 /mnt/md127 Sprawdzamy, widać, że to partycja rozruchowa CentOS 6 i duplikat tego, co już jest na /dev/sdb1, i tu znowu ten sam klucz — DennisBMacAlistairCRitchie!
Sprawdzamy, jak jest złożony /dev/md127.
$ mdadm --detail /dev/md127
Widzimy, że powinien być złożony z 4 dysków, złożony został z dwóch /dev/sda1 i /dev/sdc1, powinny być one numerami 2 i 4 w systemie. Zakładamy, że z /dev/sda2 i /dev/sdc2 można również zbudować macierz. Niejasne, dlaczego nie ma na nich metadanych, ale to na sumieniu administratora, który gdzieś na Goa. Zakładamy, że powinien być RAID10, chociaż są różne opcje. Montujemy:
$ mdadm --create --verbose /dev/md0 --assume-clean --level=10 --raid-devices=4 missing /dev/sda2 missing /dev/sdc2
Sprawdzamy blkid, pvs, lvs. Odkrywamy, że zbudowaliśmy fizyczny wolumen, którego wcześniej nam brakowało.
Natychmiast naprawiamy lvroot, montujemy go, ale najpierw aktywujemy VG:
$ vgchange -a y
$ mkdir /mnt/lvroot && mount /dev/mapper/vg_c6m1-lv_root /mnt/lvroot
I wszystko tam jest, w tym klucz w katalogu domowym root — /root/sweet.
3. Próbujemy jednak przywrócić nasz serwer, aby uruchomił się poprawnie. Wszystkie woluminy logiczne z naszego /dev/md0 (gdzie wszystko się znalazło) przenosimy do /dev/sdb2, gdzie pierwotnie działał cały serwer.
$ pvmove /dev/md0 /dev/sdb2
$ vgreduce vg_c6m1 /dev/md0Zatrzymujemy serwer, usuwamy dyski 1 i 3, zostawiamy drugi, uruchamiamy z Live CD/DVD w trybie Rescue. Znajdujemy partycję rozruchową, przywracamy bootloader w grubie:
root (hd0,0)
setup (hd0)
Wyjmujemy dysk rozruchowy i uruchamiamy system pomyślnie, ale strona nie działa.
4. Są dwa sposoby na uruchomienie strony: skonfigurować Apache od zera lub użyć już wcześniej skonfigurowanego nginx z php-fpm:
$ /etc/init.d/nginx start
$ /etc/init.d/php-fpm start
Na koniec, należy uruchomić MySQL:
$ /etc/init.d/mysqld start Nie uruchamia się, a zagadka tkwi w /var/log/mysql. Gdy tylko rozwiążesz problem z MySQL, strona zacznie działać, a na stronie głównej znajdziesz klucz — RichardGCCMatthewGNUStallman! Teraz mamy dostęp do 1C, a pracownicy będą mogli otrzymać wynagrodzenie. A przed tobą, jak zawsze, dużo pracy nad infrastrukturą i bezpieczeństwem w firmie.
Możemy również jeszcze raz podzielić się listą książek, które pomagały nam i naszym uczestnikom w przygotowaniach do gry: .
Dziękujemy, że byliście z nami! Śledźcie zapowiedzi kolejnych gier!
Źródło: habr.com
