I've inherited a botnet target
in [Postfix]
|
From: Matt Hayes on 26 May 2010 16:37 On 5/26/2010 4:32 PM, Ralf Hildebrandt wrote: > * Matt Hayes <dominian(a)slackadelic.com>: > >> postscreen doesn't require you to use RBL's during its checks, > > Ah yes, the earlytalking and all. > >> however, you have the ability to do so. The nice thing about doing RBL >> checks in postscreen is it stops connections from getting to the SMTPD, >> thus reducing system load. > > That's how I'm using it here. It's amazing :) > Yes I definitely love it. I've noticed afew things get through postscreen and then hit smtpd_recipient_restrictions and still fire on the same RBLs, which I'm still have in place for testing. Which I found odd, but figured it was a snapshot so I'd deal :) -Matt
From: Nataraj on 26 May 2010 16:46 brian wrote: > On 10-05-26 03:55 PM, Noel Jones wrote: >> >> Some random suggestions... >> >> Use a bogus MX record for the old domain if that domain has no valid >> mail recipients. Of course, some bots will connect to your A record >> anyway... > > OK, I like the sound of that. Per your other email, I think I did, a > long time ago, learn about A being used in the absence of an MX. That > seems familiar now. Thanks for the tip. > >> You can use "reject_unlisted_recipient" early in your >> smtpd_recipient_restrictions to dump connections to bad users early. A >> later RBL check will only apply to valid recipients. >> >> Set smtpd_hard_error_limit to a low number, such as 2, to disconnect >> clients after just a few errors. >> >> Set smtpd_error_sleep_time to 0 to get rid of bad clients without delay. > > I'll give all that a try. Does this order seem alright? > > smtpd_recipient_restrictions = > permit_mynetworks, > reject_unlisted_recipient, > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_non_fqdn_recipient, > reject_non_fqdn_sender, > reject_unauth_destination, > reject_unknown_recipient_domain, > reject_unauth_pipelining > >> I'll bet the postfix 2.7 "postscreen" feature will get rid of 1/2 or >> more of the bots before they every talk to you. >> >> Postfix 2.7 allows you to specify 521 for the various *_reject_code >> parameters to signal a disconnect. > > I've just been having a look at that. It does seem to be something > very useful in this situation. But, maybe the bogus MX will solve my > problems. > >> Increase the max number of smtpd listeners in master.cf to the highest >> number your memory will allow. > > What's the best way of determining that? > I have had success with lowering these 3 parameters as well, if even temporarily during an attack. The values should be chosen based on how many legitamite incoming connections you receive (so as not to limit those). Also beware that in some cases rate limiting can cause a buildup of incoming connection requests which could cause problems with your tcp/ip stack, but generally these have worked for me. smtpd_client_connection_count_limit = 6 smtpd_client_connection_rate_limit = 6 smtpd_client_message_rate_limit = 6 If you never want mail destined for the domain example.com, you can use setup a rule to reject it. I would think this would be quite fast. I would also use the bogus MX record to prevent as much traffic as possible form hitting the server. smtpd_recipient_restrictions = permit_mynetworks check_recipient_access hash:/etc/postfix/smtpd_recipient_access REST OF YOUR RESTRICTIONS In the file smtpd_recipient_access example.com REJECT "NO THANK YOU, WE ARE NOT EXCEPTING MAIL" Here's a simple script to build the hash file from smtpd_recipient_access #! /bin/bash /usr/sbin/postmap hash:/etc/postfix/smtpd_sender_access /bin/chgrp postfix smtpd_sender_access* /bin/chmod g=r,o-rwx smtpd_sender_access* Nataraj
From: Noel Jones on 26 May 2010 16:56 On 5/26/2010 3:12 PM, brian wrote: > On 10-05-26 03:55 PM, Noel Jones wrote: >> >> Some random suggestions... >> >> Use a bogus MX record for the old domain if that domain has no valid >> mail recipients. Of course, some bots will connect to your A record >> anyway... > > OK, I like the sound of that. Per your other email, I think I did, a > long time ago, learn about A being used in the absence of an MX. That > seems familiar now. Thanks for the tip. > >> You can use "reject_unlisted_recipient" early in your >> smtpd_recipient_restrictions to dump connections to bad users early. A >> later RBL check will only apply to valid recipients. >> >> Set smtpd_hard_error_limit to a low number, such as 2, to disconnect >> clients after just a few errors. >> >> Set smtpd_error_sleep_time to 0 to get rid of bad clients without delay. > > I'll give all that a try. Does this order seem alright? > > smtpd_recipient_restrictions = > permit_mynetworks, > reject_unlisted_recipient, > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_non_fqdn_recipient, > reject_non_fqdn_sender, > reject_unauth_destination, > reject_unknown_recipient_domain, > reject_unauth_pipelining I would suggest: smtpd_recipient_restrictions = permit_mynetworks reject_non_fqdn_recipient reject_unauth_destination reject_unlisted_recipient ## next line if you have postfix 2.3 or newer reject_unknown_reverse_client_hostname reject_non_fqdn_sender reject_non_fqdn_hostname reject_unknown_sender_domain reject_rbl_client zen.spamhaus.org recipients with unknown/invalid domains won't make it past reject_unauth_destination, so drop reject_unknown_recipient_domain. With postfix < 2.6, reject_unauth_pipelining belongs in smtpd_data_restrictions. smtpd_data_restrictions = reject_unauth_pipelining > >> I'll bet the postfix 2.7 "postscreen" feature will get rid of 1/2 or >> more of the bots before they every talk to you. >> >> Postfix 2.7 allows you to specify 521 for the various *_reject_code >> parameters to signal a disconnect. > > I've just been having a look at that. It does seem to be something very > useful in this situation. But, maybe the bogus MX will solve my problems. > Sorry, I'm reminded that postscreen is only available in the 2.8 snapshots at this time. The snapshots are "production quality" so feel confident to use them. >> Increase the max number of smtpd listeners in master.cf to the highest >> number your memory will allow. > > What's the best way of determining that? > Use ps or top to see how much RAM each smtpd uses, guesstimate from there. If system swaps, reduce. Postscreen will help with this, since a single postscreen process can handle thousands of connections. -- Noel Jones
From: Nataraj on 26 May 2010 17:10 Nataraj wrote: > brian wrote: >> On 10-05-26 03:55 PM, Noel Jones wrote: >>> >>> Some random suggestions... >>> >>> Use a bogus MX record for the old domain if that domain has no valid >>> mail recipients. Of course, some bots will connect to your A record >>> anyway... >> >> OK, I like the sound of that. Per your other email, I think I did, a >> long time ago, learn about A being used in the absence of an MX. That >> seems familiar now. Thanks for the tip. >> >>> You can use "reject_unlisted_recipient" early in your >>> smtpd_recipient_restrictions to dump connections to bad users early. A >>> later RBL check will only apply to valid recipients. >>> >>> Set smtpd_hard_error_limit to a low number, such as 2, to disconnect >>> clients after just a few errors. >>> >>> Set smtpd_error_sleep_time to 0 to get rid of bad clients without >>> delay. >> >> I'll give all that a try. Does this order seem alright? >> >> smtpd_recipient_restrictions = >> permit_mynetworks, >> reject_unlisted_recipient, >> reject_invalid_hostname, >> reject_non_fqdn_hostname, >> reject_non_fqdn_recipient, >> reject_non_fqdn_sender, >> reject_unauth_destination, >> reject_unknown_recipient_domain, >> reject_unauth_pipelining >> >>> I'll bet the postfix 2.7 "postscreen" feature will get rid of 1/2 or >>> more of the bots before they every talk to you. >>> >>> Postfix 2.7 allows you to specify 521 for the various *_reject_code >>> parameters to signal a disconnect. >> >> I've just been having a look at that. It does seem to be something >> very useful in this situation. But, maybe the bogus MX will solve my >> problems. >> >>> Increase the max number of smtpd listeners in master.cf to the highest >>> number your memory will allow. >> >> What's the best way of determining that? >> > > I have had success with lowering these 3 parameters as well, if even > temporarily during an attack. The values should be chosen based on > how many legitamite incoming connections you receive (so as not to > limit those). Also beware that in some cases rate limiting can cause > a buildup of incoming connection requests which could cause problems > with your tcp/ip stack, but generally these have worked for me. > > > > smtpd_client_connection_count_limit = 6 > smtpd_client_connection_rate_limit = 6 > smtpd_client_message_rate_limit = 6 > > > If you never want mail destined for the domain example.com, you can > use setup a rule to reject it. I would think this would be quite > fast. I would also use the bogus MX record to prevent as much traffic > as possible form hitting the server. > > smtpd_recipient_restrictions = > permit_mynetworks > check_recipient_access hash:/etc/postfix/smtpd_recipient_access > REST OF YOUR RESTRICTIONS > > > In the file smtpd_recipient_access > example.com REJECT "NO THANK YOU, WE ARE NOT EXCEPTING MAIL" > > > Here's a simple script to build the hash file from smtpd_recipient_access > #! /bin/bash > > /usr/sbin/postmap hash:/etc/postfix/smtpd_sender_access > /bin/chgrp postfix smtpd_sender_access* > /bin/chmod g=r,o-rwx smtpd_sender_access* > > > Nataraj > > > > You won't really need the check_recipient_access if example.com is not configured as a local domain. Nataraj
From: LuKreme on 26 May 2010 18:27
On 26-May-2010, at 14:12, brian wrote: > > I'll give all that a try. Does this order seem alright? No, not really. > smtpd_recipient_restrictions = > permit_mynetworks, > reject_unlisted_recipient, > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_non_fqdn_recipient, > reject_non_fqdn_sender, > reject_unauth_destination, > reject_unknown_recipient_domain, > reject_unauth_pipelining smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_invalid_hostname, permit_mynetworks, [ rest of restrictions ] reject_rbl_client zen.spamhaus.org permit Even if someone is in your network, there is no reason to allow unknown sender domains, invalid hostnames and (usually) non-fqdn, though in some circumstances these two rules might not be desired. -- Well I've seen the Heart of Darkness/Read the writing on the wall/an the voice out in the desert/Was the voice out in the hall |