Procmail doklejamy stopkę [linux mta]

Ściąga Admina, Usługi Możliwość komentowania Procmail doklejamy stopkę [linux mta] została wyłączona

Procmail to niedoceniane narzędzie, pozwala w prosty sposób manipulować pocztą dostarczaną do użytkowników.

Dziś opiszę jak dodać stopkę do e-mail dostarczanych do naszych użytkowników.

mcedit /etc/procmail

:0fb
| cat — ; \
echo ; \
echo „———————————————” ; \
echo „Super firma” ; \
echo „tu jej strona” ; \
echo „antynet.pl” ; \
echo „———————————————” ; \
echo „”

zapisujemy i po sprawie….
prawda że proste?

Postfix i SPF

Usługi Możliwość komentowania Postfix i SPF została wyłączona

SPF czyli [wikipedia] Sender Policy Framework (SPF) to niekomercyjny projekt mający na celu wprowadzenie zabezpieczenia serwerów SMTP przed przyjmowaniem poczty z niedozwolonych źródeł. Ma to pozytywnie wpłynąć na ograniczenie ilości spamu oraz zmniejszenie ilości rozsyłających się wirusów.

Teraz uruchomimy to ustrojstwo u siebie, pozytywne doświadczenie arta na podstawie strony [http://www.urug.net/blog/archives/6-postfix,_SPF_jako_antybiotyk_na_greyliste.html ]

Do dzieła:

instalujemy podstawowy soft.
apt-get install whitelister

edytujemy plik /etc/whitelister.conf

sock: 127.0.0.1:10000
user: www-data
group: www-data
verb: 1
spf: 3
spfrej: yes

Jak widać odpalamy go na prawach www-data, to uprawnienia apache w debianie.
Jak ktoś nam włamie się na apache to przejmie też whitelister , myślę że to wtedy będzie bardzo mały istotny problem.

Teraz edycja main.cf :

należy dopisać: check_policy_service inet:127.0.0.1:10000
u mnie tak to wygląda:
[…]
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_hostname,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rhsbl_sender dsn.rfc-ignorant.org,
reject_unauth_destination,
check_policy_service inet:127.0.0.1:10000
[…]

pozostało zatwierdzenie konfiguracj:
/etc/init.d/postfix restart

Bind9 named „max open files (1024) is smaller than max sockets (4096)”

Ściąga Admina, Usługi Możliwość komentowania Bind9 named „max open files (1024) is smaller than max sockets (4096)” została wyłączona

Po upgrade Debiana z Etch do Lenny bind9 w logach możemy zobaczyć komunikat: „max open files (1024) is smaller than max sockets (4096)” . Na google szukałem chwilę ale znalazłem posty w których pojawiały się jakieś dziwne pytania do stref itp. Co ma piernik do wiatraka? No chyba że faktycznie stref mamy bardzo dużo. Reasumując przypomniał mi się podobny problem ze squidem obsługujących ponad tysiąc userów, wtedy pomogło: wpisanie w powłoce ulimit -HSn 8192.

Teraz też pomogło
ulimit -HSn 8192
/etc/init.d/bind9 restart

no i w logach mamy:
using up to 4096 sockets

Misja wykonana!

SVN

Usługi Możliwość komentowania SVN została wyłączona

wgranie pakietów
instalacja cvs2svn
make install
lub
apt-get install apache2
apt-get install subversion
apt-get install libapache2-svn
dodanie grupy svn
dodanie usera na którym jest apache do grupy svn
stworzenie repozytorium
zmiana grupy plików i katalogów repozytorium na grupę svn i uprawnienia 770

konfiguracja w pliku httpd.conf:

LoadModule dav_module /usr/lib/httpd/modules/mod_dav.so
LoadModule dav_svn_module /usr/lib/httpd/modules/mod_dav_svn.so
LoadModule authz_svn_module /usr/lib/httpd/modules/mod_authz_svn.so


SetOutputFilter DEFLATE
SetInputFilter DEFLATE
DAV svn
SVNParentPath /u02/svn_home
AuthType Basic
AuthName „Subversion repository”
AuthUserFile /u01/apache2/conf/[password_file]
Require valid-user
#SVNIndexXSLT „/svnindex.xsl”
AuthzSVNAccessFile /u01/apache2/conf/[role_file]
SVNPathAuthz off

dopisywanie userów:
htpasswd -mb [password_file] user password

konfiguracja pliku z rolami [role_file]:

[groups]
grupa1 = user1,user2
grupa2 = user2,user3
[repozytorium:/[katalog]
@grupa1 = rw
@grupa2 = r
user3 = rw


migracja Z CVS DO SVN
cvs2svn –encoding cp1250 -s [sciezka_projekt_svn] [sciezka_projekt_cvs]
cvs2svn –encoding cp1250 –dumpfile [sciezka_plik_dump] [sciezka_projekt_cvs]

nowe REPOZYTORIUM
svnadmin create /[repository_path]

import z dumpa do REPOZYTORIUM
cat [dumpfile_path] | svnadmin load [sciezka_projekt_svn] –działa
svnadmin load [sciezka_projekt_svn] [dumpfile_path] –miałem problemy

zmienić prawa do repozytorium
w przypadku błędu:
m:human-readable errcode=”13″ Could not open the requested SVN filesystem /m:human readable
brak jest uprawnień do czytania przez apache


sprawdzenie LOCKS
svnadmin lslocks /[repository_path]

usunięcie LOCKS
svn unlock –force

nowy BRANCH/TAG z już istniejącego
svn copy -r [ver] http://[trunk_path] http://[new_trunk_path] -m „[komentarz]”

nowy KATALOG
svn mkdir http://[trunk_path]/[new_dir]

dodanie KATALOGU z kompa do TRUNKA
svn import [local_dir_path] http://[trunk_path]/[new_dir]

usuwanie KATALOGU (zawsze można odtworzyć)
svn delete http://[trunk_path]/[dir]

ściągnięcie określonego nr rewizji
svn checkout -r [rewizja] http://[repo_path]
svn checkout http://[trunk_path]@[rev]9814

sprawdzenie z jakiej rewizji został zbudowany TAG:
svn log -v –stop-on-copy http://[tag_path]

sprawdzenie wersji na serwerze
svn status -u

find . -perm +2000 -exec chmod 2775 {} \;


BACKUP
svnadmin hotcopy /[repository_path] /[backup_dir_path]

DUMP przepisuje repozytorium do jednego pliku z wszystkimi rewizjami
svnadmin dump /[repository_path] [-r LOWER[:UPPER]]> [dumpfile]
#rewizje od 100 do 200
svnadmin dump /[repository_path] -r 100:200 > [dumpfile]

wrzuca z dumpa tylko pliki określone w path
svndumpfilter include [dumpfile] [repository_path] > [dumpfile_after]

wrzuca z dumpa wszystkie pliki za wyj╣tkiem wykluczonych w path
svndumpfilter exclude [dumpfile] [repository_path] > [dumpfile_after]

wciągnięcie z utworzeniem nowego projektu
svnadmin create calc; svnadmin load calc


Bind – SPF

Usługi Możliwość komentowania Bind – SPF została wyłączona

Sender Policy Framework (SPF) to niekomercyjny projekt mający na celu wprowadzenie zabezpieczenia serwerów SMTP przed przyjmowaniem poczty z niedozwolonych źródeł. Ma to pozytywnie wpłynąć na ograniczenie ilości spamu oraz zmniejszenie ilości rozsyłających się wirusów.

Konfiguracja postfixa do współpracy z SPF pewnie niedługo się pojawi na tej stronie, na razie przedstawię jak skonfigurować nasz serwer DNS Bind aby inne serwery pocztowe mogły sprawdzić czy poczta przyszła z prawdziwego serwera.
Zabezpieczy to nas przed podszywaniem się wirusów pod naszą domenę.
Oczywiście zakładając, iż zdalny serwer pocztowy sprawdza wpis SPF dla przesyłek pocztowych.

W pliku strefy naszej domeny dodajemy wpis:

antynet.pl. TXT „v=spf1 ip4:xxx.xxx.xxx.xxx ip4:xxx.xxx.xxx.xxx -all”

xxx.xxx.xxx.xxx – adres(y) naszych serwerów smtp
Prawdopodobnie w większości konfiguracji będzie to jeden IP

Postfix – walczymy ze spamem

Usługi Możliwość komentowania Postfix – walczymy ze spamem została wyłączona

Postfix – walczymy ze spamem

Większość spamu jaki dociera do naszych skrzynek pocztowych jest wysyłana przez ogromne sieci komputerów zombie, pracujących pod kontrolą cudownego Windows XP.

Są to zawirusowane komputery z własnymi silnikami SMTP, silniki te są zwykle napisane w możliwie najprostszy sposób, bez obsługi błędów.
Błędnie się przedstawiają, starają się podszyć pod istniejące serwery pocztowe itp. To będzie teraz nasza broń, dodamy do postfixa kilka regułek pozwalających wykryć tego typu śmieci i usunąć je zanim zostaną dostarczone do naszego systemu.

Zajmiemy się konfiguracją pliku:

/etc/postfix/main.cf

w sekcji:
smtpd_recipient_restrictions

dodajemy:

reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_hostname,
reject_unverified_recipient,

Na tym etapie z całą pewnością spora część poczty z windzianych botnetów zostanie odrzucona.

wpis:
reject_unknown_client,

Ten wpis odrzuci połączenia z serwerów nie posiadających RevDns, jest bardzo skuteczny na sporą część spamu, jednakże wciąż istnieją serwery pocztowe bez wpisu Rev. Ja osobiści daruje sobie tę metodę, przynajmniej na razie, ale pewnie tylko do czasu gdy moje obecne metody antyspamowe będą działać należycie.

Netfilter – limit

Iptables, Usługi Możliwość komentowania Netfilter – limit została wyłączona

LIMIT

1) iptables -A FORWARD -p tcp –dport 3000 -m limit –limit 3/minute –limit-burst 4 -j ACCEPT
2) iptables -A FORWARD -p tcp –dport 3000 -j DROP

1) Gdy wskazany pakiet wystąpi pierwszy raz to wykonaj regułę ACCEPT na czterech pakietach, następnie czekaj przez czas określony współczynnnikiem 3/minute tzn. 20 sekund i wykonaj regułę ACCEPT na jednym pakiecie, ale jeśli po 20 sekundach nie pojawi się żaden wskazany pakiet a pojawi się dopiero po 40 sekundach od pierwszych trzech to zastosuj regułę do dwóch pakietów, ale jeśli ani po 20 ani po 40 nie pojawi się żaden wskazany pakiet a pojawi się dopiero po 60 sekundach od pierwszych trzech to zastosuj regułę do trzech pakietów itd.
Jak pisze Bromirski, każde 20 sekund które minie bez pakietu, który pasowałby do tej reguły, spowoduje odnowienie jednego numeru z serii, jeśli żaden pakiet nie będzie pasował do reguły w ciągu 80 sekund, seria zostanie w pełni odnowiona do 4 sztuk tak jak zaczęliśmy.

IIII <—- 20s —-> I
IIII <—- 20s —-> <—- 20s —-> II
IIII <—- 20s —-> <—- 20s —-> <—- 20s —-> III
IIII <—- 20s —-> <—- 20s —-> <—- 20s —-> <—- 20s —-> IIII

–limit x/second,minute,hour,day określa przedział czasowy pomiędzy seriami
–limit-burst x określa ilość pakietów w pierwszej serii

BIND – Podstawy Bezpieczeństwa

Usługi Możliwość komentowania BIND – Podstawy Bezpieczeństwa została wyłączona

BIND – Podstawy Bezpieczeństwa

BIND (Berkeley Internet Name Domain, poprzednio: Berkeley Internet Name Daemon) jest popularnym serwerem (demonem) DNS. Został on stworzony przez Paula Vixie w roku 1988 podczas jego pracy w DEC. BIND jest jednym z najpopularniejszych serwerów DNS wykorzystywanym w systemach Linux i Unix. BIND stanowi niezmiernie ważny składnik zapewniający poprawne działanie sytemu nazw w Internecie. Wielu użytkowników globalnej sieci bezwiednie korzysta z serwera BIND, kiedy ich przeglądarka WWW odpytuje go o adres IP komputera udostępniającego interesującą ich stronę.

Skanując sieć internetową można bardzo szybko zauważyć, iż znakomita większość serwerów DNS jest po prostu zainstalowana i skonfigurowana do obsługi jakieś domeny lub domen.
Zadając tym serwerom pytanie o dowolna domenę zaraz nam odpowie, czyli pełne open for all, zwykle nawet pozwalają na transfer całej swojej strefy. Chyba nie muszę tłumaczyć iż to nie jest najbezpieczniejszy pomysł, nasz serwer powinien:

Każdemu odpowiedzieć na pytanie TYLKO o obsługiwane przez siebie domeny,
pozwolić transferować swoje domeny TYLKO swoim serwerom podrzędnym,
odpowiadać na każde zapytanie TYLKO obsługiwanym przez siebie siecią. (klientom)

Teraz opiszę jak osiągnąć to w Bind v8.
całość polega na edycji pliku /etc/bind/named.conf (Debian GNU/Linux)

Określamy kto może nas pytać o dowolną domenę:

acl „swoi” { 127.0.0.1/8; 192.168.0.0/24; };
options {
directory „/var/cache/bind”;
allow-query {„swoi”;};
};

Teraz określimy, kto może transferować naszą domenę oraz kto może pytać o naszą domenę:

zone „antynet.pl” {
type master;
file „/etc/bind/antynet.pl”;
notify yes;
allow-transfer { ip_sec_dns1; ip_sec_dns2; };
allow-query { 0.0.0.0/0;};
};

allow-transfer są to serwery które mogą transferować od nas strefę antynet.pl, w celu jej dalszego rozgłaszania.

allow-query określa kto może pytać o naszą domenę. Oczywiście że wszyscy, tak więc wpisujemy 0.0.0.0/0

Tych kilka prostych zabiegów znacznie poprawi stopień bezpieczeństwa naszego serwera DNS.
Teraz śledzimy logi i patrzymy ile dziwnych sieci stara się o uzyskanie odpowiedzi z naszego serwera. Ciekawe w jakim celu? :>

Greylisting – Postfix

Ściąga Admina, Usługi Możliwość komentowania Greylisting – Postfix została wyłączona

Ogromną ilość spamu wytnie nam zmuszenie postfixa do współpracy z Greylisting.

Greylisting jest jedną z najnowszych metod walki ze spamem. Jak sama nazwa wskazuje, jest czymś więcej niż whitelistingiem i blacklistingiem. Za każdy razem kiedy nieznany serwer poczty próbuje dostarczyć wiadomość, ta wiadomość jest odrzucana z komunikatem spróbuj ponownie później („try again later”). Oznacza to, iż wiadomość zostanie dostarczona z opóźnieniem, jednak roboty spamerskie, które nie mają zaimplementowanego protokołu RFC odrzucą próbę dostarczenia spamu i nie będą tego nigdy powtarzać. Z biegiem czasu roboty zapewne przystosują się, jednak zanim to nastąpi inne technologie będą miały zapewniony czas, aby udoskonalić swoje metody identyfikacji spamu.

Konfiguracja tego rozwiązania w systemie Debian GNU/Linux jest wręcz banalna, więc do dzieła.

1.
# apt-get install postgrey

2.
Otwieramy do edycji plik konfiguracyjny postfixa:
# mcedit /etc/postfix/main.cf

odnajdujemy sekcję:
smtpd_recipient_restrictions

i w tej sekcji dopisujemy:
check_policy_service inet:127.0.0.1:60000,

Jako iż swoich klientów nie będziemy testować tym rozwiązaniem, najlepszym miejscem na wprowadzenie greylist będzie sekcja po:

permit_mynetworks,
permit_sasl_authenticated,

To już wszystko, od tego czasu zauważysz ogromny spadek spamu w Twoim systemie pocztowym 😉

W logach zaczynają się pojawiać wpisy:

Dec 26 14:14:51 serwer postfix/smtpd[19469]: NOQUEUE: reject: RCPT from yellowspace.cc[213.159.7.253]: 450 : Recipient address rejected: Greylisted for 300 seconds (see http://isg.ee.ethz.ch/tools/postgrey/help/serwer.pl.html); from= to= proto=ESMTP helo=

Powodzenia!

WordPress - Hosting: Twój hosting - Skórka: N.Design Studio - Spolszczenie: Adam Klimowski.
RSS wpisów RSS komentarzy Zaloguj się