K-NET s.c.

Budowa serwera SFTP na bazie SSH i Debiana

Jak powszechnie wiadomo nie wynaleziono jeszcze bardziej popularnej usługi do transferu plików niż FTP. Być może większość administratorów wolałaby korzystać z innych rozwiązań ale tak się składa, że znają prawie wszyscy użytkownicy i to oni z reguły wymuszają stosowanie FTP. Podstawowy problem w tym przypadku to brak szyfrowania transmisji co przede wszystkim oznacza przesyłanie haseł jawnym tekstem. Jednak mając gotowy serwer z Linuxem oraz dostępem zdalnym po SSH można pokusić się o przygotowanie serwera SFTP, który zachowując większość funkcji FTP będzie zabezpieczał odpowiednio nasze połączenia. Co więcej jeśli ktoś dotychczas korzystał z bardzo popularnych programów typu WinSCP czy FileZilla to zasadniczo nie powinien mieć żadnych problemów z korzystaniem z SFTP bowiem obsługa tego ostatniego została już zaimplementowana w tych windowsowych klientach. Zatem do dzieła.

Po pierwsze sprawdzamy czy obsługa SFTP została włączona w konfiguracji serwera OpenSSH. Plik /etc/ssh/sshd_config powinien zawierać wpis:

Subsystem sftp internal-sftp

Teraz, na końcu pliku możemy dodać sekcje dla nowego konta z dostępem SFTP:

Match User KontoSFTP
  ChrootDirectory /home
  AllowTCPForwarding no
  X11Forwarding no
  ForceCommand internal-sftp

Oczywiście zakładam, że wcześniej założyliśmy sobie takie konto w systemie. Po ponownym uruchomieniu serwera SSH wszystko powinno zacząć działać… oprócz dwóch drobnostek.

Na pewno warto zadbać aby użytkownik KontoSFTP nie miał dostępu shellowego do systemu. W tym celu musimy zmienić mu domyślny shell. Najpierw sprawdzamy czy możemy użyć shella typu sftp-server:

cat /etc/shells

Jeśli nie zostanie wyświetlona nazwa sftp-server powinniśmy użyć polecenia:

echo '/usr/lib/openssh/sftp-server' >> /etc/shells

Teraz możemy już zmodyfikować konto naszego użytkownika:

usermod -s /usr/lib/openssh/sftp-server KontoSFTP

Druga sprawa to powinniśmy zmienić prawa dostępu do tych podkatalogów w /home, do których chcemy zabezpieczyć dostęp. W ten sposób nasz użytkownik nie będzie mógł zwiedzać innych podkatalogów. Dla każdego z zabezpieczanych katalogów należy wydać polecenie:

chmod 700 /home/NazwaZabezpieczanegoKatalogu

Po wykonaniu powyższych czynności możemy cieszyć się nowym serwerem SFTP. Powyższe uwagi dotyczą rzecz jasna mojego ulubionego Debiana.

MG

update.rc-d vs rc.local vs @reboot

Tym razem chciałem przedstawić krótki i treściwy wpis na temat uruchamiana aplikacji w trakcie startu serwerowego systemu operacyjnego. Sprawa dotyczy mojego ulubionego Debiana. Właściwie najabardziej elegancką i zgodną z regułami metodą jest umieszczenie skryptu startowego w katalogu /etc/init.d/, nadanie mu praw wykonywalnych i wywołanie polecenia:

update-rc.d nasz_skrypt defaults 99

Niemniej z różnych przyczyn nie zawsze się to udaje. Trzeba podejść do tematu inaczej. Od razu zaznaczam, że poniższe metody, jakkolwiek spełniające swój cel, są po prostu bardzo nieeleganckie i nie świadczą najlepiej o umiejętnościach administratora. Czasami jednak trzeba się ugiąć – chociażby pod presją czasu.

Druga metoda polega na dopisaniu skryptu do pliku /etc/rc.local. Generalnie tym sposobem można rozwiązać dużo problemów ale osobiście stosuje go tylko doraźnie. Polecam to jako rozwiązanie tymczasowe.

Trzecia metoda, kiedy zawiodą dwie poprzednie, to umieszczenie skryptu startowego w cronie systemowym dla konta root. Wywołujemy go poleceniem:

crontab -e

a następnie na końcu pliku dopisujemy linijkę:

@reboot /ścieżka_dostępu/nasz_skrypt

Od tego momentu, za każdym razem podczas uruchamiania się systemu, automatycznie będzie wykonywał się skrypt. Mało elegancko ale skutecznie.

MG

Jak zmienić UID i GID w Linuxie

Przenoszenie kont użytkowników między serwerami Debian jest czynnością prostą i bezpieczną. W zasadzie wystarczy wykonać 3 podstawowe czynności:

1. Skopiować odpowiednie grupy z pliku /etc/group.
2. Skopiować odpowiednich użytkowników z pliku /etc/passwd.
3. Skopiować hasła powyższych użytkowników z pliku /etc/shadow.

Wymienione pliku są tekstowe zatem sprawdzi się metoda copy-paste. Oczywiście na koniec trzeba skopiować katalogi domowe użytkowników (np. używając tar z opcjami cvzf) a potem rozpakować na serwerze docelowym (tar xvzf). Jeśli ktoś woli można skorzystać z synchronizacji między serwerami za pomocą rsync.

Problem może pojawić się wtedy kiedy na docelowym serwerze istnieją już konta posiadające identyfikatory systemowe UID (user ID) i GID (group ID) i nie możemy wprost kopiować linii plików konfiguracyjnych aby uniknąć sytuacji, w której np. dwa konta posiadają ten sam UID. Wówczas przed kopiowaniem trzeba zmienić UID i GID na serwerze źródłowym. Czy jest to proste? Jak wszystko w Linuxie… Poniżej zamieszczam polecenia pozwalające przygotować się do całego procesu:

usermod -u <NowyUID> <Login> 
groupmod -g <NowyGID> <Grupa>
find / -user <StaryUID> -exec chown -h <NowyUID> {} \;
find / -group <StaryGID> -exec chgrp -h <NowyGID> {} \;
usermod -g <NowyGID> <Login>

MG

ssl error weak server ephemeral dh key

Od miesiąca, po zainstalowaniu najnowszej aktualizacji przeglądarki Firefox można napotkać błąd połączenia z niektórymi szyfrowanymi stronami (chodzi o protokół HTTPS):

ssl error weak server ephemeral dh key

W dużym skrócie wynika to stąd, że pojawiła się nowa metoda ataku o nazwie Logjam, która wymusza zmiane długości klucza szyfrującego do 512 bitów (w miejsce np. 2048). Jak powszechnie wiadomo osłabia to znacząco odporność szyfrowanego kanału transmisji. Autorzy Firefoxa słusznie postanowili wzmocnić swoją przeglądarkę uniemożliwiając połączenie ze serwerami podatnymi na taki mechanizm. Z jednej strony jest to rozsądne działanie ale z drugiej co mają zrobić np. użytkownicy domowych urządzeń sieciowych zarządzanych przez HTTPS. O ile w przypadku serwerów zawsze można liczyć na administratorów o tyle domowy router wcale nie musi dostać wsparcia od producenta w postaci nowego firmware’u. Można wybrać inną przeglądarke ale myślę, że za miesiąc pozostałe również zablokują wspomniane połączenia. Okazuje się jednak, że w Firefoxie można wyłączyć to zabezpieczenie. Nie namawiam nikogo aby robił to na stałe. Poniższe kroki proponuję stosować wyłącznie tymczasowo np. aby skonfigurować swój router domowy:

• Jako adres w Firefoxie podajemy „about:config”
• Wyszukujemy paramter „security.ssl3.dhe_rsa_aes_128_sha” i ustawiamy jego wartość na „false”
• Wyszukujemy parametr „security.ssl3.dhe_rsa_aes_256_sha” i ustawiamy jego wartość na „false”

Pamiętajmy jednak o tym, żeby na koniec przywrócić wartość „true” dla wspomnianych parametrów po zakończeniu konfiguracji przykładowego routera.

MG

Wymiana dysku na SSD

Jeszcze dwa lata temu zastanawiałem się czy całkowite zrezygnowanie z tradycyjnych dysków na rzecz SSD w moim laptopie będzie dobrym krokiem. Znajomi głównie straszyli wielką katastrofą, utratą danych spowodowaną przez niesprawdzoną technologię. Minęło sporo czasu i okazało się, że technologia ma się całkiem dobrze, nie ma spektakularnych katastrof a w nowym sprzęcie zaczynają się pojawiać wyłącznie dyski SSD. Dlatego zdecydowałem się na wymiane dysku. Generalnie rzecz biorąc jest to dość droga operacja. Nie ma się co oszukiwać ceny są jeszcze wysokie. Niemniej postanowiłem zmienić HDD 750 GB na SSD 512 GB. Producent dostarczył wraz z dyskiem specjalną wersję Acronis TrueImage, która miała uczynić cały proces bezbolesnym. Miała, gdyż nie przewidziano, że można mieć 2 systemy operacyjne (Ubuntu, Windows 7) oraz 6 partycji różnego typu (NTFS, EXT3, EXT4). Efekt był taki, że po sklonowaniu dysku nic nie działało prawidłowo. Pobieżne przejrzenie materiałów w sieci utwierdziło mnie w przekonaniu, że są duże problemy z takimi operacjami. Niemniej postanowiłem spróbować starej i sprawdzonej przeze mnie wielokrotnie metody. W tym celu potrzebowałem jedynie SystemRescueCD (http://www.sysresccd.org/SystemRescueCd_Homepage), drugiego kabla SATA (żeby podłączyć dwa dyski na raz) oraz trochę spokoju.

SystemRescueCD zawiera wszystkie potrzebne narzędzia a przede wszystkim GParted (http://gparted.sourceforge.net/), który jest bardzo łatwy w użyciu i pozwala skopiować całe partycje na nowy dysk wraz ze zmianą ich rozmiaru. Należy pamiętać, żeby odwzorować flagę partycji startowej za pomocą menu edycji partycji (opcja 'Manage flags on …’). Druga bardzo ważna czynność to skopiowanie MBR. W tym przypadku należy skorzystać z polecenia:

 dd if=/dev/sdX of=plik_mbr.img bs=512 count=1

które zapisze zawartość MBR dysku klonowanego w pliku 'plik_mbr.img’. Przy odtwarzaniu MBR na nowym dysku musimy pamiętać, że jeżeli zmienialiśmy rozmiary partycji (tak jak w opisywanym przypadku) to powinniśmy użyć polecenia:

dd if=plik_mbr.img of=/dev/sdX bs=446 count=1

w przeciwnym razie możemy odtworzyć cały obszar:

dd if=plik_mbr.img of=/dev/sdX bs=512 count=1

I w zasadzie to wszystko. Opisana metoda działa niezawodnie a co ważniejsze pozwala cieszyć się zauważalnym wzrostem wydajności naszego komputera.

MG

BulletProof Security

Zabezpieczanie stron zbudowanych w oparciu o platforme WordPress jest czynnością, która powinna wejść w nawyk każdemu autorowi. Dotyczy to zresztą nie tylko WordPressa ale również Joomli i Drupala. Wiem, że jednym z głównych argumentów za wyższością dwóch ostatnich CMS-ów jest ich większe bezpieczeństwo ale nie ma co zaprzeczać, że ostatnio WordPress stał się bardzo popularny i stale powiększa się grono jego użytkowników. Poza tym nie ma co się oszukiwać bo stara prawda głosi, że każdy system jest tak bezpieczny jak jego administrator. Zatem krótko i na temat – jeżeli nie jesteś super administratorem, nie chesz zajmować się konfiguracją plików .htaccess, chcesz po prostu komfortowo, bez zbędnych problemów prowadzić bloga lub po prostu swoją stronę www, to jako jedną z pierwszych zainstaluj wtyczkę BulletProof Security. Nie ma ona może zbyt przyjaznego interfejsu i wymaga poświęcenia około 30 minut na konfigurację ale każda z nich to bardzo dobrze spędzony czas! Nie będę dalej opisywał jej możliwości bo przecież każdy może to sprawdzić sam. A na prawdę warto.

WordPress – włamanie w celu rozsyłania spamu (Apache+PHP+Postfix)

WordPress jako bardzo popularne narzędzie jest często obiektem ataków w celu przejęcia zawartości strony. Podmiana treści serwisu przez hackera jest widocznym skutkiem złamania zabezpieczeń. Sama w sobie nie jest jednak tak groźna jak np. wykorzystanie naszego serwera do rozsyłania spamu (co może spowodować umieszczenie go na czarnych listach). Najczęściej atakujący starają się umieścić w strukturze katalogów serwisu przygotowane skrypty PHP (w formie plików), które następnie wykorzystują do wysyłania maili. Co zrobić, żeby zabezpieczyć się przed tą formą ataku?

Przede wszystkim konieczne jest wykonanie 2 czynności: (a) ograniczenie zainstalowanych motywów do niezbędnego minimum oraz (b) usunięcie wszystkich zbędnych wtyczek (bywają takie, które z powodu słabej jakości kodu umożliwiają natychmiastowy dostęp do serwera). Kolejną rzeczą jest uniemożliwienie przesłania spreparowanego zapytania do naszego serwera. Absolutnym minimum jest przygotowanie pliku .htaccess z odpowiednimi regułami. Jeśli chcemu pójść na skróty można skorzystać ze zbioru gotowych reguł: http://perishablepress.com/5g-blacklist-2013/. W zasadzie dzięki tym dwóm prostym krokom uzyskamy przynajmniej minimalny poziom zabezpieczeń strony w WordPressie. Dodam jeszce, że na końcu .httaccess można  dopisać linijkę

RewriteRule ^(php\.ini|\.htaccess) - [NC,F]

która zabezpieczy nas przed modyfikacją zawartości plików index.php i właśnie .htaccess co z kolei uniemożliwi np. przekierowanie wywołań naszej strony na inny serwer www.

Jednak w jaki sposób powstrzymać doraźnie atak na nasz serwer (jeśli już doszło do niego). Przy założeniu, że korzystamy z domyślnej konfiguracji Apache trzeba zatrzymać wysyłanie poczty z konta www-data. Edytujemy plik /etc/postfix/main.cf i dodajemy na końcu wiersz

authorized_submit_users = !www-data, static:all

Natstępnie wczytujemy nową konfiguracje serwera poczty:

/etc/init.d/postfix reload

Teraz musimy wyczyścić kolejkę maili oczekujących na nadanie:

postsuper -d ALL

Przechodzimy do najbardziej monotonnej częsci całego procesu. Edytujemy plik /etc/php5/apache2/php.ini, żeby znaleźć (i odkomentować lub zmienić na postać przedstawioną poniżej) fragment:

mail.add_x_header = On
mail.log = /var/log/phpmail.log

Pierwsza spowoduje dodanie nagłówka do wszystkich maili nadawanych z wykorzystaniem PHP a druga włączy logowanie informacji na ten temat (do pliku /var/log/phpmail.log). Teraz pozostaje nam żmudne przeglądanie pliku z logami w celu śledzenia historii ataku oraz usuwania niepożądanych plików (zawierających np. skrypty PHP), które są wykorzystywane do rozsyłania spamu.

MG

rsync czyli kopie szybko i bezproblemowo

rsync to narzędzie dobrze znane i szeroko stosowane. Ten niezwykle wygodny w użyciu program pozwala na synchronizowanie zawartości między zasobami w niezawodny sposób. Dzięki kopiowaniu bloków informacji w miejsce całych jednostek np. plików, algorytm kopiowania jest bardzo szybki. Dodatkowo rsync sprawdza się na zawodnych łaczach, gdzie dostępne pasmo potrafi spaść nagle do kilku kb/s. Nie ukrywam, że jest to moja ulubiona metoda tworzenia kopii dlatego chciałem pokazać jak szybko przygotować rsync dla dwóch serwerów w środowisku Debian Linux. Jeden niech będzie serwerem produkcyjnym, drugi zaś serwerem kopii.

Zaczynamy od instalacji aplikacji na obu komputerach:

apt-get install rsync

Następnie tworzymy specjalne konto na serwerze kopii:

adduser zapasowe

Kolejnym krokiem jest wygenerowanie certyfikatu na serwerze produkcyjnym i skopiowanie go na serwer kopii:

ssh-keygen -t dsa

ssh-copy-id -i .ssh/id_dsa.pub zapasowe@serwer_kopii

Możecie wierzyc lub nie ale to już prawie wszystko! Teraz wystarczy wywołanie polecenia na serwerze produkcyjnym:

rsync -aogrvzP --delete -e ssh /wazne zapasowe@serwer_kopii:kopie

Spowoduje ono utworzenie dokładnej kopii zawartości katalogu wazne na serwerze kopii w katalogu kopie. Prosto i skutecznie. Aha, powyższe polecenie możemy umieścić w pliku crontab, automatyzując tym samym cały proces.

MG

Ultra Fast Boot zbyt szybki?

Już od dłuższego czasu większość sprzedawanych płyt głównych wyposażona jest w opcje Ultra Fast Boot. W połączeniu z UEFI i Windows 8 daje ona możliwość bardzo szybkiego startu komputera, nawet na poziomie kilku sekund. Wyzwaniem jest jednak dostanie się do ustawień BIOS po jej włączeniu. W praktyce bootowanie odbywa się tak szybko, że nie można liczyć na ekran POST i wciśnięcie klawisza F2 lub DEL. Użytkownicy Windows otrzymują wraz ze sterownikami płyty głównej aplikację narzędziową. Pozwala ona uruchomić komputer z wejściem do BIOS przy następnym przeładowaniu systemu. Co jednak mają zrobić właściciele Linkusów? Najczęściej można usłyszeć poradę brzmiącą mniej więcej – zdjąć obudowę i wyjąć na kilka sekund baterie podtrzymująca CMOS. Ewentulanie należu skorzystać z odpowiedniej zworki na płycie. Tak czy inaczej jest to operacja ryzykowna. Zakładając na przykład, że mieliśmy skonfigurowany software-RAID w BIOS, możemy sprawić sobie problem. Jednak jak zwykle istnieje dużo prostsze rozwiązanie. Być może nie jest ono oczywiste ale zazwyczaj sprawdza się. Skoro otworzyliśmy już obudowe naszego komputera to wystarczy odpiąć dyski twarde. Po uruchomieniu, BIOS wykryje zmiane konfiguracji i umożliwi bezpośrednio konfiguracje swoich parametrów. Korzystając z okazji wyłączamy opcję Ultra Fast Boot i zapisujemy ustawienia. Po wyłączeniu komputera i ponownym podłączeniu dysków możemy uruchomić system. Tym razem ekran POST powinien być już widoczny a my powinniśmy mieć zawsze szanse dostać się do naszych ustawień w BIOS.

MG

Konfigurowanie użytkowników systemowych na serwerze Samba w środowisku Active Directory

Praktyka związana z budowaniem sieci komputerowych w małych i średnich firmach pokazuje, że często jesteśmy zmuszeni tworzyć środowiska heterogeniczne, gdzie np. domena Active Directory AD współpracuje z linuksowym sewerem plików Samba SMB. Aby ten dość często spotykany tandem był w pełni funkcjonalny dobrze jest zintegrować bazę użytkowników AD z kontami dla serwera SMB. Nie chcę tutaj poruszać problemów związanych z samą konfiguracją po stronie Linuksa – jest to wielokrotnie omawione w sieci (jeden z najlepszych poradników howto można znaleźć pod tym adresem). Tym razem chciałbym pokazać jak rozdzielić na serwerze Debian użytkowników AD od systemowych.

W przypadku integrowania serwera plików z domeną mamy dwie możliwości:

• albo wszystkie konta będą przechowywane w katalogu Active Directory
• albo na serwerze linuksowym pozostawimy część natywnych kont systemowych

Osobiście zawsze wybieram tą drugą opcję, chociażby dlatego aby uniezależnić niektóre usługi systemowe od domeny. Takie podejście bywa często krytykowane, szczególnie przez zwolenników centralnego zarządzania. Niemniej jest spotykane i stosowane. Problem z opisywaną konfiguracją polega na tym, że łącząc nasz serwer z domeną musimy włączyć protokół uwierzytelniania Kerberos. Przy standardowej konfiguracji oznacza to, że wszyscy użytkownicy o identyfikatorze UID większym równym 1000, będą autoryzowani na poziomie domeny (oznacza to, że np. nie zadziałają prawidłowo polecenia passwd i useradd).

Jak zwykle w takich przypadkach istnieje wiele rozwiązań, o czym można przekonać się poszukując materiałów w sieci. Niemniej najprostszym i prawdopodobnie najszybszym będzie wyedytowanie pliku/etc/pam.d/common-password. Następnie należy zmienić wartość paramteru minimum_uid (która domyślnie wynosi 1000):

password requisite pam_krb5.so minimum_uid=2000

Powyższy wpis oznacza, że odtąd użytkownicy LDAP (którzy w tym przypadku są użytkownikami AD) mają identyfikatory UID zaczynające się od 2000, zaś lokalny administrator linuksowy może spokojnie operować na kontach systemowych.

MG