Testele pentru soluțiile de față le-am făcut într-o mașină virtuală rulând Debian 6.0 (Sqeeze) dar se pretează bine, cu posibile mici schimbări pe toate distribuțiile bazate pe debian, cum ar fi Ubuntu, versiunile pentru care încă există suport(de exemplu în Ubuntu 8.04 directorul de configurație al SpamAssasin nu e /etc/mail/spamassassin ci /etc/spamassassin) dar și pe versiunile mai vechi de Debian(4 sau 5). În distribuțiile “Redhatish”, mă refer aici la Fedora, CentOS sau chiar RHEL, intervin alte comenzi de instalare, posibila nevoie de compilare a pachetelor sau alte locații pentru fișierele de configurare.

1. SpamAssassin – Probabil cel mai mare dinozaur din lumea SPAM-ului. Deși consumă foarte multe resurse, fiin scris în Perl, rămâne cel mai utilizat. Motivul este unul simplu, este singurul scanner OpenSource “de treabă”.
Pentru instalare rulăm din shell comanda:

apt-get install spamassassin

Edităm /etc/default/spamassassin și configurăm:

ENABLED=1
CRON=1

Edităm fișierul implicit de confgurație al SpamAssassin /etc/spamassassin/local.cf după cum urmează:

report_safe 0

În felul acesta SpamAssassin nu modifică conținutul mail-ului, dacă acesta este marcat ca SPAM, ci doar subiectul.

Verificăm să avem pachetul re2c instalat. Pentru aceasta vom rula comanda:

apt-get install re2c

Edităm fișierul /etc/mail/spamassassin/v320.pre pentru a activa cele două plugin-uri care au # în față:

loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody
loadplugin Mail::SpamAssassin::Plugin::ASN

Pentru pasionați mai există un plugin implicit dezactivat în fișierul v330.pre, numit PhishTag, dar care necesită alte configurări suplimentare.
După accea facem prima compilare a regulilor.

sa-compile

Pentru a instala filtrele “sociale” pe care le suportă SpamAssassin vom rula următoarea comandă:

apt-get install razor pyzor

Edităm /etc/mail/spamassassin/local.cf și adăugăm:

pyzor_options --homedir /etc/mail/spamassassin

Pentru a rula pyzor are nevoie de Python 2.5. Pentru a-l instala rulăm:

apt-get install python2.5

Edităm executabilul /usr/bin/pyzor și pe prima linie o modificăm în felul următor:

#!/usr/bin/python2.5

Inițializăm lista de servere cu care va comunica pyzor dând comanda:

pyzor --homedir /etc/mail/spamassassin discover

Putem verifica funcționalitatea lui Pyzor folosind comanda:

echo "test" | spamassassin -D pyzor 2>&1 | less

Instalăm spamass-milter. Aceasta este metoda prin care urmează să îl integrăm în Postfix. Motivul pentru care alegem această metodă este pentru că milter-ul este un “before-queue scanner” adică scanare se face înainte ca mail-ul să intre în coada lui Postfix și SpamAssassin poate direct să respingă mail-urile care au un scor mare.

apt-get install spamass-milter

OPTIONS="-r 10 -u spamass-milter -i 127.0.0.1"
SOCKET="inet:8894@localhost"

“-r 10″ înseamnă că mail-urile care au scor mai mare de 10 în SpamAssassin vor fi respinse din start. Modificați acest scor după bunul plac.

Repornim SpamAssassin și spamass-milter.

/etc/init.d/spamassassin restart
/etc/init.d/spamass-milter restart

2. ClamAV. Singurul antivirus OpenSource, optimizat pentru scanarea virușilor ce se transmit prin e-mail. La fel îl vom integra prin interfața de scanare milter. Pentru instalare rulăm:

apt-get install clamav-milter clamav-daemon

Edităm /etc/clamav/clamav-milter.conf și configurăm:

MilterSocket "inet:8893@localhost"

Repornim Clamav-milter:

/etc/init.d/clamav-milter restart

3. SPF Milter este scanner-ul care va respinge mail-urile care vin dinspre domenii care au SPF configurat și mail-urile nu vin de pe un IP permis, dacă înregistrarea SPF este configurată să respingă mail-urile ce nu vin de pe IP-uri agreate.

apt-get install spfmilter

În fișierul /etc/default/spfmilter configurăm:

DAEMON_OPTS=""
NO_MACROS_CHECK=1
SOCKET="inet:8895@localhost"

Repornim SPFMilter

/etc/init.d/spfmilter restart

Verificăm că până aici avem toate milterele pornite și “ascultătoare”. Rulăm comanda:

netstat -natpd |grep 889

Rezultatul comenzii ar trebui să fie în felul următor.

tcp        0      0 127.0.0.1:8893          0.0.0.0:*               LISTEN      12273/clamav-milter
tcp        0      0 127.0.0.1:8894          0.0.0.0:*               LISTEN      11680/spamass-milte
tcp        0      0 127.0.0.1:8895          0.0.0.0:*               LISTEN      12288/spfmilter

4. Greylisting. Este una dintre cele mai controversate metode de filtrare a SPAM-ului, personal nu-mi place, dar mi s-a dovedit în multe cazuri foarte eficientă. Pentru mai multe explicații despre ce și cum funcționează găsiți de exemplu pe Wikipedia. Vom folosi în Graylisting Postgrey, care este un filtru specific Postfix. Pentru instalare rulăm:

apt-get install postgrey

Edităm fișierul /etc/default/postgrey și punem în acesta:

POSTGREY_OPTS="--inet=60000 --delay=60"

La fel ca și în cazul milterelor ar fi bine să verificăm că Postgrey este pornit și “ascultător”. Dăm comanda:

netstat -natpd |grep 60000

Rezultatul ar trebui să fie:

tcp        0      0 127.0.0.1:60000         0.0.0.0:*               LISTEN      7043/postgrey.pid -

5. Postfix. Multe dintre setările care ajută direct în combaterea SPAM-ului se găsesc direct în MTA. De acesta țin anumite verificări primare, cum ar fi verificarea derogărilor de la RFC-uri(de obicei cei care trimit SPAM-uri fac anumite derogări de la standarde pentru a fi în stare să trimită un volum mult mai mare de mailuri) sau verificarea adresei de mail, fie că e destinatarul fie că e expeditorul, dacă întradevăr există sau nu, etc.

Configurăm postfix, în fișierul /etc/postfix/main.cf vom avea:

smtpd_recipient_restrictions = permit_sasl_authenticated,
        permit_mynetworks,
        reject_unauth_destination,
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_unauth_pipelining,
        reject_invalid_hostname,
        reject_unverified_recipient,
        check_policy_service inet:127.0.0.1:60000
smtpd_sender_restrictions = reject_rhsbl_sender dsn.rfc-ignorant.org,
        reject_non_fqdn_sender,
        reject_unverified_sender,
        reject_unknown_sender_domain
 
non_smtpd_milters = inet:localhost:8895 inet:localhost:8894 inet:localhost:8893
smtpd_milters = inet:localhost:8895 inet:localhost:8894 inet:localhost:8893

Comentarii? Păreri?

În primul rând îl descărcăm.

wget http://downloads.sourceforge.net/project/roundcubemail/roundcubemail/0.5/roundcubemail-0.5.tar.gz

Despachetăm:

tar xzvf roundcubemail-0.5.tar.gz

Îl mutăm într-un director vizibil pe web:

mv roundcubemail-0.5 /var/www/roundcubemail

Schimbăm proprietarul fișierelor astfel încât serverul web să poată scrie în acel folder, deși este suficient doar directorul temp.

chown -R www-data.www-data /var/www/roundcubemail/

Schimbăm calea curentă în directorul cu fișiere de configurație al aplicației și copiem fișierele de configurație implicite ca fiind cele curente.

cd /var/www/roundcubemail/config
cp main.inc.php.dist main.inc.php
cp db.inc.php.dist db.inc.php

Creem baza de date MySQL în care aplicația va stoca diverse informații ale utilizatorilor(pfererințe, agenda,etc.). De asemenea creem un utilizator cu drepturi de citire/scriere în acea bază de date și îi dăm parola “password”. Înlocuiți aici cu ce vreți, preferabil o parolă generată cu pwgen.

mysql -p
create database roundcubemail;
grant all on roundcubemail.* to roundcubemail@localhost identified by 'password';
flush privileges;

Edităm fișierul db.inc.php astfel încât acesta să conțină credențialele corecte pentru MySQL.

$rcmail_config['db_dsnw'] = 'mysql://roundcubemail:password@localhost/roundcubemail';

Importăm în baza de date nou creată schema implicită a bazei de date. Din shell dăm comanda.

mysql -u roundcubemail -p'password' roundcubemail < ../SQL/mysql.initial.sql

În main.inc.php trecem serverul de mail implicit pentru ca implicit utilizatorii să se conecteze fie la localhost fie la serverul la care doriți ca aceștia să se conecteze. Dacă e un server extern, ce nu ține de acel server vă recomand să verificați și setările de SSL. De obicei este suficient să puneți:

$rcmail_config['default_host'] = 'localhost';

Și ne putem autentifica. Deschidem dintr-un browser adresa:

http://ip_server/roundcubemail/.

O să-mi spuneți că pe ubuntu este acel MOTD care ne avertizează la fiecare autentificare prin SSH. Să fiu sincer unul din primele lucruri după instalarea unui server bazat pe ubuntu este să șterg pachetele landscape-common și update-notifier-common, deci acel MOTD nu mai apare, autentificarea pe SSH e mult mai rapidă, etc.

Și atunci soluția este să instalăm pachetul cron-apt(mai există și pachetul apticron dar nu e atât de ușor de configurat). Dăm comanda

apt-get install cron-apt

După instalare ne asigurăm că acesta va și instala automat pachetele noi apărute. Implicit cron-apt este configurat doar să descarce pachetele pentru o instalare mai facilă. Pentru aceasta în directorul /etc/cron-apt/action.d vom crea un fișier nou cu numele: 4-install în care vom scrie:

dist-upgrade -y

Următorul pas este să verificăm că aplicația cron-apt va fi rulată în fiecare zi. Pentru aceasta verificăm conținutul fișierului /etc/cron.d/cron-apt să aibă decomentată linia numărul 5, unde daemonul cron va fi programat să ruleze comanda cron-apt în fiecare noapte la ora 4.

Ultimul pas este să verificăm că daemonul cron este pornit

service cron status

PHP până nu demult rula în apache doar folosind MPM-ul prefork. În acest MPM(Multi-Processing Module) fiecare client este servit de către un proces separat al Apache pornit în prealabil și care „așteaptă” să servească clientul. Se configurează numărul maxim de cereri pe care îl va servii acest proces pre-deschis și astfel se acumulează în memoria serverului web cache-uri de la fiecare fișier PHP rulat.

În MPM-ul worker serverul web poate servii mai mulți clienți(mai multe cereri) folosind același proces, pe mai multe thread-uri. De asemena câteva procese sunt păstrate latente pentru momentele în care procesele care servesc inițial cererile for fi prea ocupate. Chiar de la prima vedere putem observa că posibilitatea ca un client să ceară aceeași frântură de cod PHP existentă în cache este mult mai mare. Problema este că folosind MPM-ul worker nu vom putea rula nativ codul PHP și va fi nevoie să-l folosim prin intermediul modulului FastCGI.

Instalăm serverul web apache, varianta cu MPM-ul worker,  modulul FastCGI și SuExec.

apt-get install apache2-mpm-worker libapache2-mod-fcgid apache2-suexec

Instalăm php5-cgi, pachetul care permite rularea PHP-ului prin modulul fastcgi.

apt-get install php5-cgi

Activăm modulele:

a2enmod suexec fcgid

Presupunem din start că serverul nostru web servește mai multe site-uri și vom începe cu crearea unui utilizator,  ne inclusiv în faptul că îl putem folosi pentru FTP dar și la rularea PHP-ului.

adduser vhost1 --home /var/www/vhost1 --shell /bin/false

Creem directoarele suplimentare necesare

cd /var/www/vhost1/
mkdir htdocs tmp
chown -R  vhost1.vhost1 .

Edităm fișierul ce conține informațiile despre site-ul nostru(/etc/apache2/sites-available/vhost1)

<VirtualHost *:80>
        ServerAdmin webmaster@vhost1
        ServerName vhost1
        ServerAlias www.vhost1
        DocumentRoot /var/www/vhost1/htdocs
        ErrorLog /var/log/apache2/vhost1_error.log
        CustomLog /var/log/apache2/vhost1_access.log combined
        SuexecUserGroup vhost1 vhost1
 
                # SocketPath /tmp/fcgid_sock/
                IdleTimeout 3600
                ProcessLifeTime 7200
                # MaxProcessCount 1000
                DefaultMinClassProcessCount 3
                DefaultMaxClassProcessCount 100
                IPCConnectTimeout 8
                IPCCommTimeout 360
                BusyTimeout 300
 
                Options Indexes FollowSymLinks MultiViews +ExecCGI
                AllowOverride All
                Order allow,deny
                allow from all
        AddHandler fcgid-script .php .php3 .php4 .php5
        FCGIWrapper /var/www/vhost1/.php-fcgi-starter .php
</VirtualHost>

Din rațiuni de securitate SuexecUserGroup are ca parametrii numele de utilizator și grupul cu care vom încărca fișierele PHP în rădăcina acelui site. În felul acesta PHP-ul va fi rulat sub permisiunile utilizatorului respectiv și nu va mai fi nevoie să modificăm permisuni ale fișierelor de pe disc atunci când o aplicație are nevoie să scrie anumite fișiere pe disc.

Creem scriptul care pornește PHP-ul (/var/www/vhost1/.php-fcgi-starter) cu următorul conținut:

#!/bin/sh
PHPRC="/etc/php5/cgi/"
export PHPRC
PHP_DOCUMENT_ROOT="/var/www/vhost1/htdocs"
export PHP_DOCUMENT_ROOT
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /usr/bin/php-cgi \
 -d open_basedir="/var/www/vhost1/htdocs:/usr/share/php5:/tmp:/usr/share/phpmyadmin" \
-d upload_tmp_dir=/var/www/vhost1/tmp \
-d session.save_path=/var/www/vhost1/tmp \
 $1

În cazul în care avem nevoie ca din PHP să folosim alte fișiere de pe disc decât cele din rădăcina acelui site vom modifica în acest scrip opțiunea open_basedir. Este în general bine să nu lăsăm PHP-ul să deschidă alte fișiere de pe disc din rațiuni de securitate.

Modificăm permisiunile acestui fișier:

chmod 755 /var/www/vhost1/.php-fcgi-starter
chown vhost1.vhost1 /var/www/vhost1/.php-fcgi-starter

Activăm site-ul și repornim Apache

a2ensite vhost1
/etc/init.d/apache2 restart

Pentru a verifica că PHP-ul funcționează creem un fișier info.php în directorul /var/www/vhost1/htdocs cu următorul conținut:

Deschidem browserul și accesăm adresa serverului web (http://vhost1/info.php). Ar trebui să se deschidă o pagină în următorul format.

Pentru a putea încărca fișierele prin FTP nu ne rămâne decăt să instalăm un server FTP.

apt-get install proftpd

Modificăm în /etc/proftpd/proftpd.conf și scoatem #-ul din fața liniei

RequireValidShell               off

Mai trebuie să instalăm MySQL ca să avem un „LAMP” complet

apt-get install mysql-server

PS Rămâne de văzut cum se comportă în practică atunci când vorbim de performanță

JFolder::create: Infinite loop detected
Unable to create destination

To make everything possible go to ISPConfig Control Pannel to Sites, choose your site, go to Options and change the Option for PHP open_basedir option like /var/www/clients/client1/web4/web to /var/www/clients/client1/web4. Save and wait for the ISPConfig cron to happen (about 1 minute) and try updating Joomla Again.

Iată și un mic filmuleț despre procedura de actualizare de la 3.0.2 la 3.0.3 pe Debian Lenny pe 32 de biți.

(În format liber aici)

Explicația e simplă se rulează comana ispconfig_update.sh și se urmează instrucțiunile.

La prima vedere tema este unpic stilizată, apare ideea de Dashboard, adică o pagină principală cu informații despre contul de hosting/resellter și într-adevăr apar noile funcționalități în meniuri, rămâne de văzut cum se lucrează efectiv cu ele.

Adăugăm în /etc/apt/sources.list următoarea linie

deb http://backports.debian.org/debian-backports lenny-backports main

Actualizăm lista de pachete disponibilă în distribuție cu comand:

apt-get update

Instalăm pachetul:

apt-get install linux-image-2.6.32-bpo.5-686

Repornim calculatorul și ne putem bucura de noul kernel.

Pentru o listă completă de pachete kernel disponibilă rulăm comanda:

apt-cache search linux-image

apt-get install arpwatch

Pentru configurarea aplicației vei edita /etc/default/arpwatch și treci acolo:

ARGS="-N -p -i eth0 -m adresa@email.tld"

În loc de eth0 vei trece interfața internă de rețea iar în loc de adresa@email.tld vom trece adresa de e-mail unde dorim să fim notificați atunci când apare un dispozitiv nou în rețea.

Nu de puține ori dorim ca căsuțele de e-mail de la firmă să fie găzduite pe propriul server de e-mail. Acest lucru poate avea mai multe cauze mai mult sau mau puțin obective: serviciile de găzduire sunt prea scumpe, informațiile tranzitate sunt sensibile/cu caracter confidențial, vrem să avem control deplin asupra informațiilor tranzitate prin serverul de e-mail sau pur și simplu dorim să plătim niște bani în plus pentru un Exchange server sau SBS.

1. Firewall. Dacă nu putem să punem serverul de e-mail într-un DMZ este bine cel puțin să configurăm un firewall pentru acesta. Presupunem că un atacator vrea să fure informațiile de pe serverul de e-mail. Acesta încearcă să-l atace și nu reușește. Îl scanează și vede că pe acesta mai rulează încă niște servicii. Dacă firewall-ul sau IDS/IPS-ul  îl oprește atunci se va lăsa păgubaș.
2. Filtru anti-virus și anti-spam. Pur și simplu nu pot percepe ca un server de e-mail din zilele noastre să nu scaneze email-urile de viruși/spam. Domeniul este foarte vast, este greu să vă spun care soluție să o implementați, care e mai bună și care nu. Puteți alege soluții libere(SpamAssassin și ClamAV) sau chiar soluții comerciale.
3. Blocarea portului 25 în rețea. Este în general un lucru bun ca din rețeaua locală să poată fi accesat doar serverul de e-mail propriu. Se întâmplă în ultima vreme destul de des ca cel puțin o stație din rețea să se viruseze și să trimită mesaje de tip spam pe internet. Filtrele anti-spam ar lua-o razna în primul rând datorită faptului că IP-ul(IP-urile) rețelei firmei intră în RBL-uri. Dacă aveți angajați care solicită acces la portul 25 înseamnă că aceștia vor să folosească alt server de e-mail, poate unul personal și va trebui să vă gândiți la seriozitatea acelui angajat. O altă posibilitate este ca routerul să facă DNAT pentru portul 25 către propriul server de e-mail.
4. STARTTLS. Este bine ca serverul nostru de e-mail să comunice criptat cel puțin cu acele servere de e-mail cu care poate. Există servere de e-mail care nu suportă acest mod de comunicare. Pentru a verifica acest lucru folosim comanda telnet

   server:~# telnet localhost 25
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   220 localhost ESMTP Postfix (Debian/GNU)
   EHLO mail
   250-localhost
   250-PIPELINING
   250-SIZE 10240000
   250-VRFY
   250-ETRN
   250-STARTTLS
   250-AUTH LOGIN PLAIN
   250-AUTH=LOGIN PLAIN
   250-ENHANCEDSTATUSCODES
   250-8BITMIME
   250 DSN
   QUIT
   221 2.0.0 Bye
   Connection closed by foreign host.

   Observăm că la comanda EHLO că serverul de e-mail răspunde cu 250-STARTTLS

5. IMAPs/POP3s. Este recomandat ca serviciile POP3 și IMAP să funcționeze criptat. Chiar dacă cineva încearcă prin Internet să intercepteze comunicația aceasta este criptată și îi este cel puțin mai greu să intercepteze ceva.
6. HTTPS pentru webmail. Povestea e aceeași ca la punctul anterior. Dacă tot veni vorba de webmail feriți-vă de Squirrelmail, este mai degrabă o interfață de citit e-mail-ul decât un webmail.
7. Luați în considerare existența unui VPN. Uneori citirea e-mailurilor este mai sigură dacă se întâmplă printr-un VPN. În felul acesta serviciile POP3/IMAP pot fi închise publicului larg. În materie de VPN evitați folosirea VPN-ului de tip pptp, deși configurarea este foarte ușoară pot apărea diverse probleme, de securitate sau chiar de funcționalitate, de exemplu este posibil ca de pe unele rețele wireless să nu funcționeze.
8. Software-ul trebuie întreținut! Dacă aveți personal dedicat angajat în vederea  întreținerii hardware/software a rețelei este bine ca acel om să întrețină și serverul de e-mail, adică să-l actualizeze, să-l monitorizeze(o simplă verificare zilnică), să primească mesajele de sistem. Dacă nu, apelați la o firmă care să facă asta pentru dumneavoastră.

În final v-aș recomanda să folosiți un server de e-mail bazat pe linux, acestea necesită mult mai puține cheltuieli de instalare și întreținere și se dovedesc a fi mult mai fiabile. Dacă-mi scapă ceva vă invit să comentați.

Sursa imaginii aici.

Sap unpic mai adânc și dau de Stallone. Acesta este un mic daemon implementează acest protocol și se folosește de iptables pentru a translata poturi către calculatorul din spatele routerului. Ca acesta să funcționeze va trebui mai întâi să activați din firewall portul UDP 5351. Pentru compilare pe Debian este nevoie și de pachetul libdaemon-dev.

Instalarea pe Debian 5 (Lenny):

wget http://tedp.id.au/stallone/releases/stallone-0.2.0.tar.gz # Descărcăm și dezarhivăm pachetul pachetul
tar xzvf stallone-0.2.0.tar.gz
cd stallone-0.2.0
./configure --prefix=/usr/local/stallone # Configurarea și compilarea
make
make install

Trecem în fișierul /etc/rc.local înainte de „exit 0”:

/usr/local/stallone/sbin/stallone -D

Cam asta e tot. De acum împărți mai ușor fișiere prin bittorrent.

mysql_secure_installation

și să alegem opțiunile recomandate.

Nu de puține ori în ultima vreme lumea își instalează linux. Motivele pentru care nu își instalează și daemon-ul de ssh sunt multiple: neatenție, grabă, necunoaștere. Din păcate cam asta e ordinea în care se întâmplă lucrurile. Iată cum puteți instala foarte ușor acest daemon ce vă permite accesul de la distanță:

În Ubuntu:

sudo apt-get update
sudo apt-get install openssh-server openssh-client

În CentOS/Fedora:

yum install openssh-server openssh-clients

Se pare că whois-ul din Hardy(Ubuntu 8.04) e o versiune unpic mai veche și nu cunoaște aceste AS-uri. Ca să funcționeze totul corect va trebui să facem un update. Descărcăm pachetul avânt ultima versiune de la adresa și il înstalăm.

wget http://ftp.debian.org/debian/pool/main/w/whois/whois_4.7.31_amd64.deb
dpkg -i whois_4.7.31_amd64.deb

PS! Exemplul este pentru distribuția pe 64 de biți.

Nu de puține ori dăm câte un ping la serverul respectiv, numai ca să verificăm că funcționează. Ce facem? Îl facem să accepte ping numai de la anumite adrese? Dacă se virusează astea și fac mai mult rău decât restul internetului la un loc?

Eu vă recomand așa:

• creem un lanț nou, ICMP și direcționătm tot traficul ICMP către el(practica spune că e bine să creem grupurile de reguli ce țin de un anume protocol sau de un serviciu în lanțuri separate)

iptables -N ICMP
iptables -A INPUT -p icmp -j ICMP
iptables -A OUTPUT -p icmp -j ICMP
iptables -A FORWARD -p icmp -j ICMP

• jurnalizăm și ignorăm pachetele ce depășesc de o anumită dimensiune (pachetele de control în general nu depășesc 1500, adică mai mult de cât MTU, dacă sunt mai mari e clar că ceva e în neregulă)

iptables -A ICMP -m length --length 1700:65507 -m limit --limit 1/sec -j LOG --log-prefix "ICMP TOO BIG: "
iptables -A ICMP -m length --length 1700:65507 -j DROP

• acceptăm pachetele de tipul care ne interesează și în anumite limite

iptables -A ICMP -p icmp -m limit --limit 10/sec --limit-burst 20 -m icmp --icmp-type 0 -j ACCEPT #echo-reply
iptables -A ICMP -p icmp -m limit --limit 10/sec --limit-burst 20 -m icmp --icmp-type 8 -j ACCEPT #echo-request
iptables -A ICMP -p icmp -m limit --limit 3/sec -m icmp --icmp-type 3 -j ACCEPT #destination-unreachable (folosit la traceroute și mtr)
iptables -A ICMP -p icmp -m limit --limit 3/sec -m icmp --icmp-type 11 -j ACCEPT #time-exceeded
iptables -A ICMP -p icmp -m limit --limit 3/sec -m icmp --icmp-type 30 -j ACCEPT #traceroute
iptables -A ICMP -p icmp -m limit --limit 3/sec -m icmp --icmp-type 17 -j ACCEPT #address-mask-request
iptables -A ICMP -p icmp -m limit --limit 3/sec -m icmp --icmp-type 18 -j ACCEPT #address-mask-reply

• jurnalizăm și ignorăm restul pachetelor

iptables -A ICMP -m limit --limit 1/sec -j LOG --log-prefix "DROP ICMP: "
iptables -A ICMP -j DROP

Aștept sugestii