Security FAQ & HowTo by SinusPL --------------------------------- Czemu ja to robie? Chyba dlatego, ze wielu z was zabiera sie za rzeczy, za ktore sie nie pownniscie zabierac, bo nieznacie innych, wazniejszych, podstawowych rzeczy. No ale nicstraconego. Mysle, ze to FAQ odpowie na wasze pytania i stworzy nowe... na te nowe nie bedzie odpowiedzi tutaj. Zacznijmy od dobrze znanego problemu (a moze nie problemu?) jakim jest tzw. "security by obscurity" czyli "bezpieczenstwo przez krecenie". Do typowych przypadkow tego naleza pytania typu "jak zrobic, aby userzy nie widzieli co mam w /etc/" albo "nie chce, aby userzy czytali /etc/passwd i wiedzieli, jacy inni userzy istnieja w systemie". Aby pokazac wam, co sie kiedy i jak dzieje oprocz mojego loginu "sinuspl" stworzylem login "test". Jest to zwykly szary user, bez zadnych specjalnych uprawnien. Jako pierwsze przetestujemy, co siedzieje gdy user test ma dostep do /etc/passwd: [root@mobile root]# ls -al /etc/shadow /etc/passwd /etc/group -rw-r--r-- 1 root root 644 Sep 18 12:12 /etc/group -rw-r--r-- 1 root root 1626 Sep 18 12:12 /etc/passwd -r-------- 1 root root 1170 Sep 18 12:12 /etc/shadow [root@mobile root]# su - test [test@mobile test]$ id uid=503(test) gid=503(test) groups=503(test) [test@mobile test]$ touch test.txt [test@mobile test]$ ls -al test.txt -rw-rw-r-- 1 test test 0 Oct 26 22:02 test.txt [root@mobile root]# Teraz damy mode 600 na /etc/passwd, czyli tylko owner pliku jakim jest root moze go czytac: [root@mobile root]# chmod 600 /etc/passwd /etc/group [root@mobile root]# ls -al /etc/passwd /etc/group -rw------- 1 root root 644 Sep 18 12:12 /etc/group -rw------- 1 root root 1626 Sep 18 12:12 /etc/passwd [root@mobile root]# su - test could not open session [root@mobile root]# Ups? Nie dziala? Czemu? Ano zobaczmy: [root@mobile root]# tail -1 /var/log/messages Oct 26 22:04:06 mobile su[7193]: pam_xauth: error determining target user's UID Jeszcze jeden test, teraz zmienimy prawa dostepu w momencie, gdy user "test" juz jest zalogowany. W jednym okienku: [root@mobile root]# chmod 600 /etc/passwd /etc/group [root@mobile root]# ls -al /etc/passwd /etc/group -rw------- 1 root root 644 Sep 18 12:12 /etc/group -rw------- 1 root root 1626 Sep 18 12:12 /etc/passwd [root@mobile root]# A w drugim, gdzie jest "test": [test@mobile test]$ id uid=503 gid=503 groups=503 [test@mobile test]$ ls -al test.txt -rw-rw-r-- 1 503 503 0 Oct 26 22:02 test.txt [test@mobile test]$ cd /tmp [test@mobile tmp]$ ls -al total 28 drwxrwxrwt 4 0 0 8192 Oct 26 21:46 . drwxr-xr-x 26 0 0 4096 Oct 22 10:59 .. -rw-r--r-- 1 0 0 808 Oct 26 21:46 debug_unrar.txt drwxrwxrwt 2 43 43 4096 Oct 22 11:00 .font-unix -r--r--r-- 1 0 0 11 Oct 22 11:05 .X0-lock drwxrwxrwt 2 0 0 4096 Oct 22 11:05 .X11-unix [test@mobile tmp]$ Gdybysmy zmienili tylko /etc/group na 600, to nie byloby tylko widac nazwy grupy, do ktorej nalezy plik. Jaki moral z naszego eksperymentu? IDIOTYCZNE MYSLI, ZE /ETC/PASSWD I /ETC/GROUP NIE POWINNY MOC BYC CZYTANYMI PRZEZ USEROW SA CHOLERNIE DEBILNE. ZAPOMNIJMY O NICH!!! A wiec zapomnijmy o tych wszystkich glupich modach na te pliki. Nastepny przypadek jest nastepujacy: "Admin" servera nie chce, aby userzy wiedzieli jakiekolwiek pliki w / i w /etc. Co robi taki admin? Albo daje 711 na / i na /etc albo co gorzej 700 na te dwa foldery. Pierwsze prowadzi do tego, ze userzy naprawde nie wiedza co sie tam dzieje, ale gdy znaja nazwe pliku, to i tak moga go przeczytac. Dlatego np. zabierajac prawa odczytu z /home kazdy user moze sobie w /etc/passwd zobaczyc jacy inni userzy istnieja w systemie. Czego sie tu uczymy? WYDLUBUJAC JEDNO OKO, USER MOZE DRUGIM PATRZYC. Dobrze mi znane jest tez "bezpieczenstwo" przez zabieranie mozliwosci wykonywania roznych plikow jak "w", "who", "pinky", "last" i "finger". Zabierajac userom prawa wykonywania do tych plikow nie zabieramy im dostepu do tych danych. Kazdy user moze sobie z innego konta te pliki zciagnac i przez odpalenie ich dostac te informacje, ktore chca. Kto jest zalogowany i kto sie skad gdzie i jak logowal jest zapisywane w dwoch plikach: [root@mobile root]# ls -al /var/run/utmp /var/log/wtmp -rw-rw-r-- 1 root utmp 1191936 Oct 26 22:11 /var/log/wtmp -rw-rw-r-- 1 root utmp 9216 Oct 26 22:11 /var/run/utmp Plik "utmp" odpowiada za wlasnie zalogowanych userow, a plik "wtmp" za historie logowania. Dopiero przez zabranie dostepu do tych plikow mozemy byc pewni, ze userzy nie dostana tych informacji: [root@mobile root]# chmod 600 /var/run/utmp /var/log/wtmp [root@mobile root]# ls -al /var/run/utmp /var/log/wtmp -rw------- 1 root utmp 1191936 Oct 26 22:11 /var/log/wtmp -rw------- 1 root utmp 9216 Oct 26 22:11 /var/run/utmp [root@mobile root]# su - test [test@mobile test]# who who: /var/run/utmp: Permission denied [test@mobile test]# w w: /var/run/utmp: Permission denied [test@mobile test]# A wiec jednak osiagnelismy zamierzony efekt. A czego sie teraz nauczylismy? JEZELI USEROWI WYDLUBIEMY OCZY, TO NIE ZNACZY, ZE CALY SWIAT PRZESTANIE ISTNIEC. cdn.