Linux security

Slacker

Użytkownik
Dołączył
Czerwiec 28, 2009
Posty
3
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.
 

Slacker

Użytkownik
Dołączył
Czerwiec 28, 2009
Posty
3
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

Były Moderator
Dołączył
Kwiecień 29, 2006
Posty
1953
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...
 

Slacker

Użytkownik
Dołączył
Czerwiec 28, 2009
Posty
3
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
smile.gif
.
 

widmo17

Były Moderator
Dołączył
Lipiec 16, 2007
Posty
1089
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ą.
 
Ostatnia edycja:

thc_flow

Zbanowany
Dołączył
Listopad 13, 2008
Posty
649
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ć)
 
Ostatnia edycja:

Wojtek

Były Moderator
Dołączył
Maj 23, 2007
Posty
546
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:
Kod:
[Wed Nov 18 20:27:46 2009] [info] Executing "/home/wojtek/public_html/rotfl.php" as UID 1001, GID 1001
Kod:
[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:
Kod:
[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:
Kod:
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... :)
Kod:
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 :)
 
Ostatnia edycja:

Hunter

Użytkownik
Dołączył
Październik 29, 2005
Posty
478
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

Były Moderator
Dołączył
Lipiec 16, 2007
Posty
1089
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

Użytkownik
Dołączył
Październik 29, 2005
Posty
478
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 ).
 

Hunter

Użytkownik
Dołączył
Październik 29, 2005
Posty
478
Ps. aby uniemozliwic wykonywanie plikow jako urzadzenie nalezy ustawic punkt montowania z opcja -nodev
 
Do góry Bottom