1.  Apache

Apache posiada stosunkowo dobry domyślny plik konfiguracyjny, warto jednak nanieść na niego kilka poprawek, jak na przykład związanie go z jednym adresem czy zapobieganie wyciekom informacji. Poniżej podajemy opcje, które warto dodać do pliku konfiguracyjnego.

O ile nie wyłączono ssl w pliku /etc/make.conf przed instalacją, Apache powinien posiadać jego obsługę. Wewnątrz katalogu /etc/apache2/vhosts.d znajdują się przykładowe pliki konfiguracyjne. Są to tylko przykłady, dlatego należy je dokładnie sprawdzić zanim się ich użyje.

Bardzo ważne jest zdefiniowanie w konfiguracji adresu na którym serwer będzie nasłuchiwał (a nie na wszystkich dostępnych adresach IP danego systemu). Poniżej przykładowy plik 00_default_vhost.conf file:

# Nasłuchuj tylko na podanym adresie IP
Listen 127.0.0.1

Zalecamy również, aby serwer Apache nie podawał żadnych informacji na swój temat. Domyślnie do wszystkich stron dołączana jest wersja serwera oraz nazwa wirtualnego hosta. Można to wyłączyć przełączając opcję ServerSignature na Off.

ServerSignature Off

Apache jest kompilowany z opcjami --enable-shared=max i --enable-module=all, czyli ze wszystkimi modułami, co zmusza do wykomentowywania wszystkich przez nas nieużywanych w /etc/apache2/httpd.conf modułów z sekcji LoadModule (LoadModule i AddModule). Następnie należy zrestartować usługę poleceniem /etc/init.d/apache restart.

Całość dokumentacji znajduje się na stronie http://www.apache.org.

1.  Bind

Dokumentacja znajduje się na stronach Internet Software Consortium. "The BIND 9 Administrator Reference Manual" znajduje się również w katalogu doc/arm.

Nowsze ebuildy BIND umożliwiają chrootowanie się poza maszynę. Po zainstalowaniu bind należy wykonać następujące czynności:

# emerge --config bind
(Przed wpisaniem powyższego polecenia warto zmienić katalog dla chroota
w pliku /etc/conf.d/named. W innym wypadku zostanie użyty katalog
/chroot/dns)

1.  Djbdns

Djbdns to implementacja zabezpieczeń DNS, której autor jest tak pewny, że stawia na nią pieniądze. Jej sposób działania bardzo różni się od tego z Bind 9, ale mimo wszystko warto ją wypróbować. Więcej informacji znajduje się na stronie http://www.djbdns.org.

1.  FTP

Generalnie używanie FTP (File Transfer Protocol) to kiepski pomysł. FTP używa niezaszyfrowanych haseł (są przesyłane czystym tekstem), nasłuchuje na dwóch portach (standardowo 20 i 21), a ponadto jest często atakowane przez włamywaczy szukających anonimowych serwerów w celu wymiany warezów. W związku z wieloma brakami w bezpieczeństwie protokołu FTP powinno się zamiast niego używać sftp lub HTTP. Jeśli nie jest to możliwe należy zabezpieczyć FTP jak to tylko możliwe i przygotować się na sporo problemów.

1.  Mysql

Jeśli dostęp do bazy mysql jest potrzebny wyłącznie lokalnym aplikacjom należy odkomentować następującą linię w pliku /etc/mysql/my.cnf:

skip-networking

Następnie wyłączymy komendę LOAD DATA LOCAL INFILE. Zapobiegnie to nieautoryzowanemu dostępowi do lokalnych plików. Takie zabezpieczenie przydaje się np. w przypadku odkrycia słabych punktów w PHP umożliwiających atak typu SQL Injection.

set-variable=local-infile=0

Następnie musimy usunąć przykładową bazę danych (test) i wszystkie konta poza kontem roota.

mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host="localhost" and user="root");
mysql> flush privileges;

1.  Proftpd

Proftpd miało wiele problemów związanych z bezpieczeństwem, na szczęście większość z nich już naprawiono. Do domyślnego pliku konfiguracyjnego warto dodać następujące opcje:

ServerName "My ftp daemon"
#Don't show the ident of the server
ServerIdent on "Go away"

#Makes it easier to create virtual users
RequireValidShell off

#Use alternative password and group file (passwd uses crypt format)
AuthUserFile "/etc/proftpd/passwd"
AuthGroupFile "/etc/proftpd/group"

# Permissions
Umask 077

# Timeouts and limitations
MaxInstances 30
MaxClients 10 "Only 10 connections allowed"
MaxClientsPerHost 1 "You have already logged on once"
MaxClientsPerUser 1 "You have already logged on once"
TimeoutStalled 10
TimeoutNoTransfer 20
TimeoutLogin 20

#Chroot everyone
DefaultRoot ~

#don't run as root
User  nobody
Group nogroup

#Log every transfer
TransferLog /var/log/transferlog

#Problems with globbing
DenyFilter \*.*/

Całość dokumentacji znajduje się na stronie http://www.proftpd.org.

1.  Pure-ftpd

Pure-ftpd to odmiana trollftpd, zmodyfikowana pod kątem bezpieczeństwa przez Franka Dennisa.

Dzięki włączeniu opcji AUTH uniemożliwia się korzystania z kont użytkowników systemowych i zmusza serwer do pracy z kontami wirtualnymi. Bazę danych wirtualnych użytkowników tworzy się poleceniem -lpuredb:/etc/pureftpd.pdb, a użytkowników do niej dodaje za pomocą /usr/bin/pure-pw.

AUTH="-lpuredb:/etc/pureftpd.pdb"

## Misc. Others ##
MISC_OTHER="-A -E -X -U 177:077 -d -4 -L100:5 -I 15"

Warto również skonfigurować opcję MISC_OTHER, tak aby uniemożliwić logowanie się jako anonymous (-E), zamykać każdego użytkownika w chroocie (-A), uniemożliwić dostęp do plików rozpoczynających się od . (kropki) (-X), podać maksymalny czas beczynności (-I), zabronić rekursywnego pobierania (-L) oraz ustawić sensowny umask.

Całość dokumentacji znajduje się na stronie http://www.pureftpd.org.

1.  Vsftpd

Vsftp (skrót od "bardzo bezpieczne ftp" (very secure ftp)) to mały daemon ftp z bardzo dobrą domyślną konfiguracją. Jest bardzo prostym programem, więc nie posiada tak rozbudowanych możliwości jak pureftp albo proftp.

anonymous_enable=NO
local_enable=YES

#read only
write_enable=NO

#enable logging of transfers
xferlog_std_format=YES

idle_session_timeout=20
data_connection_timeout=20
nopriv_user=nobody

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chrootlist

ls_recurse_enable=NO

Jak widać nie ma możliwości, aby usługa ta posiadała jakieś indywidualne ustawienia praw dostępu. Jeśli jednak chodzi o ustawienia dla anonimowych użytkowników okazuje się ona bardzo dobra, a taki anonimowy serwer przydaje się np. gdy trzeba szybko podzielić się z kimś kodem open source.

1.  Netqmail

Netqmail jest uważany za bardzo bezpieczny serwer pocztowy. Przy jego pisaniu zwrócono szczególną uwagę na opcje związane z bezpieczeństwem. Domyślna konfiguracja nie umożliwia przekazywania poczty, a w samym programie nie znaleziono błędu związanego z bezpieczeństwem od 1996 roku. Nie ma się co zastanawiać, należy po prostu wpisać emerge netqmail i zabrać się za konfigurację.

1.  Samba

Samba jest protokołem umożliwiającym wymianę plików z sieciami Microsoft i Novell, z którego nie powinno korzystać się w Internecie. Ponadto jak niemal każdy program wymaga pewnego dokonfigurowania.

[global]
  #Bind to an interface
  interfaces = eth0 10.0.0.1/32

  #Make sure to use encrypted password
  encrypt passwords = yes
  directory security mask = 0700

  #allow traffic from 10.0.0.*
  hosts allow = 10.0.0.

  #Enables user authentication
  #(don't use the share mode)
  security = user

  #Disallow privileged accounts
  invalid users = root @wheel

  #Maximum size smb shows for a share (not a limit)
  max disk size = 102400

  #Uphold the password policy
  min password length = 8
  null passwords = no

  #Use PAM (if added support)
  obey pam restrictions = yes
  pam password change = yes

Warto upewnić się, że wszystkie prawa dostępu są ustawione prawidłowo oraz zapoznać się z dokumentacją programu.

Następnie należy zrestartować serwer i dodać konta użytkowników, którzy mają mieć dostęp do tej usługi. Dokonuje się tego przy pomocy polecenia /usr/bin/smbpasswd z parametrem -a.

1.  ssh

Jedynym zabezpieczeniem jakiego potrzebuje OpenSSH jest przełączenie go na silniejszy mechanizm uwierzytelniania, oparty na szyfrowaniu klucza publicznego (przy pomocy niewłaściwie ustawionych haseł włamano się już między innymi na strony http://www.sourceforge.net, http://www.php.net i http://www.apache.org).

#Only enable version 2
Protocol 2

#Disable root login. Users have to su to root
PermitRootLogin no

#Turn on Public key authentication
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

#Disable .rhost and normal password authentication
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no

#Only allow userin the wheel or admin group to login
AllowGroups wheel admin

#In those groups only allow the following users
#The @<domainname> is optional but replaces the
#older AllowHosts directive
AllowUsers kn@gentoo.org bs@gentoo.org

#Logging
SyslogFacility AUTH
LogLevel INFO

(Należy zmienić adres na odpowiedni)
ListenAddress 127.0.0.1

Należy sprawdzić czy w pliku konfiguracyjnym nie ma linii UsePAM yes, ponieważ nadpisze ona ustawienia dla uwierzytelniania poprzez klucze publiczne. Można również wyłączyć PasswordAuthentication lub ChallengeResponseAuthentication. Więcej informacji na temat tych opcji można znaleźć w manie sshd_config.

Teraz wszyscy użytkownicy muszą wygenerować własne klucze na komputerach, z których będą się logować na nasz serwer. Dokonuje się tego następującym poleceniem:

# /usr/bin/ssh-keygen -t dsa

Następnie należy wpisać hasło.

Generating public/private dsa key pair.
Enter file in which to save the key (/home/kn/.ssh/id_dsa):[Press enter]
Created directory '/home/kn/.ssh'.
Enter passphrase (empty for no passphrase): [Enter passphrase]
Enter same passphrase again: [Enter passphrase again]
Your identification has been saved in /home/kn/.ssh/id_dsa.
Your public key has been saved in /home/kn/.ssh/id_dsa.pub.
The key fingerprint is:
07:24:a9:12:7f:83:7e:af:b8:1f:89:a3:48:29:e2:a4 kn@knielsen

W wyniku tych czynności w katalogu ~/.ssh/ zostaną utworzone dwa pliki o nazwach id_dsa i id_dsa.pub. Plik o nazwie id_dsa to prywatny klucz i nie powinien być przekazywany innym osobom. Natomiast drugi plik, id_dsa.pub, powinno umieścić się w ~/.ssh/authorized_keys na każdym serwerze, na który zamierzamy się logować:

$ scp id_dsa.pub other-host:/var/tmp/currenthostname.pub
$ ssh other-host
password:
$ cat /var/tmp/currenthostname.pub >> ~/.ssh/authorized_keys

Użytkownicy powinni pilnować swoich prywatnych kluczy i przechowywać je wyłącznie na nośnikach, które będą zawsze mieć przy sobie lub na swoich stacjach roboczych. Informację o tym należy umieścić w (polityce) bezpieczeństwa dotyczącej haseł.

Więcej informacji na ten temat można znaleźć na stronie projektu OpenSSH.

1.  Używanie xinetd

xintetd to zastępstwo dla demona usług internetowych - inetd (którego nie ma w Gentoo). Umożliwia kontrolę dostępu na podstawie adresu i czasu tego dostępu. Posiada również szerokie możliwości logowania, obejmujące między innymi czas uruchomienia serwera, zdalne adresy hostów, zdalnych użytkowników, czas działania serwera i wszystkie zgłoszone żądania.

Jak w przypadku wszystkich innych usług ważną rzeczą jest tu bardzo uważna konfiguracja. Ponieważ jednak xinetd jest uruchamiane z konta roota i obsługuje wiele protokołów, których działanie nie jest powszechnie znane, odradzamy jego używanie. Jeśli jednak koniecznie chcecie go używać oto jak należy go zabezpieczyć:

# emerge xinetd tcp-wrappers

Następnie edytujemy plik konfiguracyjny:

defaults
{
 only_from = localhost
 instances = 10
 log_type = SYSLOG authpriv info
 log_on_success = HOST PID
 log_on_failure = HOST
 cps = 25 30
}

# This will setup pserver (cvs) via xinetd with the following settings:
# max 10 instances (10 connections at a time)
# limit the pserver to tcp only
# use the user cvs to run this service
# bind the interfaces to only 1 ip
# allow access from 10.0.0.*
# limit the time developers can use cvs from 8am to 5pm
# use tpcd wrappers (access control controlled in
# /etc/hosts.allow and /etc/hosts.deny)
# max_load on the machine set to 1.0
# The disable flag is per default set to no but I like having
# it in case of it should be disabled
service cvspserver
{
 socket_type = stream
 protocol = tcp
 instances = 10
 protocol = tcp
 wait = no
 user = cvs
 bind = 10.0.0.2
 only_from = 10.0.0.0
 access_times = 8:00-17:00
 server = /usr/sbin/tcpd
 server_args = /usr/bin/cvs --allow-root=/mnt/cvsdisk/cvsroot pserver
 max_load = 1.0
 log_on_failure += RECORD
 disable = no
}

Więcej informacji znajduje się w man 5 xinetd.conf.

1.  X

Domyślnie Xorg jest skonfigurowany jako serwer X. Może to być niebezpieczne, ponieważ X używa nieszyfrowanych połączeń TCP i oczekuje na połączenia od xklientów.

Jeśli jednak komputer ma działać jako serwer X należy używać polecenia /usr/X11R6/bin/xhost z ostrożnością. Polecenie to umożliwia łączenie się z naszym serwerem klientom z innych hostów i używanie naszego ekranu. Może to być pomocne, jeśli chcemy użyć aplikacji opartej na X na innym komputerze, do którego dostęp mamy jedynie przez sieć, ale może również zostać wykorzystane w niecnych celach przez włamywaczy. Składnia dla tej komendy to /usr/X11R6/bin/xhost +hostname.

Dużo bezpieczniejszym rozwiązaniem jest nie korzystanie z tej możliwości np. poprzez uruchamianie serwera X poleceniem startx -- -nolisten tcp lub całkowite jej wyłączenie w plikach konfiguracyjnych.

defaultserverargs="-nolisten tcp"

Aby uniemożliwić nadpisanie pliku startx w trakcie emergowania nowych wersji Xorg należy dodać go do listy plików chronionych, dokonuje się tego poprzez dopisanie następującej linii do pliku /etc/make.conf:

CONFIG_PROTECT_MASK="/usr/X11R6/bin/startx"

Graficzny menedżer logowania wymaga nieco innego podejścia:

Dla gdm (Gnome Display Manager):

[server-Standard]
command=/usr/X11R6/bin/X -nolisten tcp

Dla xdm (X Display Manager) i kdm (Kde Display Manager):

:0 local /usr/bin/X11/X -nolisten tcp