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

W dobie wszechobecnej wirtualizacji i coraz większej popularyzacji wszelkiej maści rozwiązań HA współdzielenie urządzeń blokowych staje się konkretnym problemem wielu administratorów. Jeśli pracujesz w firmie, którą stać na FC – możesz sobie odpuścić ten artykuł. Nawet Novell promując technologię iSCSI mówi wprost: jeśli możesz wybierać – wybierz FC. Ale jeśli nie… to postaram się przedstawić jak w kilku krokach zbudować własną „macierz”  iSCSI. Całą operację przeprowadzę na systemie SLES10SP2, ale będę unikał narzędzi dedykowanych dla tej dystrybucji (kto lubi – może to wyklikać w programie YaST) tak, aby opis był w miarę uniwersalny. A więc zaczynamy…

Jak to działa

iSCSI to protokół opierający się o enkapsulacje poleceń SCSI wewnątrz protokołu TCP/IP. Jest to więc swego rodzaju wirtualizacja dostępu do urządzenia blokowego. Z podobnych technologii można wspomnieć HyperSCSIczy ATAoE – protokoły przekazujące odpowiednio polecenia SCSI i ATA bezpośrednio w ramkach Ethernet. W odróżnieniu od nich iSCSI może być rutowane (ale ma w związku z tym większy narzut w postaci dodatkowych nagłówków TCP/IP). Ponadto iSCSI pozwala na obustronne uwierzytelnienie za pomocą protokołu CHAP.

Zasada działanie jest bardzo prosta. Po stronie serwera (w terminologii iSCIS – target) działa demon ietd (iSCSI Enterprise Target), który eksportuje wskazane urządzenia blokowe. Po stronie klienta działa demon open-iscsi (inicjator), którego zadaniem jest nawiązanie połączenia i komunikacja z targetem oraz utworzenie urządzeń blokowych (np. sdb, sdc, itd.) w katalogu /dev. Utworzone przez inicjator urządzenia widoczne są w systemie klienckim jak zwyczajne dyski SCSI czy SATA.

Konfiguracja targetu

Po stronie naszej macierzy należy doinstalować demona ietd oraz moduł do jądra z obsługą protokołu iSCSI. W systemie SLES jądro zawiera wszystkie potrzebne moduły, a demon ietd znajduje się w pakiecie iscsitarget. Osobom pracującym na systemie  SLES polecam jeszcze pakiet yast2-iscsi-server zawierający moduł YaSTa do konfiguracji targetu.

Przed przystąpieniem do konfiguracji serwera iSCSI należy przygotować urządzenia blokowe, które będą eksportowane. Można do tego celu wykorzystać całe dyski, poszczególne partycje, albo wolumeny LVM. Ta ostatnia metoda jest wygodna ze względu na elastyczność zarządzania warstwą urządzeń blokowych oraz możliwość wykonywania snapshot’ów.

W tym artykule posłużę się przykładem konfiguracji pod klaster HA. Załóżmy więc że potrzebujemy jeden wolumen na dane konfiguracyjne (powiedzmy pod klastrowy system plików), trzy wolumeny jako dyski dla maszyn wirtualnych oraz dysk pod serwer plików. Wtakim układzie najlepej będzie skonfigurować dwa targety:

• pierwszy z wolumenem współdzielonym pod klastrowy system plików i trzema wolumenami dla maszyn wirtualnych
• drugi z jednym wolumenem pod serwer plików

Konfiguracja wolumenów LVM:

host03:~ # dd if=/dev/zero of=/dev/sdb  bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1,0 MB) copied, 0,006733 seconds, 156 MB/s
host03:~ # pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created
host03:~ # pvscan
  PV /dev/sdb1               lvm2 [93,13 GB]
  Total: 1 [93,13 GB] / in use: 0 [ 0 MB ] / in no VG: 1 [93,13 GB]

host03:~ # vgcreate iSCSI /dev/sdb
  Volume group "iSCSI" successfully created

host03:~ # vgdisplay
  --- Volume group ---
  VG Name               iSCSI
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  6
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               100,00 GB
  PE Size               4,00 MB
  Total PE              25600
  Alloc PE / Size       12850 / 50,20 GB
  Free  PE / Size       12750 / 49,80 GB
  VG UUID               Wlx3d1-DHqd-6P7U-ASIP-4HVD-jDQc-pSErYA

host03:~ # lvcreate -n samba iSCSI -L 20G
  Logical volume "samba" created
host03:~ # lvcreate -n config iSCSI -L 200M
  Logical volume "config" created
host03:~ # lvcreate -n xen1 iSCSI -L 10G
  Logical volume "xen1" created
host03:~ # lvcreate -n xen2 iSCSI -L 10G
  Logical volume "xen2" created
host03:~ # lvcreate -n xen3 iSCSI -L 10G
  Logical volume "xen3" created
host03:~ #
host03:~ # ls -l /dev/iSCSI/
razem 0
lrwxrwxrwx 1 root root 24 2009-10-27 15:12 config -> /dev/mapper/iSCSI-config
lrwxrwxrwx 1 root root 23 2009-10-27 15:11 samba -> /dev/mapper/iSCSI-samba
lrwxrwxrwx 1 root root 22 2009-10-27 15:12 xen1 -> /dev/mapper/iSCSI-xen1
lrwxrwxrwx 1 root root 22 2009-10-27 15:12 xen2 -> /dev/mapper/iSCSI-xen2
lrwxrwxrwx 1 root root 22 2009-10-27 15:12 xen3 -> /dev/mapper/iSCSI-xen3
host03:~ #

Po przygotowaniu wolumenów można przystąpić do konfiguracji demona ietd. W tym celu w pliku /etc/ietd.conf należy dodać następujące wpisy:

Target iqn.2009-10.com.vnet:host03-samba
         Lun 0 Path=/dev/mapper/iSCSI-samba,Type=fileio
Target iqn.2009-10.com.vnet:host03-xen
         Lun 0 Path=/dev/mapper/iSCSI-config,Type=fileio
         Lun 1 Path=/dev/mapper/iSCSI-xen1,Type=fileio
         Lun 2 Path=/dev/mapper/iSCSI-xen2,Type=fileio
         Lun 2 Path=/dev/mapper/iSCSI-xen3,Type=fileio

Po zapisaniu konfiguracji można uruchomić serwer iscsi i sprawdzić czy wszystkie targety/LUNy są widoczne:

host03:~ # rciscsitarget start
Starting iSCSI target service:                                        done
host03:~ # cat /proc/net/iet/volume
tid:2 name:iqn.2009-10.com.vnet:host03-xen
	lun:0 state:0 iotype:fileio iomode:wt path:/dev/mapper/iSCSI-config
	lun:1 state:0 iotype:fileio iomode:wt path:/dev/mapper/iSCSI-xen1
	lun:2 state:0 iotype:fileio iomode:wt path:/dev/mapper/iSCSI-xen2
tid:1 name:iqn.2009-10.com.vnet:host03-samba
	lun:0 state:0 iotype:fileio iomode:wt path:/dev/mapper/iSCSI-samba
host03:~ #

Voila! Serwer działa i eksportuje to co chcemy, więc pozostaje nam tylko skonfigurować klienta…

Konfiguracja klienta

Po stronie klienta również wymagany jest odpowiedni moduł jądra oraz pakiet z demonem – w systemie SLES nosi on nazwę open-iscsi.  Podobnie jak w przypadku serwera iSCSI, w SLESie można wyklikać wszystko w odpowiednim module programu YaST (wymaga to doinstalowania pakietu yast2-iscsi-client) . Jak zaznaczyłem na początku będę unikał YaSTa więc przedstawię narzędzia uniwersalne.

Do zarządzania dyskami podpiętymi poprzez iSCSI służy polecenie ietadm. Oto przykład wykrywania i podpinania dysków przez protokół iSCSI:

rico:~ # /etc/init.d/open-iscsi start
Starting iSCSI initiator service:                                     done
Setting up iSCSI targets:                                             unused
rico:~ # iscsiadm -m discovery -t st --portal 10.0.0.103
10.0.0.103:3260,1 iqn.2009-10.com.vnet:host03-xen
10.0.0.103:3260,1 iqn.2009-10.com.vnet:host03-samba
rico:~ #
rico:~ # iscsiadm -m node -T iqn.2009-10.com.vnet:host03-xen --login
Logging in to [iface: default, target: iqn.2009-10.com.vnet:host03-xen, portal: 10.0.0.103,3260]
Login to [iface: default, target: iqn.2009-10.com.vnet:host03-xen, portal: 10.0.0.103,3260]: successful
rico:~ #
rico:~ # ls -l /dev/disk/by-path/
total 0
lrwxrwxrwx [...] ip-10.0.0.103:3260-iscsi-iqn.2009-10.com.vnet:host03-xen-lun-0 -> ../../sda
lrwxrwxrwx [...] ip-10.0.0.103:3260-iscsi-iqn.2009-10.com.vnet:host03-xen-lun-1 -> ../../sdb
lrwxrwxrwx [...] ip-10.0.0.103:3260-iscsi-iqn.2009-10.com.vnet:host03-xen-lun-2 -> ../../sdc
[...]
rico:~ #

Następnym krokiem (w zależności od potrzeb) może być konfigurowania automatycznego logowania się do wybranych targetów zaraz po uruchomieniu demona open-iscsi:

rico:~ # iscsiadm -m node -T iqn.2009-10.com.vnet:host03-xen  -o update -n node.conn[0].startup -v automatic

Od tej chwili demon open-iscsi będzie automatycznie logował się do wskazanego targetu zaraz po uruchomieniu:

rico:~ # /etc/init.d/open-iscsi start
Starting iSCSI initiator service:                                     done
Attempting discovery on target at 10.0.0.103:                         done
Setting up iSCSI targets: Logging in to [iface: default, target: iqn.2009-10.com.vnet:host03-xen, portal: 10.0.0.103,3260]
Login to [iface: default, target: iqn.2009-10.com.vnet:host03-xen, portal: 10.0.0.103,3260]: successful
                                                                      done
rico:~ #

Dodatkowe możlilwości

W zależności od potrzeb, serwer iSCSI pozwala nam na skonfigurowanie uwierzytelniania (w dwie strony) oraz ograniczenie ilości równocześnie podpiętych do targetu inicjatorów. W naszym przykładzie wolumen przeznaczony na serwer plików można by zabezpieczyć przed przypadkowym podmontowaniem na kilku maszynach ustawiając maksymalną ilość połączeń na 1. Takie zabezpieczenie jest bardzo wskazane jeśli nie stosujemy klastrowego systemu plików.

Podsumowanie

Technologia  iSCSI jest ciekawą alternatywą dla tych, których nie stać na Fibre Channel. Za jej pomocą możemy zbudować funkcjonalną i niedrogą „macierz” , a korzystając z pakietów DRBD oraz Heartbeat – można zbudować wysokowydajną macierz replikowaną w czasie rzeczywistym. Należy jednak pamiętać, że serwer iSCSI nie kontroluje równoczesnego dostępu do urządzeń więc równoczesne wykorzystanie wolumenów na kilku maszynach wymaga zastosowania dodatkowych mechanizmów zabezpieczających jak np. klastrowy system plików.

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ę…

wg@hydra:~/tmp> netcat -l -p 8000 | wireshark -HklS -i -

Uruchomi ono Wiresharka w taki sposób, że wszystko co wpadnie na port 8000 będzie potraktowane jako dane z tcpdumpa. Teraz pozostaje tylko zalogować się na zdalną maszynę, na której będziemy snifować i uruchomić coś takiego:

root@nono:/# tcpdump -lnw - -i ethX port not 8000 | netcat TU.JE.ST.IP 8000

Dodanie filtru ‘port not 8000′ zapobiegnie łapaniu pakietów wysyłanych przez polecenie netcat – nie jest konieczne jeśli snifujemy na innym interfejsie niż ten wykorzystany do przesyłania danych do Wiresharka

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.