Archiwum dla kategorii: ‘ISPConfig2’

v1.Lenny-cz.2

05-30-09

Dziś próbując uruchomić svn’a na serwerze wydałem ( oczywiście z root’a ) głupią komendę:

chown www-data:www-data * -R

Tylko że zamiast byćw katalogu /var/www/svn bylem w /var/www. Generalnie spieprzyłem uprawnienia wszystkich stron, kont pocztowych itp. Że zdarzyło mi się takie coś po raz trzeci bodajże to sie wkurzyłem i postanowiłem napisać skrypcik który naprawi uprawnienia /var/www dla ISPConfiga2 gdzie identyfikatory są ustawione na [domain]. Więc nie owijając w bawełnę:
Link do pliku: restore_premissions

Treść nalezy skopiować, zapisać i nadać uprawnienia do wykonania

chmod +x restor_permissions
#! /bin/bash
#Shrek ISPConfig2 Permissions script
#Variables
root=root:root
www=www-data
no=.no_delete
dir=/var/www
 
echo "Restoring Permissions of $dir"
 
#Gets web[0-9]* directories into table
ls -alh $dir | grep drwx | grep -e "[0-9][0-9]:[0-9][0-9] web[0-9]" | awk '{print $9}' > .web_dirs
n=1
exec < .web_dirs
while read line
do
        web_dirs_list[$n]=$line
        n=$n+1
done
 
#echo ${#web_dirs_list[@]}
no_of_dirs=${#web_dirs_list[@]}
 
for ((k=1;k<=no_of_dirs;k++))
do
        web=${web_dirs_list[$k]}
        echo $web
        #Owning a web[0-9] directory to www-data:web[0-9]
        chown www-data:$web /var/www/$web -R
        #Owning root permission files
        chown $root $dir/$web/cgi-bin/$NO
        chown $root $dir/$web/log/error.log
        chown $root $dir/$web/log/$NO
        chown $root $dir/$web/phptmp/$NO
        chown $root $dir/$web/ssl/$NO
        chown $root $dir/$web/user/$NO
        #Owning User files
        #Getting user namse/dirs
        ls -alh $dir/$web/user/ | grep drwx | awk '{print $9}' | grep -e ".[a-z]_[a-z]" > .users
        m=1
        exec < .users
        while read line
        do
                user_list[$m]=$line
                m=$m+1
        done
 
        #echo ${user_list[@]}
        no_of_users=${#user_list[@]}
        echo $no_of_users
        zero=0
        if(($no_of_users>=$zero ))
        then
                #Owning files to their owners
                for((x=1;x<=$no_of_users;x++))
                do
                        user=${user_list[$x]}
                        echo "$web/user/$user"
                        chown $user:$web $dir/$web/user/$user -R
                        chown $root $dir/$web/user/$user/.antivirus.rc
                        chown $root $dir/$web/user/$user/.autoresponder.rc
                        chown $root $dir/$web/user/$user/.html-trap.rc
                        chown $root $dir/$web/user/$user/.local-rules.rc
                        chown $root $dir/$web/user/$user/.mailsize.rc
                        #Some users does not have .procmailrc file
                        chown $root $dir/$web/user/$user/.procmailrc
                        chown $root $dir/$web/user/$user/.quota.rc
                        chown $root $dir/$web/user/$user/.spamassassin.rc
                        chown $root $dir/$web/user/$user/.user_prefs
                        chown $root $dir/$web/user/$user/.vacation.msg
                done
                no_of_users=0
                unset user_list[*]
        fi
        #Owning symlinks
        symlink=`ls -alh /var/www | grep $web | grep lrwx | awk '{print $9}'`
        echo $symlink
        chown $www:$web $dir/$symlink
rm -f .users
rm -f .web_dirs
done

Opublikowane przez: Shrek data wpisu: Maj 30, 2009

v1.Lenny-cz.1

05-27-09

Tak się ostatnio stało że przypadło mi postawienie serwera, i przeniesienie całego hostingu wirtualnego na VPS’a.

Zdecydowałem że panelem do zarządzania hostingiem będzie ISPConfig2 -klik. Przyczyn było kilka:
Pierwsza jest taka że panel jest darmowy.
Druga to to że jeśli pamięć mnie nie myli to jest na licencji BSD.
Trzecia to że pomimo że ISPConfig3 jest nowszy to jednak większy support i więcej informacji znajdę o sprawdzonym rozwiązaniu niż o wersji która dopiero co oficjalnie ujrzała światło dzienne.

Instalacja przechodzi bez najmniejszego problemu – dosłownie dziedziczenie przez kopiowanie z manuala w okno putty’ego. Problemem może być wygenerowanie poprawnych certyfikatów dla naszej domeny gdyż dla kogoś kto nigdy tego wcześniej nie robił może to sprawić pewien problem.
Po instalacji stwierdzam ze system z zainstalowanymi tylko usługami potrzebnymi dla hostingu z howto + SSHD pochłania jeśli mnie pamięć nie myli z 70MB ramu także niezawiele. A po instalacji wszystko zajmowało 1,7Gb

Zabezpieczenie SSH:
1. Przyzwolenie tylko grupom do logowania przez ssh

Do pliku /etc/ssh/sshd_config dorzucamy takie 2 linijki:

1
2
AllowGroups sshAllow
DenyGroups sshDeny

następnie tworzymy takie grupy w systemie :

1
2
#:groupadd sshAllow
#:groupadd sshDeny

Do wybranych grup dodajemy odpowiednich użytkowników do wybranych grup:

1
#:adduser some_user_name sshAllow

lub

1
#:adduser some_user_name sshDeny

Jak same nazy grup mówią userzy w grupie sshAllow będą mogli się logować przez ssh do systemu.

2.Automatyczna obrona ssh przed atakami słownikowymi.

Zamiast bezsensu przepisywać treść artykuły poprostu polecam – klik a poniżej polecenia na zasadzie copy’n'paste

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
apt-get install python python2.3-dev python2.3
cd /tmp
wget http://mesh.dl.sourceforge.net/sourceforge/denyhosts/DenyHosts-2.0.tar.gz
tar xvfz DenyHosts-2.0.tar.gz
cd DenyHosts-2.0
python setup.py install
cd /usr/share/denyhosts
cp denyhosts.cfg-dist denyhosts.cfg
# w poniższym musimy wyedytować plik w zależności od naszej dystrubucji
vi denyhosts.cfg
SECURE_LOG = /var/log/auth.log
LOCK_FILE = /var/run/denyhosts.pid
cp daemon-control-dist daemon-control
vi /usr/share/denyhosts/daemon-control
# i należy upenwic się ze wartości zgadzają się z poniższymi ( dla debiana )
# DENYHOSTS_BIN = "/usr/bin/denyhosts.py"
# DENYHOSTS_LOCK = "/var/run/denyhosts.pid"
# DENYHOSTS_CFG = "/usr/share/denyhosts/denyhosts.cfg"
chown root daemon-control
chmod 700 daemon-control</span></em></span>
cd /etc/init.d
ln -s /usr/share/denyhosts/daemon-control denyhosts
update-rc.d denyhosts defaults
/etc/init.d/denyhosts start</span></em></span>
/etc/init.d/denyhosts start --purge

Po instalacji zalecam pobawienie się ustawieniami programu /usr/share/denyhosts/denyhosts.cfg
A tu mamy przykładowy plik konfiguracyjny : przykładowy plik konfugiracyjny denyhostsa

Względnie ciekawy artykulik: http://www.securityfocus.com/infocus/1876

3. Przyśpieszenie logowania proftpd

Niezależnie od logowania przez ssh każdy użytkownik systemu przynajmniej w teorii może się zalogować przez FTP do swojego konta.
Aby przyśpieszyć czasem niesamowicie wolne łączenie się s naszym hostem należy w pliku konfiguracyjnym proftpdznaleść wpis IdentLookups , zmienic jego wartość na off oraz wziąść w tagi Global:

1
2
3
<global>
IdentLookups                    off
</global>

Oraz wypadało by dodać wpisy:

1
2
3
DefaultRoot ~
UseReverseDNS off
ServerIdent on "FTP Server ready."

4. Uszczelnienie Apache2.2 i php5

W sumie całe zabezpieczenie serwera WWW polega na jak największym ograniczeniu możliwości wycieku informacji o serwerze do wiadomości potencjalnego atakującego. Wersja systemy, wersja php, apache’a, ssh, proftpd… wszystko może zwiększyć hakerowi możliwość dokonania włamania.
W pliku httpd.conf ( lub apache2.conf) powinny się znaleźć takie 2 wpisy:
#Dzięki ponizszym opcjom powodujemy ze nasz serwer apache nie zwraca zadnych informacji o swojej wersji w naglowkakch http

1
2
3
ServerSignature Off
#ServerTokens ProdServerSignature Off
ServerTokens Prod

W natomiast w pliku php.ini

1
2
3
disable_functions = exec,system,passthru,shell_exec,popen,escapeshellcmd,proc_open,proc_nice,ini_restore
expose_php = Off
display_errors = Off


W bliższej lub dalszej przyszłości rozgryzę iptables, zabezpieczenie FTP, skrypty do “hot backupu” maszyny przy padzie, zawartość katalogu /etc/security oraz man security

Opublikowane przez: Shrek data wpisu: Maj 27, 2009