bash script - iptables block port 25 & 587

[fulltilt]

Moin,
ich bastele gerade an einem script welches die Anzahl der Mails im Queue per Cronjob überprüft und eine Benachrichtigung schickt sowie die Ports blockiert wenn z.b. mehr als 1000 Mails im Queue sind ...
Wie kann man das ganze noch verbessern, z.b. das nur einmal eine Benachrichtigung versendet wird und die Doppelaktion mit den 2 Ports ...
ist das so OK wenn ich && verwende?

Code: Alles auswählen

#!/bin/bash
EMAIL="user@example.com"
LIMIT=1000
QVALUE=`find /var/spool/postfix/deferred -type f -print | wc -l`
WARNING="Your mail queue is over $LIMIT, please investigate."
if
[ "$QVALUE" -ge "$LIMIT" ] ; then
echo "Check the Mailqueue!" | mail -s "$WARNING" $EMAIL 
/sbin/iptables -A OUTPUT -p tcp --dport 25 -j REJECT && iptables -A OUTPUT -p tcp --dport 587 -j REJECT
fi

[eggy]

Bei dem zweiten iptables fehlt der Pfad. Und je nachdem was Du erreichen willst, ist es bei REJECT Regeln ganz gut statt -A (anfügen) lieber -I (voranstellen) zu nehmen, falls man vorher ne entsprechende ACCEPT Regel drin hatte greift das späte REJECT nicht mehr. Für mehrere Ports in einer Regel gabs auch mal was, schau mal nach multiport in der Manpage von iptables-extensions nach.

[heisenberg]

ich bastele gerade an einem script welches die Anzahl der Mails im Queue per Cronjob überprüft und eine Benachrichtigung schickt sowie die Ports blockiert wenn z.b. mehr als 1000 Mails im Queue sind ...

Hört sich so an, als ob Dein Server evtl. ein Spamproblem hat. Da wäre es vielleicht gut die Konfiguration des Mailservers zu prüfen oder ggf. die auch die Konfiguration und Aktivität Deines Webservers, falls die Mails darüber erzeugt werden.

[fulltilt]

ich bastele gerade an einem script welches die Anzahl der Mails im Queue per Cronjob überprüft und eine Benachrichtigung schickt sowie die Ports blockiert wenn z.b. mehr als 1000 Mails im Queue sind ...

Hört sich so an, als ob Dein Server evtl. ein Spamproblem hat. Da wäre es vielleicht gut die Konfiguration des Mailservers zu prüfen oder ggf. die auch die Konfiguration und Aktivität Deines Webservers, falls die Mails darüber erzeugt werden.

Nee kein Spamproblem, alle Mailserver sind save und werden überwacht ... ist nur ne automatisierte Vorsichtsmassnahme, stört dich etwas daran?
Es sind halt ne Menge Mailkonten drauf und CMS ... solche Probleme treten auf wenn ein Mailkonto wg. unsicheren Passwd gehackt wird oder eine unsichere PHP Anwendung gehackt wurde, hab ich oft genug erlebt

[fulltilt]

hier mal das überarbeitete Script ...
wenn eine Warn Mail gesendet werden soll, wird vorher geprüft ob die Datei mailqsend bereits existiert, wenn nicht wird eine Warnemail versendet.
Falls die Mails unter dem Mail Warn Limit liegen, werden die Ports wieder aufgemacht und die mailqsend wieder entfernt ...

Könnt ihr mal drüberschauen ob es so stimmt?

Code: Alles auswählen

#!/bin/bash
EMAIL="user@example.com"
LIMIT=200  
QVALUE=`find /var/spool/postfix/deferred -type f -print | wc -l`
WARNING="Host1 Mail Queue is over $LIMIT"
if
 [ "$QVALUE" -ge "$LIMIT" && ! -f /root/mailqsend ] ; then
 echo "Host1 - Check the Mailqueue!" | mail -s "$WARNING" $EMAIL && touch /root/mailqsend
fi

LIMIT2=500  
if
 [ "$QVALUE" -ge "$LIMIT2" ] ; then
 /sbin/iptables -I OUTPUT -p tcp --dport 25 -j REJECT && /sbin/iptables -I OUTPUT -p tcp --dport 587 -j REJECT 
fi

if
 [ ! -f "$QVALUE" -ge "$LIMIT" ] ; then
 rm /root/mailqsend && /sbin/iptables -A INPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT && /sbin/iptables -A INPUT -m state --state NEW -p tcp --dport 587 -j ACCEPT
fi

[heisenberg]

Mich stört da nix dran. Bisher war so etwas nur nicht unbedingt mein Ansatz, was mich dazu veranlasst, darüber nachzudenken, ob ich so eine Massnahme für mich als sinnvoll erachte. Mit der Problematik bin ich auch ganz gut vertraut.

Eine Art automatischer Notstop ist eine Massnahme, die durchaus einen gewissen Sinn hat.

Die Mailqueue überwache ich unter anderem auch. Wenn allerdings 1000 Mails in der Queue sind, dann ist das Kind eigentlich schon in den Brunnen gefallen, weil so viele Mails verzögert werden bzw. abgelehnt werden, weil schon extrem viel Spam(oder auch nicht Spam) versandt wurde. Deswegen habe ich mich dazu entschieden, die Anzahl der verarbeiteten Mails zu überwachen

Meine Massnahmen hier sind:

• Fail2Ban einsetzen inkl. längerer Sperrzeiten für hartnäckigere Scripte (Google: f2b-loop) gegen BruteForce-Attacken auf den Mailserver
• Überwachen der Zahlen von gesendeten, verzögerten und abgelehnten Mails mit meinem Monitoring Plugin(postfix processed mails). Das kann man auch ohne das dahinterliegende Monitoringsystem einsetzen.
• Regelmässiges überwachen der Blacklistings, da ich auch schon Fälle hatte, in der eine relativ geringe Menge an versendeten Spams Störungen verursacht hat. Hier ist ein Script dazu: postfix_rbl. Das Script ist etwas krude, aber es tut seinen Job.
• pflogsumm.pl ist auch immer ganz hilfreich und mailgraph

[fulltilt]

Meine Massnahmen hier sind:

• Fail2Ban einsetzen inkl. längerer Sperrzeiten für hartnäckigere Scripte (Google: f2b-loop) gegen BruteForce-Attacken auf den Mailserver
• Überwachen der Zahlen von gesendeten, verzögerten und abgelehnten Mails mit meinem Monitoring Plugin(postfix processed mails). Das kann man auch ohne das dahinterliegende Monitoringsystem einsetzen.
• Regelmässiges überwachen der Blacklistings, da ich auch schon Fälle hatte, in der eine relativ geringe Menge an versendeten Spams Störungen verursacht hat. Hier ist ein Script dazu: postfix_rbl. Das Script ist etwas krude, aber es tut seinen Job. Es prüft welche IPs von Postfix zum Versand verwendet werden(oder alle) und prüft bei mehreren Aufrufen alle 15 Min die wichtigsten Blacklisten und alle 24 Stunden alle Blacklisten für die betreffenden IPs.
• pflogsumm.pl ist auch immer ganz hilfreich und mailgraph

Danke, das postfix_rbl Script sieht gut aus
pflogsumm und mailgraph verwende ich bereits

[heisenberg]

Nachtrag

Die veröffentlichte Variante hat das wohl noch nicht drin mit den 15 Min für die wichtigsten Listen und 24 Stunden für alle Blacklisten.

[fulltilt]

hier nochmal die verbesserte Variante, sollte jetzt klappen

Code: Alles auswählen

#!/bin/bash
EMAIL="user@example.com"
LIMIT=200  
QVALUE=`find /var/spool/postfix/deferred -type f -print | wc -l`
WARNING="Host1 Mail Queue is over $LIMIT"
if
 [ "$QVALUE" -ge "$LIMIT" ] && [ ! -f /root/mailqsend ] ; then
 echo "Host1 - Check the Mailqueue!" | mail -s "$WARNING" $EMAIL && touch /root/mailqsend
fi

LIMIT2=500  
if
 [ "$QVALUE" -ge "$LIMIT2" ] ; then
 /sbin/iptables -I OUTPUT -p tcp --dport 25 -j REJECT && /sbin/iptables -I OUTPUT -p tcp --dport 587 -j REJECT 
fi

if
[ "$QVALUE" -lt "$LIMIT" ] && [ -f /root/mailqsend ] ; then
 rm /root/mailqsend && /sbin/iptables -A INPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT && /sbin/iptables -A INPUT -m state --state NEW -p tcp --dport 587 -j ACCEPT
fi

[eggy]

Ich glaub da ist noch nen Problem mit dem was Du erreichen willst gegen das was das Script tut ...
geh ich richtig in der Annahme, dass der letzte Block des Scripts das ganze wieder freischalten soll?

Dann solltest Du lieber -D (Regel entfernen) nehmen, denn was zur Zeit passiert: Die REJECT Regeln bleiben drin, und gelten immer, egal was das Script am Ende noch an ACCEPT angefügt hat. Allerdings ist die richtige Regel finden unter Umständen nicht ganz so einfach, insbesondere falls eh mehrere von Ihnen gibt. Ich würde daher eher ne neue Kette "MAIL" anfügen, alles auf den entsprechenden Ports darein umleiten und dort dann nur eine Regel haben, die kannst Du dann treffsicher mit "iptables --list MAILKETTE --line-numbers" auslesen und deren Zustand gezielt mit -R (glaub ich, schau nochmal in die manpage) ändern.

[heisenberg]

Ich arbeite beim Sperren und wiederaufheben der Sperren von Iptables mit comments. Hier mal ein Beispiel, wie eine Anwendung bei mir aussieht:

Code: Alles auswählen

LOCK_ID=MAILLOCKDOWN
PORTS="25 587"

function lock_ports {

        local PORTS="$1"
        local LOCK_ID="$2"
        RULE_IDS="$( iptables -L INPUT -v -n --line-numbers| grep "$LOCK_ID" | awk '{print $1}' | tac )"
        read -r -a PORTS <<< "$PORTS"
        local PORTLIST=$(IFS=, ; echo "${PORTS[*]}")
        iptables -N LOCKDOWN
        iptables -A LOCKDOWN -p tcp -m multiport -m comment --dports $PORTLIST --comment="$LOCK_ID" -j REJECT
        iptables -I INPUT 1 -p tcp -m comment --comment="$LOCK_ID" -j LOCKDOWN

}

function unlock_ports {
 
        local LOCK_ID="$1"
        RULE_IDS="$( iptables -L INPUT -v -n --line-numbers| grep "$LOCK_ID" | awk '{print $1}' | tac )"
        for RULE in $RULE_IDS;do
            iptables -D INPUT $RULE
        done
        iptables -F LOCKDOWN
        iptables -X LOCKDOWN
}

# sperren
lock_ports "$PORTS" "$LOCK_ID"

# freigeben
unlock_ports "$LOCK_ID"

[fulltilt]

Ich glaub da ist noch nen Problem mit dem was Du erreichen willst gegen das was das Script tut ...
geh ich richtig in der Annahme, dass der letzte Block des Scripts das ganze wieder freischalten soll?

danke eggy, reicht es so aus mit -D oder besser noch die ACCEPT rules anschliessend mit anhängen?

Code: Alles auswählen

#!/bin/bash
EMAIL="user@example.com"
LIMIT=200
QVALUE=`find /var/spool/postfix/deferred -type f -print | wc -l`
WARNING="Host1 Mail Queue is over $LIMIT"
if
 [ "$QVALUE" -ge "$LIMIT" ] && [ ! -f /root/mailqsend ] ; then
 echo "Host1 - Check the Mailqueue!" | mail -s "$WARNING" $EMAIL && touch /root/mailqsend
fi

LIMIT2=1000
if
 [ "$QVALUE" -ge "$LIMIT2" ] ; then
 /sbin/iptables -I OUTPUT -p tcp --dport 25 -j REJECT && /sbin/iptables -I OUTPUT -p tcp --dport 587 -j REJECT 
fi

if
 [ "$QVALUE" -lt "$LIMIT" ] && [ -f /root/mailqsend ] ; then
 rm /root/mailqsend && /sbin/iptables -D OUTPUT -p tcp --dport 25 -j REJECT && /sbin/iptables -D OUTPUT -p tcp --dport 587 -j REJECT
fi

[fulltilt]

wow, sehr geil ... werd ich gelich mal testen.

Ich arbeite beim Sperren und wiederaufheben der Sperren von Iptables mit comments. Hier mal ein Beispiel, wie eine Anwendung bei mir aussieht:

Code: Alles auswählen

LOCK_ID=MAILLOCKDOWN
PORTS="25 587"

function lock_ports {

                local PORTS="$1"
                local LOCK_ID="$2"
                RULE_IDS="$( iptables -L INPUT -v -n --line-numbers| grep "$LOCK_ID" | awk '{print $1}' | tac )"
                read -r -a PORTS <<< "$PORTS"
                local PORTLIST=$(IFS=, ; echo "${PORTS[*]}")
                iptables -N LOCKDOWN
                iptables -A LOCKDOWN -p tcp -m multiport -m comment --dports $PORTLIST --comment="$LOCK_ID" -j REJECT
                iptables -I INPUT 1 -p tcp -m comment --comment="$LOCK_ID" -j LOCKDOWN
        fi
}

function unlock_ports {
        local LOCK_ID="$1"
        RULE_IDS="$( iptables -L INPUT -v -n --line-numbers| grep "$LOCK_ID" | awk '{print $1}' | tac )"
        for RULE in $RULE_IDS;do
            iptables -D INPUT $RULE
        done
        iptables -F LOCKDOWN
        iptables -X LOCKDOWN
}

# sperren
lock_ports "$PORTS" "$LOCK_ID"

# freigeben
unlock_ports "$LOCK_ID"

[heisenberg]

Vorsicht, in der zitierten Variante war noch ein Fehler drin, den ich oben nochmal korrigiert habe.

[fulltilt]

Vorsicht, in der zitierten Variante war noch ein Fehler drin, den ich oben nochmal korrigiert habe.

TOP, danke dir!

[eggy]

Ob du am Ende noch ein ACCEPT brauchst oder nicht hängt von der POLICY ab.
Schau dir mal die Ausgabe von iptables --list -nv --line-numbers an. Ganz grob kannst Du sagen iptables geht immer von oben nach unten durch, der erste Treffer gewinnt (Log targets und co ignorieren wir erstmal), und wenns keinen Treffer gab, dann greift die Policy.

vereinfachtes Beispiel:
INPUT Policy DROP
1. ... -dport 23 -j ACCEPT
2. ... -dport 23 -j DROP

a) Pakete mit dport 23 werden akzeptiert (Regel 1 greift, Regel 2 wird nicht mehr angesehn, Policy ebenfalls nicht)
b) Pakete mit dport 42 werden verworfen (Keine Regel hat gepasst, Policy muss einspringen)

[heisenberg]

Ob du am Ende noch ein ACCEPT brauchst oder nicht hängt von der POLICY ab.
Schau dir mal die Ausgabe von iptables --list -nv --line-numbers an. Ganz grob kannst Du sagen iptables geht immer von oben nach unten durch, der erste Treffer gewinnt (Log targets und co ignorieren wir erstmal), und wenns keinen Treffer gab, dann greift die Policy.

WARNUNG Ist die Policy auf Drop, ist alles abgeschaltet, was nicht explizit freigschaltet ist. Das heisst, da ist auch mal ganz schnell der SSH-Zugang weggeschossen und wenn man's brav sofort rebootfest gemacht hat, kommt man nur noch mit dem Rettungssystem/RemoteConsole/Lokaler Konsole dran oder darf neuinstallieren, wenn die Optionen nicht zur Verfügung stehen.

[fulltilt]

Danke Jungs, hat mir sehr viel weiter geholfen