Parar o postfix de devorar recursos durante ataques de dicionário de spam?

Question

Quando um spammer usa sua botnet de milhares de PCs zumbis para spam em endereços aleatórios inexistentes @ example.com, a uma taxa muito alta de velocidade, o postfix esgota os limites de recursos do nosso provedor VPS tentando lidar com isso. Especificamente, ele esgota o número de soquetes não-TCP, que é limitado a 900 pelo VPS. Estou executando o postfix 2.3.3-2.1.el5_2 no CentOS 5 em um VPS do Virtuozzo linux.

/var/log/maillog says:
Feb 23 06:26:22 postfix/smtpd[3938]: warning: connect #1 to subsystem private/proxymap: Cannot allocate memory
Feb 23 06:26:22 postfix/smtpd[3936]: fatal: socket: Cannot allocate memory
Feb 23 06:26:48 postfix/qmgr[17702]: fatal: socket: Cannot allocate memory

O firewall seria um pouco difícil por causa dos milhares de IPs envolvidos no ataque do dicionário.

O provedor de VPS sugeriu ajustar os seguintes parâmetros, mas não sugeriu o que defini-los:

max_idle = 100s (default)
max_use = 100 (default)

Eu encontrei outra pessoa com o mesmo problema com os ataques de dicionário de postfix e spammer:

link

Ele mudou:

default_process_limit from 100 (default) to 10

... que resolveu o problema, mas introduziu uma penalidade de desempenho.

Não sei ao certo qual parâmetro deve ser ajustado com segurança aqui, mesmo depois de skimming postfix.org/TUNING%5FREADME.html Qualquer especialista em postfix pode ajudar?

    

Answer 1

Infelizmente, como o Postfix segue o modelo orientado pelo processo, o alto uso de memória sob carga é um dos seus efeitos colaterais. Você poderia tentar isso

De /etc/postfix/master.cf

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       5       smtpd

Na coluna maxproc , você pode substituir o - por um número menor para limitar o número de processos simultâneos de smtpd , isso deve fornecer um pouco da quantidade de mensagens recebidas.

Outra alternativa seria ver fail2ban , que pode ser configurado para analisar /var/log/maillog e aumentar blocos iptables para endereços que enviam uma grande quantidade de e-mails não entregues.

    

Answer 2

Você pode querer considerar adicionar algo semelhante a:

smtpd_recipient_restrictions =
        permit_auth_destination,
        permit_mynetworks,
        reject_unauth_destination,
        reject_unlisted_recipient

... para o seu arquivo main.cf , que deve fazer o postfix despejar algumas das conexões assim que descobrir que não há um usuário para entregar. A mágica está em reject_unlisted_recipient , que causará rejeições para usuários que não são válidos no seu sistema quando usado com local_recipient_maps . Ao fazer isso, ele deve reduzir a pressão reduzindo a quantidade de processamento em andamento, pois cada conexão descartada libera recursos preciosos para lidar com a próxima conexão. Sim, o remetente de spam poderá determinar quais endereços são inválidos, mas é melhor que o remetente de mensagens desperdice seu tempo enviando (e sendo rejeitado, desperdiçando sua largura de banda) do que o seu (evitando o ataque).