Linux security

[Slacker]

Linuksa używam od prawie roku ale nigdy jakoś specjalnie nie wnikałem w jego zabezpieczenia. Ostatnio chodzą mi myśli po głowie by zacząć. Więc w wolnym czasie siedzę na google i szperam. Zwracam się do was o jakieś przydatne linki, ebooki czy też jakieś większe FAQ umożliwiające dobry start. Z góry dzięki za pomoc.

[loganek]

poczytaj o firestarter i selinux

[Slacker]

Mam aktualnie na Arch Linux iptables. Czytałem w necie o podstawej konfiguracji usług. Między innymi Telnet, SSH. Generalnie takie podstawy. Poszukuje czegoś innowacyjnego. Może polecicie jakiegoś ebooka?

[Dark Smark]

Jeżeli chodzi Ci też o zabezpieczenie usług to książka Apache. Zabezpieczenia aplikacji i serwerów WWW, ogólnie mógłbyś przejrzeć inne związane z tworzeniem dynamicznych stron www bo wiele dziur nie jest w oprogramowaniu serwera a w skryptach.
A innowacyjne to jak sam wymyślisz...

[abramakabra]

Polecam tą książkę:
http://helion.pl/ksiazki/bsieli.htm

[Magnefikko]

http://www.linuxsecurity.com/content/section/9/161/

[Slacker]

Panowie dzięki za linki. Akurat książka migneła mi się w miejscowym Empiku, tak więc jutro skocze i lukne co i jak .

[KangurX]

firestarter to jest podobno nakladka na iptables, radze ci tez apgrejdowac system ;D

[widmo17]

Chmody dobrem narodu, wirtualizacja, wyłączenie logowania userem root itp. Jak chcesz się dowiadywać dużo na temat serwerów to zapraszam na irc, w sieci tego jest coraz mniej, a irc to najczęściej grupy ludzi którzy są obcykani w tego typu sprawach i chętnie pomagają.

[thc_flow]

Popieram,
1) CHMODy
2) iptables
3) PortSentry
4) Logcheck
5) odrobina inteligencji
6) limits.conf
7) stała aktualizacja distro i używanie wersji stabilnych w których nacisk położony jest na stabilność i bezpieczeństwo (idealne dystrybucje to Slackware czy Debian)
8) stała obserwacja procesów i dobór demonów systemowych tak aby działały tylko te wymagane (a nie trzy tony tego co tylko żre ram i cpu przy okazji stwarzając potencjalne zagrożenie)
9) konfiguracja demonów
10) zmiana nazwy roota
11) używanie skomplikowanych haseł i częsta zmiana.

Oczywiście to tylko ułamek tego co należy zrobić aby system był "bezpieczny", główna dziura w zabezpieczeniach to zawsze człowiek, przeważnie admin systemu, choć zdażają się też glupoty popełnione przez usera (do czego admin ma zadanie nie dopuścić)

[Wojtek]

Do listy THC Flow można dopisać jeszcze grsecurity ;>
Dodaje bardzo wiele fajnych 'ficzerów'... o których poczytać możesz na stronie projektu i chociażby Wikipedii.

Poza tym...
+ Chrooting usług narażonych na ataki, demon dns itp...
+ Nadawanie użytkownikom bardziej restrykcyjnych uprawnień poprzez zastosowanie ACL.
+ Zmiana albo ukrycie 'tokenów', które zwracają usługi... chwalenie się starą wersją np. apache... huh, nic fajnego ;>
+ Odnośnie demonów httpd, obsługi php, etc...
a) suphp, skrypty wykonywane z uprawnieniami usera do którego 'należą', etc... poniżej przykładowe logi z suphp w akcji:

[Wed Nov 18 20:27:46 2009] [info] Executing "/home/wojtek/public_html/rotfl.php" as UID 1001, GID 1001

[Wed Dec 30 13:03:31 2009] [warn] UID of script "/home/wojtek/public_html/rotfl.php" is smaller than min_uid

Przykładowy config suphp:

[global]
logfile=/var/log/suphp/suphp.log
loglevel=info

webserver_user=www-data

docroot=/home
;chroot=/

allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

check_vhost_docroot=true
errors_to_browser=false
env_path=/bin:/usr/bin

umask=0077
min_uid=33
min_gid=33

[handlers]
x-httpd-php=php:/usr/bin/php5-cgi
x-suphp-cgi=execute:!self

b) Demon httpd na uprawnieniach usera != root ;D
c) Nie ładowanie nie potrzebnych modułów...
d) Własny plik php.ini dla każdego usera z dostępem do demona httpd i php z osobna...
W przypadku apache wystaczy ustawić zmienną PHPRC przez SetEnv. W lighttpd:

setenv.add-environment = (
       "PHPRC" => "sciezka do php.ini",
       "SUPHP_HANDLER" => "x-httpd-php"
)

Reszty demonów nie znam, zalety płynące z takiego rozwiązania ? Indywidualne ustawienia php dla poszczególnych userów, chociażby open_basedir itd...
e) Wsparcie apache mod_security, dla lighttpd odpowiednika chyba nie ma ;/
+ Monitorowanie anomalii i poczynań sieciowych... ulog-acctd, w połączeniu z iptables - całkiem fajny i prosty stuff, przydatne mogą okazać się również narzędzia iptraff, iftop, tcpdump... snort... co do ostatniego mam mieszane uczucia ale...

multicast groups=1
accounting file=/var/log/ulog-acctd/account.log

dump file=/var/log/ulog-acctd/dump
debug file=/var/log/ulog-acctd/debug.log
debug = syscall, misc, statistics, error, asdf, error-packet 

accounting format="[%Z] %s:%S\t> %d:%D \t [%i] [%o] [%f]\n" 

empty interface="----"
empty prefix="-"

flush=30
fdelay=0

# IPTABLES - PRZYKLAD
iptables -I INPUT -p TCP --dport 3128 -s 192.168.1.0/24 -m state --state NEW -j ULOG --ulog-prefix ALLOW_LAN_WCHODZI_SQUID

# LOGI - /var/log/ulog-acctd/account.log
[14/10/09 12:46:24] 192.168.1.2:1299    > 192.168.1.1:3128      [eth0] [----]  [ALLOW_LAN_WCHODZI_SQUID]
[14/10/09 12:46:25] 192.168.1.1:57370    > 209.85.229.104:80      [----] [wlan0] [ALLOW_WAN_WYCHODZI_HTTP]

# EOF

+ Zastąpienie takich usług jak telnet/ftp odpowiednikami używającymi szyfrowania... ssh/sftp.

Kilka drobnych, ogólnikowych wskazówek, które przed chwilą przyszły mi do głowy... jak znajdę chwilę to cuś jeszcze dopiszę

Pozatym jak z admina 'dupa' to duża część jakichkolwiek zabezpieczeń wbudowanych w system na nic się nie zda, a bo to na katalog z www 'na ślepaka' ustawi za duże chmody, żeby demon httpd nie miał 'problemów' z odczytaniem stron... rotfl

[Hunter]

chmody, portsentry etc. na nic sie nie zdadza w momencie kiedy agresor wykorzysta suid lub co gorsza wykona plik jako urzadzenie ;-) no i jezeli uslugi sa poza restrykcyjnym obszarem to juz w ogole bajka -.-

[widmo17]

chmody, portsentry etc. na nic sie nie zdadza w momencie kiedy agresor wykorzysta suid

Dlatego szuka się plików z suidem i się go usuwa dla plików które go nie potrzebują.

jezeli uslugi sa poza restrykcyjnym obszarem

Dobrze napisana usługa po wykonaniu operacji do których potrzebuje praw roota znosi sobie te uprawnienia i nie pozwala albo utrudnia przywrócenie ich. Grsec też tego pilnuje.

(Ostro wygrzebałeś temat.)

[Hunter]

Trafny wybor, grsecurity jest 'boskie' ale pocieszeniem jest fakt ze nie kazdy o tym wie i nie kazdy potrafi zainstalowac . Odnosnie uslug uruchamianych z poziomu chroot lub wyzej czyli jaila nie robia za wielka przeszkode w momencie kiedy nie ma zabezpieczenia z poziomu pkt. montowania ( to jedyny warunek udanego ataku z wymienionymi wczesniej zabezpieczeniami without grsec of course jaki znam ).