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