12.26
In /dev/random ,Arty ,Internet ,Linux | Tags: /dev/random, Linux, Security
czyli co zmienic żeby było bezpieczniej ;]. Wszelkie sugestie proszę w komentarzach, art uzupełnię jak znajdę jakiś ciekawy trik ;]. Oczywiście, są to tylko rzeczy pomagające zabezpieczyć sam system, na bugi w appie typu SQL injection raczej nie poradzą ale wtedy przynajmniej możesz powiedzieć “To nie ja, to devowie porobili dziury w appie!” ;]. Zacznę od początku:
Partycje, noexec i grsec
Grsec to jest taki fajny patch który ma parę przydatnych ficzerów, z przydatniejszych (wszystkie sa w Security Options->Grsecurity)
Address Space Protection
Tu większość (zwłaszcza blokowanie /dev/mem i /dev/kmem) warto włączyć. Psuje to niestety parę rzeczy (np. narzedzie della do gdzebania w BIOSie z poziomu systemu) ale nikt nie może grzebać w pamięci co jest Good Thing, jak zresztą parę innych rzeczy podAddress Space Protection, tylko trzeba dokładnie testować, niektóre rzeczy to psuje.
Filesystem Protections
Blokowanie montowania, mknodów, i apru innych rzeczy w chroocie, a także paru metod wychodzenia z niego, blokowanie dostępu do /proc, większość rzeczy tutaj można włączyć, raczej nic nie popsują (tylko czytaj co napisano w info każdej opcji!). Restrict /proc to user only spowoduje że user będzie mógł tylko widzieć procesy uruchomione przez siebie, więc nie podpatrzy tak łatwo co chodzi w systemie.
Kernel auditing
Popatrz i włącz co uważasz za słuszne, logowanie np. mountów się przydaje, ale niektóre opcje potrafią spamować
Executable Protection
Tu TPE jest ciekawą opcją, powoduje ona że zwykłe userki (lub tylko pare “untrusted” userków) moga odpalać tylko soft w katalogach owned by root, więc nie może sobie odpalic binarki z home nawet jak ma go zamonotowane z exec - takie dodatkowe security
Network protections
Tutaj możesz sobie stworzyć grupę która np. nie będzie mogła tworzyć listening sockets, albo łączyć się nigdzie siecią, nie zdarzyło mi się jeszcze z tego korzystać, ale tym można np. zablokowac shellowym userkom stawiania własnych serwerów. Oprócz tego jest TCP/UDP blackhole który w skrócie powoduje że porty closed wyglądają jak filtered.
O grsecu można by napisać długi artykuł więc poprzestane na tych paru tipsach, teraz partycje.
Najlepiej jest mieć wszystko w LVMie z powodu wygody w przydzielaniu wolnego miejsca.
Uprawnienia partycji
Tu zasada “tylko tyle ile potrzeba” czyli gdzie się da to noexec, nosuid, nodev. Z tym że trzeba uważać, bo np. (nie wiem jak rpm) apt odpala programy (skrypty postinst, prerm itp) z /var(lib/dpkg chyba ale nie wiem czy tylko stamtąd), niektore z paczek odpalają też skrypty w /tmp więc na czas updatu albo remout albo troche “lżejsza” polityka montowania (np tylko /tmp i /var/tmp jako noexec).
Tak samo w przypadku niektórych aplikacji webowych, ale większość jednak używa interpretera więc /var/www z noexec to nie jest problem, tak samo jak /home
Logi, configi i backupy
Zaczynając od końca, mimo że to nie do konca związane z tematem, miej codzienne i SPRAWDZONE backupy tak że w razie rm -rf / możesz szybko odtworzyć coś co działa. Zastanów sie też nad konrolą wersji dla configów, taki etckeeeper (przechowuje /etc/ w gicie) + eksport tego gdzieś jest bardzo pomocny gdy chociażby popsułeś coś i musisz wgrać stary config (albo ktoś Ci coś zmienił). A co do logów…
Jeżeli masz taką możliwość, loguj wszystko zarówno lokalnie i zdalnie (nawet jak ktoś lokalnie bedzie w nich grzebał to masz unaltered version na serwerze logów. Oprócz tego miej narzędzie analizujące logi (ja uzywam logchecker) + raport na maila i poświęć troche czasu na tuning żeby nie generował zbyt dużo false positive, o wiele łatwiej wypatrzeć potencjalną nieprawidłowość gdy masz 5KB do przejrzenia niż gdy masz 500KB.
Updaty
Maillisty typu bugtraq@securityfocus.com dostarczają raczej świeżych informacji nt. nowo odkrytych bugów, trafiają tu też listy np. z Debian Security Advisor o błędach dot. security bugów w paczce. Aktualizuje paczkę jak tylko widzisz bug związany z Twoją konfiguracją, ale jeżeli bug nie może być wykorzystany w Twojej konfiguracji (bo np. jest local i nie ma możliwości odpalenia go jak user nie ma shella na maszynie) to możesz odpuścić (chociaż wg. mnie najlepiej wszystko akutalizować, nawet jak są tam tylko małe bugi, you never know;] )
Zdalny dostęp i SSH
Po pierwsze, unikaj FTP jak ognia, więcej problemów niż tego warte ;]
Po drugie, gdy user potrzebuje dostęp TYLKO do plików nie dawaj mu shella! Przeczytaj TO i daj mu dostęp tylko do SCP (niezłym klientem jest FileZilla z tego powodu że jest multiplatform więc można dać te same instrukcje linuksiarzowi, makowcowi i windziarzowi
Po trzecie, odpowiednie uprawnienia, userki nie powinni móc sobie zaglądać do katalogów domowych, czy podglądać pliki aplikacji którą nie zarządzają(hasła do bazy!). Limity (/etc/security/limits.conf) tez się przydadzą jak masz niesfornych userków. Jak user musi miec prawo do restartowania jakiegos serwisu, daj mu sudo z uprawnieniami tylko do jednej komendy.
Po czwarte sudo i PermitRootLogin no lub PermitRootLogin without-password + pubkey
Firewall
Ja lubię FERM (jest w paczkach) ale dobrze napisany skrypt bashowy też starczy, pozwól ssh, usługi i nic więcej, to takie zabezpiecznie przed przypadkowym wystawieniem czegoś na zewnątrz.
To tyle z “podstawowych” rzeczy, pisać możnaby długo, może kiedyś powstanie kolejna część ;]. Wszelkie uwagi/propozycje poprawek/błędy w komentach ;]
14 ResponsesLeave a comment ?
A jak zabezpieczyć się przed fork-bombą?
/etc/security/limits.conf, napisałem przecież ;p
Ok, nie wiedziałem, że to tu ;p
A co jest złego w FTP ? Od *dawna* soft typu vsftpd nie był specjalnie podatny na remote exploit. Bezpieczeństwo podobne jeżeli mamy uruchomioneto TLS-a.
1.Sftp wymaga tylko jednego portu otwartego, z FTPem niektóre rotuerki sie walą
2. To że jest TLS nie znaczy że user będzie go używać ;]. Może np. używać windowsowego explorera z tym.
Oprócz tego część NATów jest mało kompatybilna z tym (bo nawet jak potrafi otworzyć dodatkowy port na dane, to gdy kanał jest zaszyfrowany już tego nie może robić
3. To jest dodatkowa usługa do administracji, podczas gdy sshd jest na serwerze anyway
> Oprócz tego jest TCP/UDP blackhole który w skrócie powoduje że porty closed wyglądają jak filtered.
Jeśli to jest to, o czym myślę, to jest to bardzo mądre rozwiązanie. Przy byle konkretniejszym floodzie na takie porty maszyna radośnie upuszcza pakiety na podłogę, a tymczasem wszystkie routery po drodze, łącznie z naszymi… robią bokami, bo im się tablice stanów kończą.
Noexec to tylko taka głupia flaga, która mówi, że z danego fs-u nie powinno się odpalać binarek (bo jest to np. zasób podmontowany po NFS-ie z serwera o innej architekturze). Może w połączeniu z WielkąPytąBradaSpenglera (programistą może i koleś jest niezłym, ale przy okazji jest dupkiem sto razy większym od Theo) ma to jakiś sens, ale skoro grsecu jest RBAC, to jest to tylko PITA. (a jak obejść noexec Lcamtuf pisał już wieki temu).
A po przedarciu się przez RHCE śmiem twierdzić, że SELinux z dopracowanymi politykami też jest całkiem zjadliwy.
Ten blackhole to po prostu “nie wysyłaj pakietów mówiących że nie da się połączyć” jak TCP RST czy ICMP unreachable. Jak się mają zapchać to sądzę że i tak to zrobią, z włączonym blackhole czy nie.
Co do noexeca, niby taaaak aaaleee jak jakiś “script kiddie” wywali sie na tym to da sobie spokój z dalszym grzebaniem ;]. Głównie po to że jak już musimy dawać komuś shella to żeby sobie nie instalował u siebie co mu się podoba ;]
>Ten blackhole to po prostu “nie wysyłaj pakietów mówiących że nie da się połączyć” jak TCP RST czy ICMP unreachable. Jak się mają zapchać to sądzę że i tak to zrobią, z włączonym blackhole czy nie.
Oczywiście, że się nie zapchają, bo widząc wracające RST/ICMP(4) będą usuwać stany z tablic.
Kiedyś, jeszcze za czasów paczy Solara sam się tą funkcją trzepałem. Po latach uważam ją za bezsensowe gówniarstwo — nie dość że jest to security through obscurity, to jeszcze cierpi na tym infrastruktura pośrednia.
Odnoszę wrażenie, że czasy dawania shell-a ludziom którzy mogą coś zepsuć poprzez odpalenie exploitów już minęły. Albo ktoś kupuje maszynę i ma wtedy dostęp do root-a, albo ktoś kupuje hosting i ma dostęp do ftp.
Osoby które mają konta shellowe to albo pracownicy i nikt tu nie będzie exploitów uruchamiał, bo takie rzeczy inaczej się rozwiązuje, albo są to osoby które są w kręgu zaufania czy jak kto chce to nazwać i nie będą takich rzeczy robić.
Osobie obcej dostępu do żadnej maszyny bym nie dał.
Jeżeli dostaje się debilne rozkazy od szefostwa trzeba się przed takimi ewentualnościami zabezpieczyć ;].
@r Sam tej opcji raczej nie używam (w końcu jak ktoś chce to sobie zeskanuje). Ale w przypadku ataku wole żeby zapychał się RAM routerów operatora a nie żeby zżerało bandwidth za który zapłaciłem ;]. Poza tym mówimy o portach closed, nie różni to się niczym od zrobienia DROP na firewallu, nikt nie będzie przecież DoSował zamkniętego portu.
>@r Sam tej opcji raczej nie używam (w końcu jak ktoś chce to sobie zeskanuje). Ale w przypadku ataku wole żeby zapychał się RAM routerów operatora a nie żeby zżerało bandwidth za który zapłaciłem ;]. Poza tym mówimy o portach closed, nie różni to się niczym od zrobienia DROP na firewallu, nikt nie będzie przecież DoSował zamkniętego portu.
A o jakiej przepustowości chcesz mówić, gdy routery klękają i zaczynają zrzucać połączenia lub nie chcą puszczać nowych? Szczególnie, gdy zarżnięty router postanowi zrzucić np. sesję BGP? ;)))
Właśnie cała idea cichego upuszczania pakietów na podłogę jest co najmniej niemądra: nie obsługujesz czegoś, to mówisz ,,nie obsługuję”. A DoS w oparciu o flood na maszynę, która nie odsyła RST/ICMP DestUnreach raczej nie jest wymierzony w maszynę, ile właśnie w routery.
Tak aaaaleee ;] atakujący może po prostu floodować otwarty port, efekt ten sam (może nawet lepszy jak serwer odpowie ACKiem bo będzie dłużej wisieć w tablicy) ;]
Dobrze napisany serwer usługi X powinien, po przekroczeniu limitu połączeń, zrzucać następne z RST.
Dużo rzeczy “być powinno”, rzeczywistość jest inna ;]. W większości serwerów jak skończy się liczba wątków/procesów to trzyma sobie w accept queue (tzn nie one tylko system bo wywołują listen() z bardzo dużym backlogiem).
Oprócz tego, SYN/ACK nie generuje aplikacja, tylko kernel, tzn. dopiero jak klient odpowie na syn/ack to kernel przekazuje do appa że jest nowe połączenie, więc autor appa może co najwyżej zabezpieczać się przed nadmierną ilością otwartych połączeń, a nie “półotwartych”
Poza tym dropowanie zamiast słania RST blokuje możliwość używania kompa do idle scana ( -sI w nmapie) chociaż to akurat małe zmartwienie ;]