DD-WRT nie odpowiada na ping?

Jeżeli chcemy zmusić nasze dd-wrt do odpowiedzi ping to należy dodać regułę na firewallu.

Zakładka Administration -> Commands -> Firewall

iptables -A OUTPUT -p icmp --icmp-type echo-reply -d 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -d A.B.C.D -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j DROP

Zapisujemy i restartujemy urządzenie.

Nowa seria dysków do serwerów NAS – Western Digital RED

Do oferty dysków WD dołączyła dedykowana dla pamięci sieciowych w domach i małych firmach 3.5 calowa seria WD Red zaprojektowana specjalnie dla systemów NAS, wyposażonych w nowatorską technologię NASware.
Dyski te charakteryzują się stosownie dużą pojemnością – od 1 do 3 TB, szybkim interface\’m SATA 6Gb/s oraz koniecznym przy dostępie wielu użytkowników cache wielkości 64MiB.
Dzięki niskiemu zużyciu energii, przystosowaniu do pracy ciągłej w środowiskach wielodyskowych oraz bezpłatnej, całodobowej infolinii technicznej stanowią idealne medium przechowywania danych w sieci lokalnej pozwalając na zapewnienie bezpieczeństwa i dostępności istotnych danych, stanowiąc doskonały kompromis między przyjaznym dla środowiska dyskom z serii WD Green oraz wysokowydajnym WD Black, zachowując jednocześnie doskonałą cenę i solidność dysków WD Blue.

Od dziś, dyski te znajdują się również w ofercie naszego sklepu internetowego w cenach od 350zł netto:
https://sklep.aboo.pl/dysk-twardy-wd-red-3-5-1tb-sata-600-64mb-cache.html
https://sklep.aboo.pl/dysk-twardy-wd-red-3-5-2tb-sata-600-64mb-cache.html
https://sklep.aboo.pl/dysk-twardy-wd-red-3-5-3tb-sata-600-64mb-cache.html

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.

Katalog stron Easydir na hostingu Aboo

Katalog stron Easydir oparty jest na frameworku Kohana i bazach SQLite.

Podstawowym wymaganiem Kohany jest choć-trochę-obsługująca programowanie obiektowe wersja interpretera PHP: co najmniej 5.2.
I na tym kompatybilność się kończy – ze względu na wiek skryptu / kunszt programisty, modele aplikacji zawierają odwołania do przestarzałych w domyślnie włączonej wersji PHP (5.3) funkcji z rodziny eregi.
Fakt ten nie objawia się: katalog silently fails, w porywach wyświetla Unknown PHP Error.

Biorąc pod uwagę podstawowe zastosowanie opisywanego kodu – pozycjonowanie stron WWW, nie namawiam nikogo na zastąpienie ich wyrażeniami regularnymi i funkcjami z rodziny preg, a zaproponowane rozwiązanie jest najprostszym z możliwych:

Zgodnie z bazą wiedzy, w pliku .htaccess używamy gotowego makra, zmieniając wersję interpretera:

Use php 52

Katalog znów żyje!

Instalacja certyfikatu SSL w DirectAdmin

Domyślnie DirectAdmin nie korzysta z SSL przy połączeniach do panelu administracyjnego.

Aby włączyć obsługę SSL oraz wygenerować certificate signing request, zastąpić samopodpisane certyfikaty wystawionymi np. przez StartSSL.com. Na serwerze s5.aboo.pl użyty został certyfikat Comodo Essential SSL:

  1. Tworzymy nowy klucz prywatny oraz CSR:

    openssl req -nodes -newkey rsa:2048 -keyout s5.aboo.pl.key -out s5.aboo.pl.csr

  2. Używając CSR generujemy certyfikat na stronie wystawcy. Jeżeli jesteśmy pytani o typ serwera, wybieramy Apache + mod_ssl, dzięki czemu otrzymamy w formacie PEM
  3. Otrzymane od wystawcy pliki umieszczamy w /usr/local/directadmin/conf wraz z wcześniej wygenerowanym kluczem (-keyout …)
  4. Edytujemy plik directadmin.conf, dodając lub modyfikując linie:

    SSL=1 <- włączamy SSL ssl_redirect_host=s5.aboo.pl <- ważne! ustawiamy adres na który klient jest odsyłany, jeżeli połączy się z http:// zamiast https:// cacert=/usr/local/directadmin/conf/cacert.pem <- certyfikat (\"nasz\") cakey=/usr/local/directadmin/conf/cakey.pem <- klucz prywatny carootcert=/usr/local/directadmin/conf/caroot.pem <- certyfikaty pośrednie (CA)

  5. Bardzo, bardzo ważne – ustawiamy odpowiednie uprawnienia na plik z kluczem:

    chown diradmin:diradmin cakey.pem
    chmod 400 cakey.pem

  6. Restartujemy usługę DirectAdmin:

    service directadmin restart