WCM Forum

WCM Forum (http://www.wcm.at/forum/index.php)
-   IT-Security (http://www.wcm.at/forum/forumdisplay.php?f=70)
-   -   [MTA] Vornamen-Attacke (http://www.wcm.at/forum/showthread.php?t=131355)

paux 14.04.2004 12:10

[MTA] Vornamen-Attacke
 
Hallo!

Nett zu wissen, daß mein kleiner Postfix-Mailserver prinzipiell bis zu 40 Messages pro Sekunde rejecten kann, aber das grenzt ja schon an DoS: Wie kann ich so lustige Vornamen-Versuche wie josh@mydomain, kristy@mydomain usw. unterbinden?

Nutzt Teergrubing was, oder ist das eher für was anderes gedacht? Es würde ja schon reichen, ein Flooding zu verhindern, ohne jetzt extra eine IPTABLES-TCP-Synflood-Regel für Port 25 anzulegen - MaW: Geht da was MTA-seitig?

TIA for your tips.

lg paux

EDIT: Hä?
Code:

# Overall Limit for TCP-SYN-Flood detection
TCPSYNLIMIT="5/s"
# Burst Limit for TCP-SYN-Flood detection
TCPSYNLIMITBURST="10"

Wie sind dann so viele Verbindungen möglich? Oder gingen die Rejects einfach "in einer Wurst" ins Log?

_m3 14.04.2004 12:37

Re: [MTA] Vornamen-Attacke
 
Zitat:

Original geschrieben von paux
Hallo!

Nett zu wissen, daß mein kleiner Postfix-Mailserver prinzipiell bis zu 40 Messages pro Sekunde rejecten kann, aber das grenzt ja schon an DoS: Wie kann ich so lustige Vornamen-Versuche wie josh@mydomain, kristy@mydomain usw. unterbinden?

Ein kleines Script, das nach X Versuchen die IP des Absenders in der FW blockt?

paux 14.04.2004 12:43

Klein? Naja, die Logs zu parsen und die Zeitdifferenzen zu ermitteln ist für mich nicht mehr so klein :)

_m3 14.04.2004 12:54

Zitat:

slowing down spambots with an error tarpit

Spambots are often not well-behaved and rfc-compliant, so if you turn on strict checking, the spambots will frequently cause errors during the SMTP dialogue. Also, if they are trying a dictionary attack, and you do not have a wildcard alias, this will cause lots of unknown user errors.

If the spambot has exceeded the number of errors specified by the variable smtpd_soft_error_limit, it will sleep that many seconds, otherwise it will wait for smtpd_error_sleep_time before returning a [45]XX error code. (So smtpd_soft_error_limit should be greater than or equal to smtpd_error_sleep_time). And if the number of errors exceeds smtpd_hard_error_limit then Postfix disconnects and the spambot will have to reconnect. I set the sleep time long enough to cause the spambot to either time out or be killed by a frustrated spammer.

Spambots may also open multiple simultaneous connections in order to deliver massive quantities (or to do a fast dictionary attack), so for an MTA running only for personal use, I think it is good to also set default_process_limit to a low number, which will limit the number of simultaneous SMTP sessions. Here's what I use:

smtpd_error_sleep_time = 60
smtpd_soft_error_limit = 60
smtpd_hard_error_limit = 10
default_process_limit = 3

[Note that these particular settings work for my site that receives email for one user, but will probably cause unnecessary delays on larger sites. You might try shorter delays and larger process limits.]

This combination should be very effective against a dictionary attack, particularly if you don't have a wildcard alias (which is why I recommend against having one). After every unknown user error, the server will sleep for 60 seconds, and will disconnect after every 10 errors.

Spammers are hit and run artists. The quicker they can complete their spam run, the better for them as filters and blackhole listings go up very quickly these days. I think it helps to do what you can to slow them down as much as possible.
http://www.bagley.org/~doug/spam/postfix.shtml

Auch gut:
http://techrepublic.com.com/5100-631...l?tag=viewfull

paux 14.04.2004 14:22

danke, schaut super aus, werd das durchgehen und auch noch was suchen bzgl dialup-IP-rejecting.

lg paux

valo 14.04.2004 23:37

das

smtpd_helo_required = yes
strict_rfc821_envelopes = yes

in verbindung mit

reject_non_fqdn_sender,
reject_non_fqdn_recipient,

bei den smtpd_recipient_restrictions blockt schon sehr viele von diesen automatischen spamschleudern...

in meiner main.cf schaut der smtpd_recipient_restrictions part so aus:

smtpd_recipient_restrictions =
check_helo_access hash:/etc/postfix/helo_checks,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
# reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_unauth_destination,
# check_recipient_access hash:/etc/postfix/recipient_checks,
# check_helo_access hash:/etc/postfix/helo_checks,
# check_sender_access hash:/etc/postfix/sender_checks,
# check_client_access hash:/etc/postfix/client_checks,
reject_unauth_pipelining,
reject_invalid_hostname,
reject_non_fqdn_hostname,
# reject_rbl_client relays.ordb.org,
# reject_rbl_client proxy.relays.osirusoft.com,
# reject_rbl_client socks.relays.osirusoft.com
# check_sender_access hash:/etc/postfix/rhsbl_sender_domain_exceptions,
# reject_rhsbl_sender dsn.rfc-ignorant.org
# check_sender_access hash:/etc/postfix/frequently_forged_senders
permit


Alle Zeitangaben in WEZ +2. Es ist jetzt 05:07 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag