Hasło roota w trybie recovery serwera, a Ezeelogin

Po wdrożeniu Ezeelogin na naszych serwerach hostingowych, administratorzy mają możliwość logowania się przez serwer-bramę, bądź używając kluczy.

W przypadku uruchomienia serwera w trybie recovery (np. przy problemie z systemem fsck systemu plików), Debian domyślnie wymaga podania hasła użytkownika root, które jest automatycznie zmieniane na losowe, nieznane hasło przez Ezeelogin.

Poniższe polecenie po podaniu poświadczeń administratora głównego Ezeelogin pozwala na wyświetlenie listy haseł.

php /usr/local/ezeelogin/ezlexport.php tmp && cat tmp | cut -d \’|\’ -f 1,4 && rm tmp

Polecenie nie sprawdza licencji – może zostać wywołane po jej wygaśnięciu.

Limitowanie zasobów użytkowników przy suPHP z wykorzystaniem stosu PAM

Nowy pracownik naszej firmy, administrator Linux Mateusz Małek, w ramach prowadzonych testów podatności przeprowadził udany, a zarazem trywialny atak mający wpływ na stabilność pracy jednego z naszych serwerów hostingowych.

Poniżej prezentujemy sposób częściowy zabezpieczenia serwera przed lokalnymi atakami DoS wykonywanymi przy pomocy funkcji shell_exec() w PHP, jeżeli wykorzystywany jest suPHP.

W przypadku wykorzystywania suPHP, uruchamiane z UID+GID użytkownika procesy nie przechodzą przez stos PAM, tym samym nie dotyczą ich limity pam_limits.so z /etc/security/limits.conf. Opisane poniżej kroki zmieniają to zachowanie.

Patchowanie, rekompilacja i rekonfiguracja suPHP

  1. Nakładamy przygotowany patch na suPHP:

    cd /usr/local/directadmin/custombuild
    cp $(find -type d -name \’suphp-0*\’) suphp-patched;
    cd suphp-patched;
    wget http://mkwm.zielonki.info/suphp_patch.diff -O – | patch -p1

  2. Tworzymy nową usługę PAM – np. \”suphp\”, uwzględniającą moduł pam_limits z dedykowaną konfiguracją – wykorzystanie globalnego pliku konfiguracyjnego stwarza pewne problemy (o czym za chwilę):

    cat << EOF > /etc/pam.d/suphp
    auth sufficient pam_permit.so
    session required pam_limits.so conf=/usr/local/suphp/etc/security/limits.conf
    session required pam_permit.so
    EOF

  3. Konfigurujemy limity dotyczące liczby procesów (tak, serwer uległ \”trzynastu znakom\”). Dedykowany plik konfiguracyjny rozwiązuje problem z sytuacją, w której konta użytkowników nie posiadają żadnej wspólnej grupy – w przypadku ustawienia limitów dla wszystkich (*), nie ma możliwości podniesienia ich dla konkretnego użytkownika/grupy (co powoduje problemy z działaniem usług czy administrowaniem serwerem):

    cat << EOF > /usr/local/suphp/etc/security/limits.conf
    * soft nproc 20
    * hard nproc 20
    EOF

  4. Rekompilujemy suPHP i dodajemy \”pam_service=suphp\” do sekcji global w jego pliku konfiguracyjnym.

Debian – reset hasła root serwera MySQL

Niestety często przejmując pod opiekę serwer, bądź jedną z usług brakuje części haseł dostępowych do uprzywilejowanych użytkowników. W tym przypadku podobny problem napotkaliśmy z serwerem baz danych MySQL. Poniżej publikujemy procedurę postępowania w tym przypadku w dystrybucji Debian.

Droga na skróty – debian-sys-maint

Zanim przystąpimy do ustawienia nowego hasła użytkownika root, a korzystamy z pochodzącego z repozytorium apt pakietu warto sprawdzić, czy użytkownik systemowy \”debian-sys-maint\” którego poświadczenia znajdziemy w /etc/mysql/debian.cnf nie ma wystarczających uprawnień. W domyślnych ustawieniach jego dane powinny wystarczyć nam do zmiany hasła bądź wykonania niezbędnych czynności administracyjnych

Ostatnia szansa – reset hasła MySQL

Aby dokonać zmiany hasła nie posiadając wystarczających uprawnień musimy mieć dostęp do użytkownika root samego serwera. W kolejnych krokach uruchomimy MySQL w trybie, w którym każdemu połączeniu zostaną przypisane pełne uprawnienia – w tym do zmiany hasła roota.

  1. Zatrzymujemy serwer MySQL:
    service mysql stop
  2. Uruchamiamy serwer MySQL bez sprawdzania poświadczeń oraz bez zdalnych połączeń.
    /usr/sbin/mysqld –basedir=/usr –datadir=/var/lib/mysql –user=mysql –pid-file=/var/run/mysqld/mysqld.pid –skip-external-locking –port=3306 –socket=/var/run/mysqld/mysqld.sock –skip-grant-tables –skip-networking
  3. W drugiej sesji SSH logujemy się na serwer MySQL i dokonujemy zmiany hasła roota, przeładowujemy uprawnienia. Kroki te możemy także wykonać przez phpMyAdmin logując się z dowolnym hasłem.
    # mysql -u root
    mysql> UPDATE mysql.user SET Password=PASSWORD(\’Nowe Hasło\’) WHERE User=\’root\’;
    mysql> FLUSH PRIVILEGES;
    mysql> exit
  4.  W tej samej sesji wyłączamy serwer MySQL (nie reaguje na CTRL+C), uruchamiamy go w normalnym trybie
    # kill $(cat /var/run/mysqld/mysqld.pid)
    # service mysql start
  5. Najważniejszy krok – zapisujemy bezpiecznie nowe hasło. W naszej do generowania, przechowywania i współdzielenia haseł korzystamy z darmowego oprogramowania Keepass

 

Symantec Backup Exec 2010 z technologią deduplikacji danych

\"\"

Firma Symantec zaprezentowała Backup Exec 2010 – nową wersję rozwiązania do tworzenia kopii zapasowych i odzyskiwania danych. Oprogramowanie oferuje zintegrowane technologie deduplikacji oraz archiwizowania danych. Jest to pierwsze rozwiązanie do backupu, które pozwala na szczegółowe odzyskiwanie danych z Microsoft Exchange, SQL i Active Directory z jednoprzebiegowej kopii zapasowej w środowiskach VMware oraz Hyper-V. Do Backup Exec 2010 dodano też obsługę Microsoft Windows 2008 R2, Hyper-V R2, Exchange 2010, Windows 7 i VMware vSphere 4.0.

Według firmy analitycznej IDC, pojemność pamięci masowej rośnie o 48-50 proc. każdego roku, przez co coraz więcej danych jest narażonych na ryzyko uszkodzenia, a proces usuwania skutków awarii znacznie się wydłuża. W rzeczywistości nawet 70 procent danych jest zduplikowanych i nikt z nich nie korzystał przez ponad więcej niż 90 dni. Przedsiębiorstwa, które wdrożą zintegrowane rozwiązanie do deduplikacji i archiwizacji danych, mogą zaoszczędzić 20-40 proc. kosztów
pamięci masowej, a także łatwo odnajdować i przywracać krytyczne informacje, kiedy tylko ich potrzebują.

Zródło: Symantec

Porada dnia: Instalacja UPS\’a APC na Debianie Lenny.

1. Opis sytuacji:

1. Serwer Debian Lenny
2. APC Smart UPS 1500

2. Instalacja:

W pierwszej kolejności podłączamy UPS\’a do serwera za pomocą kabla USB.

Aktualizujemy repozytoria:

apt-get update

Instalujemy niezbędne pakiety:

apt-get install apcupsd

2.1 Konfiguracja apcupsd.conf

W pliku konfiguracyjnym:

nano /etc/apcupsd/apcupsd.conf

zamieniamy:

UPSCABLE smart

na

UPSCABLE usb

zamieniamy:

UPSTYPE apcsmart
DEVICE /dev/ttys0

na:

UPSTYPE usb
DEVICE

2.2 Konfiguracja apcupsd

W pliku konfiguracyjnym /etc/default/apcupsd

nano /etc/default/apcupsd

zamieniamy:

isonfigured no

na:

isonfigured yes

3. Uruchamiamy usługę apcupsd oraz sprawdzamy połączenie:

/etc/init.d/apcupsd start
apcaccess

Konfiguracja pnp4nagios w systemie Debian

Konfiguracja pnp4nagios w systemie Debian

Index

Krok 1. Sprawdzenie czy pliki w folderach istnieją:
Na początek upewnić się czy plik process_perfdata.cfg oraz rra.cfg znajduje się w folderze /usr/local/pnp4nagios/etc/ . Jeżeli nie, najlepiej znaleźć pliki w katalogu pnp4nagios-0.6.2 (process_perfdata.cfg-sample oraz rra.cfg-sample), zmienić ich nazwy (bez ‘-sample’) i skopiować do powyższego folderu (/usr/local/pnp4nagios/etc/). Dodatkowo upewnić się przy process_perfdata.pl znajduje się w folderze, gdzie znajdują się wszystkie pluginy z Nagios (w moim przypadku /usr/local/nagios/libexec/), jeżeli nie znajdujemy plik process_perfdata.pl-sample, zmieniamy nazwę na process_perfdata.pl i umieszczamy go w folderze /libexec.

Krok 2. Kolejnym krokiem jest edycja pliku konfiguracyjnego nagios.cfg. Edycji i zmian należy dokonać według poniższych wartości:

process_performance_data=1
service_perfdata_file=/usr/local/pnp4nagios/var/service-perfdata
service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\\tTIMET::$TIMET$\\tHOSTNAME::$HOSTNAME$\\tSERVICEDESC::$SERVICEDESC$\\tSERVICEPERFDATA::$SERVICEPERFDATA$\\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\\tHOSTSTATE::$HOSTSTATE$\\tHOSTSTATETYPE::$HOSTSTATETYPE$\\tSERVICESTATE::$SERVICESTATE$\\tSERVICESTATETYPE::$SERVICESTATETYPE$
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=15
service_perfdata_file_processing_command=process-service-perfdata-file
host_perfdata_file=/usr/local/pnp4nagios/var/host-perfdata
host_perfdata_file_template=DATATYPE::HOSTPERFDATA\\tTIMET::$TIMET$\\tHOSTNAME::$HOSTNAME$\\tHOSTPERFDATA::$HOSTPERFDATA$\\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\\tHOSTSTATE::$HOSTSTATE$\\tHOSTSTATETYPE::$HOSTSTATETYPE$
host_perfdata_file_mode=a
host_perfdata_file_processing_interval=15
host_perfdata_file_processing_command=process-host-perfdata-file

 

Krok 3. Edycja pliku konfiguracyjnego templates.cfg (w moim przypadku uzupełnienie o następujące wpisy):

define host {
name host-pnp
register 0
action_url /pnp4nagios/graph?host=$HOSTNAME$&srv=_HOST_
}
define service {
name srv-pnp
register 0
action_url /pnp4nagios/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
}


Szczególną uwagę przywiązujemy do ścieżki, która zaczyna się od /pnp4nagios/…. Należy pamiętać o tym, że ścieżka może być inna co zależy od ustawień instalacji.

Krok 4. Dodajemy w definicji hostów i usług następujące wiersze (należy zwrócić uwagę na ścieżki!):

Dla hosta:

action_url /nagios/pnp/index.php?host=$HOSTNAME$


Dla usługi:

action_url /nagios/pnp/index.php?host=$HOSTNAME$&srv=$SERVICEDESC$

 

W moim przypadku wpiszemy na dole przed } to:

define service{
name generic-service ; The \’name\’ of this service template
active_checks_enabled 1
passive_checks_enabled 1
parallelize_check 1
obsess_over_service 1
check_freshness 0
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 1
failure_prediction_enabled 1
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
notification_interval 0
is_volatile 0
check_period 24×7
normal_check_interval 5
retry_check_interval 1
max_check_attempts 4
notification_period 24×7
notification_options w,u,c,r
contact_groups admins
register 0
action_url /pnp4nagios/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
}

 

define host{
name ogolnie-host ; The \’name\’ of this service template
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 1
failure_prediction_enabled 1
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
check_command check-host-alive
max_check_attempts 10
notification_interval 0
notification_period 24×7
notification_options d,u,r
contact_groups admins
register 0
action_url /pnp4nagios/graph?host=$HOSTNAME$
}

 

Na poniższym rysunku zaznaczyłem te dwa odnośniki:

[singlepic id=28 w=320 h=240 float=center]

Krok 5. Edytujemy plik konfiguracyjny command.cfg i uzupełniamy o następujące wiersze:

define command {
command_name process-service-perfdata
command_line /usr/bin/perl /usr/local/nagios/libexec/process_perfdata.pl
command_line /usr/bin/printf \”%b\” \”$LASTSERVICECHECK$\\t$HOSTNAME$\\t$SERVICEDESC$\\t$SERVICESTATE$\\t$SERVICEATTEMPT$\\t$SERVICESTATETYPE$\\t$SERVICEEXECUTIONTIME$\\t$SERVICELATENCY$\\t$SERVICEOUTPUT$\\t$SERVICEPERFDATA$\\n\” >> /usr/local/nagios/var/service-perfdata.out
}
define command {
command_name process-host-perfdata
command_line /usr/bin/perl /usr/local/nagios/libexec/process_perfdata.pl -d HOSTPERFDATA
command_line /usr/bin/printf \”%b\” \”$LASTHOSTCHECK$\\t$HOSTNAME$\\t$HOSTSTATE$\\t$HOSTATTEMPT$\\t$HOSTSTATETYPE$\\t$HOSTEXECUTIONTIME$\\t$HOSTOUTPUT$\\t$HOSTPERFDATA$\\n\” >> /usr/local/nagios/var/host-perfdata.out
}

define command{
command_name process-service-perfdata-file
command_line /usr/local/nagios/libexec/process_perfdata.pl –bulk=/usr/local/pnp4nagios/var/service-perfdata
}

define command{
command_name process-host-perfdata-file
command_line /usr/local/nagios/libexec/process_perfdata.pl –bulk=/usr/local/pnp4nagios/var/host-perfdata
}

 

stare wpisy dezaktywujemy, czyli dodajemy ‘#’ przed wierszami:

#\’process-host-perfdata\’ command definition
#define command{
# command_name process-host-perfdata
# command_line /usr/bin/printf \”%b\” #$LASTHOSTCHECK$\\t$HOSTNAME$\\t$HOSTSTATE$\\t$HOSTATTEMPT$\\t$HOSTSTATETYPE$\\t$HOST#EXECUTIONTIME$\\t$HOSTOUTPUT$\\t$H$
# }
# \’process-service-perfdata\’ command definition
#define command{
# command_name process-service-perfdata
# command_line /usr/bin/printf \”%b\” #\”$LASTSERVICECHECK$\\t$HOSTNAME$\\t$SERVICEDESC$\\t$SERVICESTATE$\\t$SERVICEATTEMPT$\\t#$SERVICESTATETYPE$\\t$SERVICEEX$
# }

 

Krok 6. Czas na weryfikacje instalacji poprzez plik, który jest dostarczony w pakiecie z pnp4nagios (plik o nazwie ‘verify_pnp_config’):

cd pnp4nagios-0.6.2/contrib/
chmod 755 verify_pnp_config
./verify_pnp_config -m bulk


Dokładniejszy opis znajduje się pod linkiem:
verify_pnp_config

Jeżeli wszystko się zgadza możemy podziwiać efekty naszej pracy:

[singlepic id=29 w=320 h=240 float=center]

Dodatkowo:
wykonać polecenie:

a2enmod rewrite


oraz wyłączyć magic_quotes (magic_qoutes= Off) w pliku php.ini