ARP-Cache unter Linux vergrößern
Geschrieben am 16. Dezember 2009 um 14:17 Uhr Kein Kommentar
Die Ursachen von Verbindungsabbrüchen in einem größeren LAN zu finden ist schwierig, in meinem Fall war die ARP-Tabelle des Routers voll. Auf Debian-Systemen ist sie standardmäßig auf 1024 Einträge begrenzt. Ist der Adressraum des Netzwerks größer, könnte jemand allein durch einen Ping-Scan die ARP-Tabelle des Routers füllen. Wenn das passiert, ist im Kernel-Log folgende Meldung zu lesen.
Die Begrenzung lässt sich mit folgenden Befehlen festlegen - ersteres ist das Hardlimit, das andere das Softlimit.Dec 16 09:08:19 router kernel: [14468939.388404] Neighbour table overflow.
echo 65536 > /proc/sys/net/ipv4/neigh/default/gc_thresh3 echo 32768 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 |
Um die Optionen dauerhaft zu speichern, sollten sie in die sysctl.conf eingetragen werden.
net.ipv4.neigh.default.gc_thresh2=32768 net.ipv4.neigh.default.gc_thresh3=65536 |
Bye Bye Greylisting?
Geschrieben am 16. September 2007 um 15:13 Uhr 4 KommentareMatthias von adminlife.net hat seit neuestem Greylisting wieder ausgeschaltet, da er die Erfahrung gemacht hat, dass die Spammer sich bereits angepasst haben.
Bye Bye Greylisting! @ adminlife.net
Dies könnte bei mir ja theoretisch auch der Fall sein. Zudem sollte seit der Einrichtung von policyd-weight, die Anforderungen an das eingerichtete sqlgrey nicht mehr so hoch sein. Daher werde ich mal eine intensive Logfile-Analyse bereiben und sehen, wieviel Spam wirklich noch durch sqlgrey abgefangen wird und was durch die Tests von policyd-weight abgefangen wird.
Das Abschaffen von sqlgrey hätte natürlich den Vorteil der unverzögerten Mailzustellung, die man aber – ehrlich gesagt – vielleicht einmal im Monat wirklich braucht.
Meine Erkenntnisse werde ich dann hier posten.
Wie sieht es bei euch aus? Habt ihr sqlgrey/postgrey in Aktion? Hat sich die “Abfangrate” verschlechtert? Welche Kombination von Spamtools setzt ihr ein?
Postfix: optimierte Konfiguration gegen Spam und Missbrauch
Geschrieben am 13. September 2007 um 1:47 Uhr 2 KommentareIn einem früheren Artikel versprach ich, eine Postfix-Konfiguration zu posten, die nach (meinen) neuen Erkentnissen eingerichet ist.
So sah meine Konfiguration nach der Einrichtung von sqlgrey aus:
[...]
smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_invalid_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unauth_destination
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_rbl_client dnsbl.ahbl.org
reject_rbl_client cbl.abuseat.org
reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client dul.dnsbl.sorbs.net
reject_rbl_client bl.spamcop.net
check_policy_service inet:127.0.0.1:60000
reject_unknown_client
warn_if_reject reject_unknown_hostname
permit
[...]
Mehrere Hinweise aus der Postfix-Mailgruppe brachten mich jedoch auf folgende Konfiguration, die weiter unten noch genauer erläutere:
#
# restrictions
#
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
smtpd_delay_reject = yes
#
# Recipient Restrictions
#
smtpd_recipient_restrictions =
reject_unlisted_sender
reject_unlisted_recipient
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_sasl_authenticated
permit_mynetworks
reject_invalid_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unauth_destination
#policyd-weight
check_policy_service inet:127.0.0.1:60001
#sqlgrey
check_policy_service inet:127.0.0.1:60000
reject_unknown_client
reject_unknown_hostname
permit
Es handelt sich hier natürlich nur um einen Ausschnitt aus der main.cf, diese Parameter sind sehr wichtig, wenn es darum geht, welche Mails von Postfix zur Zustellung angenommen werden.
sqlgrey: einfaches und robustes Greylisting
Geschrieben am 26. August 2007 um 17:43 Uhr 5 KommentareSpam nervt und stiehlt jedem Nutzer täglich Zeit. Um zu vermeiden, dass wir eines Tages nur noch mit dem Löschung von dubiosen Angeboten beschäftigt sind, müssen wir uns immer wieder mit Gegenmaßnahmen befassen. Eine dieser Gegenmaßnahmen ist Greylisting.
Was ist Greylisting?
Das Wort Greylisting entstand aus den Wörtern Blacklisting (in diesem Kontext: permanentes Verbot einer E-Mailadresse) und Whitelisting (permanente Erlaubnis für eine E-Mailadresse) und bezieht sich auf die Mischung dieser beiden Verfahren. Das Verfahren funktioniert vereinfacht wie folgt:
- Ein dem Mailserver unbekannter Absender (freund@absender.tld) möchte gern ein Mail an person1@mailserver.tld senden.
- Der Mailserver (mit installiertem Greylisting) aber lehnt die Übermittlung nach Erhalt der Absender und Zieladresse unter Angabe eines temporären Fehlers ab (meist mit einer Greylisting-Erklärung für das Logfile).
- Der Mailserver trägt die IP des Absendermailserver ( absender.tld, 123.123.123.123 ) zusammen mit dem Absender (freund@absender.tld) und der Zieladresse (person1@mailserver.tld) in seine Datenbank ein.
- Ein vernüftig konfigurierter Mailserver wird innerhalb der nächsten 10 bis 60 Minuten eine erneute Zustellung versuchen. So ist es auch und so versucht der Mailserver von freund@absender.tld erneut, die Mail an person1@mailserver.tld zu übergeben.
- Der Zielmailserver schaut nun wiederum in seine Datenbank, ob ihm diese Kombination aus Quell-IP (wahlweise auch Quell-Subnetz), Absender und Adressat bereits bekannt ist. Da dem in diesem Fall so ist, nimmt er die Mail an und bestätigt die Annahme.
Die Idee hinter dieser “Verkomplizierung” der Mailzustellung ist, dass die Spammaschinen entweder das Handling von temporären Fehlern ausgeschaltet oder dieses in Ihren Mailprogrammen/ -servern gar nicht implementiert haben, um den Durchsatz zu erhöhen.
Wie kann ich Greylisting einsetzen?
Da Greylisting wie oben erläutert noch vor der Annahme der Mail geschehen muss, kann man dieses entweder direkt im Mailserver integrieren (z.B. Plugin) oder alternativ dem Mailserver als Proxy vorschalten.
weiterlesen…



Stopp-Seite schließen und weiter - Close and continue

