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 ;]

Related Posts: