Mechanizm blokowania w Xenie opiera się na wywołaniu skryptu zakładającego bądź usuwającego blokadę w formie pliku tekstowego i sterują nim trzy parametry z plik konfiguracyjnego /etc/xen/xend-config.sxp:

• (xend-domain-lock yes)
• (xend-domain-lock-path /path/to/lock/directory)
• (xend-domain-lock-utility domain-lock)

Pierwszy parametr włącza mechanizm blokowania, drugi precyzuje katalog z blokadami a trzeci pozwala na zmianę narzędzia blokującego (domyślnie demon xend używa skryptu /etc/xen/scripts/domain-lock).

Aby zabezpieczyć się przed przypadkowym równoczesnym uruchomieniu tej samej maszyny wirtualnej na dwóch hostach, wystarczy włączyć mechanizm blokowania, zamontować do wybranego katalogu udział sieciowy (NFS/Samba/OCFS/etc.), wskazać znajdujący się na nim katalog w zmiennej xend-domain-lock-path i przeładować konfigurację demona xend (/etc/ini.t/xend reload).  Od tej chwili demon xend będzie zakładał blokady dla wszystkich uruchamianych maszyn, a próba wystartowania tak zablokowanej maszyny na innym hoście zakończy się błędem.

Jeśli restartowanie maszyn wydaje się być niewygodne można ręcznie założyć blokady dla wszystkich już działających domen takim prostym poleceniem (przy założeniu że katalog na blokady to /mnt/vm/lock):

xm list --state=running |  tail +3 | cut -d' ' -f1 | while read domain
    do
    virsh dumpxml $domain | sed -n '2,3{s/.*>\(.*\)<.*/\1/;p}'
    done | xargs -n 2 echo | while read domain uuid
        do
        mkdir /mnt/vm/lock/$uuid &&  \
        /etc/xen/scripts/domain-lock -l -n $domain -i $uuid -p `hostname`  \
                /mnt/vm/lock/$uuid
        done

Blokowanie domen jest prostym rozwiązaniem i zabezpiecza przed uszkodzeniem dysków maszyn wirtualnych. Następnym krokiem może być skonfigurowanie klastra HA opartego o pakiet Pacemaker,  ale to już inna historia

Przepuszczanie i kontrolowanie ruchu HTTP nie jest specjalnie skomplikowane. Niestety (a może na szczęście) konstrukcja protokołu SSL uniemożliwia wykonanie tego samego z HTTPS’em. Tak długo jak nie stosuje się metod opartych o ‘man in the middle’ – możemy tylko kontrolować dostęp na poziomie portów i adresów IP. Jedyne co może zrobić Squid w przypadku transmisji HTTPS to zablokować ją lub otworzyć tunel i przepuścić. Standardowa polityka konfiguracji squida opiera się o zdefiniowanie tzw. „bezpiecznych portów” dla połączeń metodą CONNECT:

acl SSLPorts dport 443
acl CONNECT method connect
...
http_access deny CONNECT !SSLPorts
...

Tłumacząc na ludzki język, Squid blokuje próby zestawienia tunelu na porty inne niż określone w zmiennej SSLPorts. Ponieważ standardowo HTTPS działa na porcie TCP 443 – ten port jest z reguły przepuszczany bez większych obostrzeń. Można go więc wykorzystać do zbudowania tunelu SSH, jeśli mamy dostęp do serwera SSH działającego na porcie 443.

Serwer OpenSSH może słuchać na dowolnym porcie – w szczególności 443, wystarczy tylko ustawić dyrektywę ‘Port 443′ w pliku /etc/ssh/sshd_config i zrestartować serwer SSH.

Korkociągiem w prosiaka….

Jeśli już dysponujemy działającym gdzieś w sieci na porcie 443 serwerem SSH – możemy zbudować tunel przez proxy. Do tego celu można wykorzystać narzędzie corkscrew, które w imieniu klienta SSH połączy się z proxy i otworzy tunel. Aby oszczędzić sobie ustawiania parametru ProxyCommand przy każdym połączeniu SSH, można utworzyć plik ~/.ssh/.config z następującą zawartością:

ProxyCommand corkscrew IP.SQ.UI.DA 3128 %h %p

Na tym etapie można się już logować po SSH do naszego serwera i korzystać z możliwości tunelowania portów, zestawienia proxy SOCKS a nawet kanału VPN…

Proxy w tunelu przez proxy

Gdy już nam się uda oszukać proxy i przetunelować SSH „w świat”, możemy wykorzystać funkcjonalność SSH do zbudowania proxy SOCKS i przekierować przez nie praktycznie dowolny ruch. W tym celu podczas logowania na nasz serwer SSH należy dodać parametr -D, np.:

bash$ ssh -D1080  -p443  user@nasz.serwer.ssh -f -N

Dodatkowe parametry -f -N powodują zestawienie tunelu w tle – bez przejmowania powłoki na zdalnej maszynie. Teraz pozostaje tylko zmusić aplikacje do wykorzystania naszego proxy. W przypadku aplikacji, które nie posiadają obsługi proxy SOCKS przydatna jest biblioteka tsocks dostępna w podstawowych lub dodatkowych repozytoriach większości dystrybucji linuksowych. Po zainstalowaniu należy utworzyć plik konfiguracyjny /etc/tsocks.conf:

server = 127.0.0.1
server_port = 1080

Aby aplikacja wykorzystywała nasz serwer proxy należy ją uruchomić za pośrednictwem polecenia tsocks lub – w wersji bardziej „hakierskiej” z dyrektywą LD_PRELOAD;

bash$ LD_PRELOAD=/usr/lib/libtsocks.so.1 pidgin

Mało?

Od niedawna OpenSSH wspiera tworzenie tuneli VPN między wirtualnymi interfejsami TUN – jak znajdę czasopodwajacz to może przetestuję i opiszę…

serial --unit=0 --speed=9600
terminal --timeout=5 serial console

dzięki któremu będzie możliwy dostęp do menu GRUB’a przez port szeregoewy. Aby przekierować komunikaty jądra linuksa na port szeregowy należy do parametrów jądra dodać parametr console:

...
kernel /vmlinuz root=LABEL=/ console=ttyS0,9600 console=tty0
...

Na końcu pozostało jeszcze dodać linię w pliku inittab (najlepiej tam, gdzie skonfigurowane są konsole tekstowe):

S0:12345:respawn:/sbin/agetty -L 9600 ttyS0 vt102

Jądro Xen
W przypadku maszyn z jądrem Xen sprawa ma się trochę inaczej. Po pierwsze jako jądro w pliku konfiguracyjnym (dyrektywa kernel) jest podany xen a nie vmlinuz. Ten drugi (czyli właściwe jądro linuksa) jest podawany jako moduł (dyrektywa module). Po drugie w parawirtualizowanym systemie linuksowym pod kontrolą Xen’a zmieniają się nazwy urządzeń, i port szeregowy będzie się nazywał nie ttyS0 a xvc0. Poniżej wkleiłem przykładową konfigurację z jądrem Xen:

default 0
timeout 5
serial --unit=0 --speed=9600
terminal --timeout=10 serial consoletitle Xenpae - SLES10SP2
root (hd0,0)
kernel /xen-pae.gz console=vga,com1 com1=9600
module /vmlinuz-xenpae console=xvc0,9600 console=tty0 root=/dev/system/root
module /initrd-xenpae

Po skonfigurowaniu maszyny można spiąć ją kablem szeregowym z inną maszyną aby w razie awarii karty sieciowej mieć dostęp do systemu za pośrednictwem innego hosta. Dobrym pomysłem może byc również postawienia jakiegoś „szrota” z dodatkową kartą – powiedzmy 4 x RS232 –  podpiąć do niego swoje serwery i uruchomić serwer ssh…

wg@moher:~/tmp> script -t 2>times
Script started, file is typescript
wg@moher:~/tmp> ps
  PID TTY          TIME CMD
10184 pts/3    00:00:00 bash
10203 pts/3    00:00:00 ps
wg@moher:~/tmp> ls
times  typescript
wg@moher:~/tmp> exit
Script done, file is typescript
wg@moher:~/tmp>

Po nagraniu całej sekwencji można odtworzyć nasz ‘film’ poleceniem scriptreplay:

wg@moher:~/tmp> scriptreplay  times

Wygenerowane pliki przykładowe można znaleźć tutaj.

Przy tworzeniu stref z wieloma podobnymi wpisami typu hostXXX użyteczna jest instrukcja GENERATE. Przykładowy wpis z pliku strefy może wyglądać następująco:

[...]
$GENERATE 100-110 host$ IN A		10.0.0.$
[...]

Po umieszczeniu takiego wpisu w pliku strefy wynik polecenia dig -t axfr labnet.com wykonującego transfer strefy dla zony będzie wyglądał następująco:

<<>> DiG 9.5.0-P2 <<>> -t axfr labnet.com
;; global options:  printcmd
labnet.com.		172800	IN SOA	moher.vnet.com. [...]
labnet.com.		172800	IN NS	moher.vnet.com.
labnet.com.		172800	IN TXT	"v=spf1 mx ~all"
labnet.com.		172800	IN MX	5 melman.labnet.com.
host100.labnet.com.	172800	IN A	10.0.0.100
host101.labnet.com.	172800	IN A	10.0.0.101
host102.labnet.com.	172800	IN A	10.0.0.102
host103.labnet.com.	172800	IN A	10.0.0.103
host104.labnet.com.	172800	IN A	10.0.0.104
host105.labnet.com.	172800	IN A	10.0.0.105
host106.labnet.com.	172800	IN A	10.0.0.106
host107.labnet.com.	172800	IN A	10.0.0.107
host108.labnet.com.	172800	IN A	10.0.0.108
host109.labnet.com.	172800	IN A	10.0.0.109
host110.labnet.com.	172800	IN A	10.0.0.110
melman.labnet.com.	172800	IN A	10.0.0.5
labnet.com.		172800	IN SOA	moher.vnet.com. [...]
;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jun  8 09:46:36 2009
;; XFR size: 17 records (messages 1, bytes 460)

Dynamiczne modyfikowanie strefy

W niektórych wypadkach dogodne jest modyfikowanie strefy „w locie” – bez przeładowywania strefy z pliku. Rozwiązanie takie często spotyka się na styku serwerów DNS i DHCP. Konfigurację tej funkcjonalności w serwerze BIND należy rozpocząć od wygenerowania klucza poleceniem dnssec-keygen:

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST labnet-update

W wyniku tego polecenia wygenerowane zostaną pliki Klabnet-update.+157+63533.key oraz Klabnet-update.+157+63533.private. Na ich podstawie należy wygenerować wpis do pliku named.conf, bądź innego umieszczonego w katalogu /etc/named.d/ z następującą zawartością:

key labnet-update {
algorithm hmac-md5;
        secret  "UPLyG8ScPjErGo7XU [...] MVxWXHfvIlz/Dhy/9EvYzZA==";
};

zastępując rzecz jasna wartość pola secret kluczem z jednego z plików Klabnet-update*
Dla każdej strefy, która ma być edytowana z wykorzystaniem tego klucza należy dodać dyrektywę allow-update:

[...]
zone "labnet.com" in {
        allow-transfer { none; };
        allow-update { key labnet-update; };
        file "master/labnet.com";
        type master;
};
[...]

Po wprowadzeniu tej sekcji do konfiguracji demona BIND można wykorzystywać narzędzie nsupdate do szybkiej edycji pliku strefy lub napisać własny skrypt, np. w języku perl w oparciu o moduł Net::DNS

Spam jest obecnie jednym z największych utrapień administratorów na całym świecie – co do tego chyba nie trzeba nikogo przekonywać. I jak to zwykle bywa, każdy nowy rodzaj spamu powoduje powstanie nowych metod zwalczania niechcianej poczty i na odwrót..  I tak to dorobiliśmy się takich metod jak:

• greylisting
• weryfikacja adresu nadawcy
• rekory SPF
• RBL-e
• metody oparte o analizę treści
• …itd., itp.

W tym artykule przyjglądniemy się konfiguracji trzech z nich…

Greylisting

Technika greylistingu polega na chwilowym odrzuceniu przesyłki przez MTA i opiera się na założeniu że porządny serwer pocztowy i tak spróbuje za chwilę, natomiast wirus czy automat spamowy – nie. Na pierwszy rzut oka nie wygląda to może zbyt sensownie – ale działa! Co więcej, jest to technika nie obciążająca serwera pocztowego a wymagająca jedynie przechowywania mapy adresów na serwerze pocztowym.

Włączenie tej metody ochrony przed spamem w postfixie jest bardzo prosta. Po pierwsze trzeba zainstalować pakiet postgrey, który w większości dystrybucji dostępny jest w głównym repozytorium. Jeśli jesteśmy szczęśliwymi posiadaczami dystrybucji „enterprajzowej” to być może będziemy musieli poszukać go w jednym z wielu dodatkowych repozytoriów.

Po zainstalowaniu pakietu należy uruchomić demona postgrey i upewnić się że będzie uruchamiany zawsze podczas startu systemu. Następnie można – a czasem nawet trzeba – dostosować parametry w pliku konfiguracyjnym /etc/sysconfig/postgrey ustawiając odpowiednio czas po którym postgrey przepuści wiadomość:

OPTIONS="--unix=/var/spool/postfix/postgrey/socket --delay=60"

Ostatni element to poinformowanie postfixa, że powinien skorzystać z usługi postgrey. Przy założeniu że przepuszczamy całość ruchu pocztowego przez postgreya, dodajemy następujący wpis do ustawień restrykcji:

smtpd_recipient_restrictions =
   permit_mynetworks,
   reject_unauth_destination,
   ...
   check_policy_service unix:postgrey/socket,
   ...

Na koniec wypada dodać, że postfix pozwala na wybiórcze przesyłanie maili do postgreya za pośrednictwem tabeli access. Po więcej szczegółów odsyłam do tej strony

Weryfikacja adresu nadawcy

Podczas transakcji SMTP Postfix może przeprowadzić weryfikację adresu nadawcy symulując proces wysyłania odpowiedzi na adres nadawcy. Innymi słowy MTA łączy się z serwerem pocztowym odpowiednim dla domeny nadawcy i rozpoczyna równoległą transację SMTP. Jako odbiorcę fikcyjnej wiadomości podaje konto nadawcy weryfikowanej przesyłki i po wysłaniu poleceń MAIL FROM: oraz RCPT TO: zrywa transakcję. Jeśli zdalny serwer zaakceptował połączenie – nadawca jest zweryfikowany pomyślnie. Jeśli nie – Postfix odpowiada tą samą klasą błedu (tymczasowy/permanentny).  Aby nie weryfikować ponownie adresów, Postfix przetrzymuje adresy wraz z informacją o wyniku weryfikacji w odpowiedniej mapie  (zalecany typ btree)

Za konfigurację tej funkcjonalności odpowiadają następujące parametry konfiguracyjne:

• address_verify_map – wskazujący na położenie pliku z mapą
• reject_unverified_sender – dodawany do listy restrykcji

Poniżej przedstawiona jest przykładowa konfiguracja:

address_verify_map = hash:/var/log/postfix-verify

smtpd_recipient_restrictions = permit_mynetworks,
         check_policy_service unix:postgrey/socket,
         reject_unverified_sender,reject_unauth_destination,
         check_policy_service unix:private/policy

Sender Policy Framework

Na koniec ostatnia technika, która w gruncie rzeczy jest bardzie zabezpieczeniem przed wysyłaniem spamu z naszej domeny niż blokadą przychodzącego spamu. Jej działanie opiera się bowiem na umieszczeniu w strefie DNS informacji o tym, z których hostów dozwolone jest wysyłanie poczty z naszej domeny.

Poniżej przedstawiony jest przykładowyrekord TXT informujący o tym, że zdomeny vnet.com możliwe jest wysyłanie poczty wyłącznie z hostów określonych jako MX dla vnet.com:

vnet.com.	IN TXT	"v=spf1 mx -all"

Postfix sam w sobie nie potrafi przeglądać rekordów SPF. Do tego celu służy zewnętrzne narzędzi, np. postfix-policyd-spf-perl. Jak wskazuje nazwa, jest to narzędzie napisane w perlu i  wymaga zainstalowania modułu Mail::SPF.

Po zainstalowaniu wymaganego modułu należy zciągnąć pakiet ze strony www.openspf.org/Software, umieścić go w katalogu /usr/lib/postfix/ np. pod nazwą policyd-spf-perl i dodać następujący wpis do pliku master.cf:

policy  unix  -       n       n       -       -       spawn
        user=nobody argv=/usr/bin/perl /usr/lib/postfix/policyd-spf-perl

Ostatni etap to dodanie do restrykcji frazy:

check_policy_service unix:private/policy

Po przeładowaniu Postfixa nasz MTA powinien już sprawdzać wpisy SPF z DNSu

Do szybkiego zbudowania  CA w linuksie wystarczy kilka poleceń. Cały proces składa się z:

1. przygotowania pliku konfiguracyjnego (a właściwie przerobienie pliku opnessl.cnf)
2. wygenerowania odpowiedniej struktury katalogów
3. wygenerowania samopodpisanego certyfikatu CA

Plik openssl.cnf zawiera sekcję [ CA_default ] opisującą domyślne CA. W tej sekcji należy podmienić wartość zmiennej dir na katalog, w którym umieszczone będzie CA. Tam też można dla wygody umieścić zmodyfikowaną wersję pliku konfiguracyjnego.

Kolejny krok to założenie struktury katalogów:

bash$ mkdir certs private newcerts crl
bash$ touch index.txt
bash$ echo -n '00' > serial

Ostatni krok to wygenerowanie samopodpisanego certyfikatu dla naszego CA:

bash$ openssl req -x509 -newkey rsa:2048 -keyout private/cakey.pem\
 -out cacert.pem -days 3650 -config ./openssl.cnf

Na koniec pozostaje podać polecenia do generowania nowego certyfikatu przez nasze CA (pierwsze generuje rządanie certyfikatu a drugie podpisuje je kluczem prywatnym naszego CA):

bash$ openssl req -newkey rsa:1024 -keyout private/NAZWA.pem \
-out req.pem -days 365 -config ./openssl.cnf
bash$ openssl ca -config ./openssl.cnf -policy policy_anything \
-in req.pem -out certs/NAZWA.pem

Aby sprawnić sobie proces generowania certyfikatów można wyedytować plik openssl.cnf i ustawić odpowiednio domyślne wartości pól z certyfikatów (np. Organization, Locality, itp…)

Do przechowywania tak skonstruowanego CA można wykporzystać zaszyfrowany pendrive.