Archiwa tagu: linux

Instalacja i konfiguracja OpenVPN na serwerze VPS z CentOS 6

Ikona OpenVPN

Dwa dni zajęło mi uruchomienie OpenVPN z możliwością tunelowania na VPSie z CentOSem. Było to jednak dość ciekawe doświadczenie :). Wiedząc jednak, że nie prędko będę miał przyjemność zrobić to ponownie – napiszę o przebiegu instalacji. Może komuś poza mną się to jeszcze kiedyś przyda.

O tym, co daje nam tunelowanie i jakie profity za sobą niesie poczytacie w sieci. Największą zaletą jest korzystanie z tunelowania w otwartych sieciach (Hotspoty, otwarte wifi). W skrócie: połączenie jest szyfrowane do naszego serwera, i komunikujemy się z internetem tak jakby za jego pomocą a nie naszego urządzenia. Zakręcone, wiem.

Przygotowanie

Z rzeczy, które potrzebujemy na sam początek, to:

  1. Serwer z CentOSem w wersji 6 (na niej instalowałem program);
  2. Zainstalowane repozytoria Epel oraz RPMForge (opis tutaj).
Do prawidłowego działania na serwerze musi być uruchomiony moduł TUN/TAP. W celu jego włączenia skontaktuj się z dostawcą, albo zrób to za pomocą odpowiedniej opcji w panelu zarządzania.

Instalacja i aktualizacja WordPressa z SVN

Do dziś aktualizując WordPressa korzystałem z wbudowanego mechanizmu tego skryptu. Z poziomu panelu administracyjnego, a dokładniej za pomocą poniższego odnośnika

http://nasz.blog.pl/wp-admin/update-core.php

możliwe jest dokonanie aktualizacji skryptu, oraz jego komponentów do najnowszych wersji. Prosto i przyjemnie (nie ulega bowiem wątpliwości, że rozwiązanie to jest bardzo szybkie i niezwykle proste). Jednakże posiada pewną wadę. Albowiem skrypt po aktualizacji do nowszej wersji nie usuwa pozostałości po poprzedniej, starszej wersji. Dla przykładu: stara wersja, przed aktualizacją posiadała plik xxx.php, który w nowszej został usunięty, bo twórcy wyszli z założenia, że jest zbędny, a jego funkcjonalność dodali do pliku yyy.php. Co zatem dzieje się po aktualizacji ze zbędnym plikiem xxx.php? Ano nic. On tam sobie siedzi dalej, potulnie jak myszka i czeka. Czeka tak sobie… Nawet i kilka lat, sam nie wie po co, ale sobie czeka, aż kiedyś sami go usuniemy.

Ktoś mądry wskazał mi nową drogę. Dzięki niej w końcu rozwiązany został problem pozostałości po aktualizacji WordPressa, bowiem pliki nadpisywane są do najnowszej wersji, a te zbędne same mówią „pa, pa„. Na dodatek nie trzeba odprawiać jakiś specjalnych modlitw, czy innych obrządków, by to wszystko miało miejsce!


O hostingu (VPSie) słów kilka

Minął już rok czasu od chwili, gdy ”zmigrowałem” się na VPSa z dzielonego hostingu w linuxpl.com (o którym to złego słowa powiedzieć nie mogłem). Ciągle i niezmiennie korzystam z usług firmy Hostineuro.com z najmniejszego pakietu o parametrach:

2048MB RAM
40GB HDD space
1 IP address
1000GB bandwidth traffic
HyperVM control panel
Prices start at 9.95 € / month

W skrócie (dla tych, którym nie będzie chciało się czytać całości) wszystko jest super, zero padów, administrator jest niezmiennie sympatyczną i pomocną duszyczką, serwerownia również ok. Sumarycznie – nic, tylko brać.


Logowanie do SSH za pomocą klucza – generowanie kluczy w PuTTY

Dotychczas sam logowałem się do swojego serwera poprzez SSH z wykorzystaniem zwykłego hasła. Parę dni temu w związku z jednym zleceniem zainteresowałem się kluczami SSH, dzięki którym można również uzyskać dostęp do SSH. Zaleta jest taka, że nie musimy każdorazowo wpisywać hasła. Właściwie… w przypadku kluczy niezabezpieczonych hasłem (tzw. passphrase) nie musimy w ogóle podawać hasła. Wystarczy wskazać ścieżkę do klucza w programie, za pomocą którego łączymy się do naszego serwera (PuTTY, WinSCP, Filezilla, Total Commander…).

Dla własnego bezpieczeństwa odradzam „zabiegi” tworzenia kluczy bez passphrase. W razie niepowołanego dostępu do naszego dysku i kradzieży pliku z kluczem jesteśmy delikatnie powiedziawszy w czarnej dziurze. Warto więc podać hasło i zaszyfrować klucz. Dzięki odpowiednim programom możliwe jest jednorazowe podanie hasła, co znacząco upraszcza pracę. Ale o tym w dalszej części wpisu.

Zaletą SSH jest fakt, że możemy zdefiniować sposób dostępu do naszego serwera za pośrednictwem hasła, klucza,  czy też za pomocą protokołu Kerberos (który jest mi na chwilę obecną obcy). Możemy również dla użytkownika root zabronić dostępu za pośrednictwem hasła. Dzięki czemu będzie możliwe zalogowanie się na to konto jedynie za pomocą klucza, lub protokołu Kerberos. Dziś jednak skupimy się tylko i wyłącznie na kluczach i ich generowaniu za pomocą PuTTY .


Konfiguracja fail2ban na serwerze z CentOS/httpd

Osoby posiadające swoje własne serwery pewnie nie raz zwróciły uwagę na plik error_log serwera www (apache, httpd) oraz informacje w nim zawarte, jak np.:

[Sun Oct 09 14:19:27 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phpMyadmin
[Sun Oct 09 14:19:28 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phpMyAdmin
[Sun Oct 09 14:19:28 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phpmyAdmin
[Sun Oct 09 14:19:28 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phpmyadmin2
[Sun Oct 09 14:19:28 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/2phpmyadmin
[Sun Oct 09 14:19:29 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phpmy
[Sun Oct 09 14:19:29 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phppma
[Sun Oct 09 14:19:29 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/myadmin
[Sun Oct 09 14:19:29 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/MyAdmin
[Sun Oct 09 14:19:30 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/program

Z powyższych informacji można wywnioskować iż ktoś z PEWNEGO_IP próbował uzyskać dostęp do plików/katalogów, których nie ma na serwerze. Przeważnie są to jakieś boty, które przeszukują nasz serwer pod kątem panelu zarządzania bazą danych.

Dla zainteresowanych powiem, że powyższy wycinek z logów, który zamieściłem to tylko część. W danym dniu z jednego adresu IP w ciągu niemal 2 minut wywołanych zostało aż 154 odwołań do nieistniejących plików/katalogów.

Jak zatem bronić się przed tego typu atakami na nasz serwer i jego zasoby? Logicznym rozwiązaniem wydaje się dodanie reguły do zapory systemowej i zablokowanie delikwenta. Jednakże nie jesteśmy zalogowani 24/h na naszym serwerze i nie monitorujemy ciągle logów. Wypadałoby zatem w jakiś sposób zautomatyzować tę czynność.