После DoS postfix-атаки у нас есть очереди входящих и активных писем:
drwx------. 2 postfix root 1007616 nov 5 17:01 active
drwx------. 2 postfix root 4096 nov 5 11:31 bounce
drwx------. 2 postfix root 4096 feb 20 2014 corrupt
drwx------. 18 postfix root 4096 jun 30 2014 defer
drwx------. 18 postfix root 4096 jun 30 2014 deferred
drwx------. 2 postfix root 4096 sep 8 10:41 flush
drwx------. 2 postfix root 4096 feb 20 2014 hold
drwx------. 2 postfix root 1093632 nov 5 17:01 incoming
drwx-wx---. 2 postfix postdrop 4096 nov 5 17:01 maildrop
drwxr-xr-x. 2 root root 4096 nov 5 16:49 pid
drwx------. 2 postfix root 4096 nov 5 16:49 private
drwx--x---. 2 postfix postdrop 4096 nov 5 16:49 public
drwx------. 2 postfix root 4096 feb 20 2014 saved
drwx------. 2 postfix root 4096 feb 20 2014 trace
Активная очередь:
[root@revres]# ls -la /var/spool/postfix/active/
total 992
drwx------. 2 postfix root 1007616 nov 5 17:01 .
drwxr-xr-x. 16 root root 4096 nov 5 09:06 ..
Входящая очередь:
[root@revres]# ls -la /var/spool/postfix/incoming/
total 1076
drwx------. 2 postfix root 1093632 nov 5 17:01 .
drwxr-xr-x. 16 root root 4096 nov 5 09:06 ..
Запуск postsuper -d ALL
команда ничего не удаляет и не выводит.
Есть ли другой способ очистить эти коробки?
Я почти уверен, что после этой атаки ваш постфикс потерял целостность. Очереди на самом деле находятся в структурах данных в памяти, поэтому сообщения могут находиться на диске, но postfix может их не знать. Я бы порекомендовал вам остановить службу postfix, запустить postsuper -s
(который восстанавливает и проверяет структуру файлов) и запускает его снова.
Если ls -la
показывает только два "файла" .
и ..
Затем это является пусто.
Если вы затем скажете: «Почему .
такой большой, когда он пуст »? Тогда ответ: это обычно в файловых системах ext3 или ext4. Они резервируют место для inodes, присутствующих в каталоге. И даже когда все файлы удалены (inodes ушли), зарезервированное пространство для управления inodes все еще присутствует. Так что не о чем беспокоиться. (И даже если: это всего лишь один мегабайт «большой»)
Та же проблема.
судо ls -ln / var / spool / postfix / incoming показывает 1472 файла.
#sudo ls /var/spool/postfix/incoming/ -ln
total 1472
-rw------- 1 89 89 8192 Feb 14 15:38 0007B120A83
-rw------- 1 89 89 0 Feb 14 16:38 0030E120A9B
-rw------- 1 89 89 4096 Feb 14 18:04 04548120AE7
-rw------- 1 89 89 102400 Feb 14 16:34 069CA120A94
-rw------- 1 89 89 0 Feb 14 17:56 06E53120ADF
-rw------- 1 89 89 0 Feb 14 17:10 08ADF120AB6
-rw------- 1 89 89 0 Feb 14 18:36 09A56120B24
-rw------- 1 89 89 0 Feb 14 18:32 0B0D0120B11
-rw------- 1 89 89 36864 Feb 14 16:43 0BC4D120A9A
-rw------- 1 89 89 0 Feb 14 19:01 0C150120B3E
-rw------- 1 89 89 0 Feb 14 18:30 0CED5120B16
Перезапущены службы MailScanner и postfix. Также получал кучу ошибок от сервера Exchange 2010, для которого я фильтрую и действую как шлюз.
Out: 250 2.1.5 Ok
In: DATA
Out: 354 End data with <CR><LF>.<CR><LF>
Out: 451 4.3.0 Error: queue file write error
In: RSET
Out: 421 4.3.0 Mail system error
mailq или postqueue -p показывает пустую очередь ...
#mailq
Mail queue is empty
Вы можете видеть до минуты, когда он ударяется о стену. К сожалению, я запускаю Проект ОДВ на Centos 6.8, хотя:
#yum info postfix
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
* EFA: dl4.efa-project.org
* base: mirror.fusioncloud.co
* epel: archive.linux.duke.edu
* extras: mirrors.lga7.us.voxel.net
* updates: mirrors.evowise.com
Installed Packages
Name : postfix
Arch : x86_64
Epoch : 2
Version : 3.1.3
Release : 1.efa.el6
Size : 14 M
Repo : installed
From repo : EFA
Summary : Postfix Mail Transport Agent
URL : http://www.postfix.org
License : IBM
Description : Postfix is a Mail Transport Agent (MTA), supporting LDAP, SMTP AUTH (SASL),
: TLS built for Email Filter Appliance (EFA)
Я не могу найти сценарии postfix-perl, упакованные для этой ОС. Я пытался обмануть пакеты Fedora, но мой rpm-foo очень слабый.
... отредактировано ...
Вырвать идентификатор из имени файла и попытаться просмотреть его с помощью почтовая кошка урожайность.
#postcat -vq 0007B120A83
postcat: name_mask: ipv4
postcat: inet_addr_local: configured 2 IPv4 addresses
postcat: fatal: open queue file 0007B120A83: Permission denied
[ssmith@foster-spam ~]$ sudo postcat -vq 0007B120A83
postcat: name_mask: ipv4
postcat: inet_addr_local: configured 2 IPv4 addresses
*** ENVELOPE RECORDS incoming/0007B120A83 ***
message_size: 0 0 0 0 0 0
postcat: fatal: invalid size record: 0 0 0 0 0 0
Поиск в почтовом журнале:
#sudo grep -i '0007B120A83' /var/log/maillog
Feb 14 15:36:36 foster-spam postfix/smtpd[16368]: 0007B120A83: client=foster-mail.foster2007.local[10.0.2.28]:63650
Feb 14 15:36:36 foster-spam postfix/cleanup[16371]: 0007B120A83: hold: header Received: from mail.fosterfuels.com (foster-mail.foster2007.local [10.0.2.28])??(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))??(No client certificate requested)??by mx.fosterfuels.com from foster-mail.foster2007.local[10.0.2.28]:63650; from=<xxxxxxxxxxxxx@fosterfuels.com> to=<xxxxxxx@xxxxxx.com> proto=ESMTP helo=<mail.fosterfuels.com>
Feb 14 15:36:36 foster-spam postfix/cleanup[16371]: 0007B120A83: message-id=<6B24BD0263D83043837040657FCAC53414F05903@foster-mail.FOSTER2007.local>
Feb 14 19:41:51 foster-spam postfix/postsuper[20067]: queue: 0007B120A83
Feb 14 19:41:51 foster-spam postfix/postsuper[20067]: fatal: invalid directory name: 0007B120A83
Я думаю, что на этом этапе я мог бы предположить, что все эти файлы - просто мусор, и безумно надеяться, что во время DOS / вирусного потока, который начал это, не было съедено никакой почты ...
Проверьте / var / spool / postfix / defer и deferred - убедитесь, что они пустые перед (повторным) запуском постфикса.
Файл каталога - это специальный файл, который ТОЛЬКО расширяется и никогда не сжимается, поскольку они заполняются все большим количеством файлов и каталогов под ним. Я столкнулся с этой проблемой, особенно с файлами в /tmp
с процессами, имеющими запускаемые сценарии, которые создали тысячи промежуточных файлов.
Если вы хотите уменьшить размер файла каталога, выполните следующие основные шаги:
Завершите любые процессы, используя bigdir
mv bigdir bigdir.x
mkdir bigdir
mv bigdir.x/* bigdir
;; переместить существующие файлы в новый меньший каталог
mv bigdir.x/.[a-zA-Z0-9]* bigdir
;; копировать скрытые файлы, но не. и .
Измените разрешения, ACL, маркировку SEL, чтобы они соответствовали biddir.x
rmdir bigdir.x
;; bigdir.x должен быть пустым
Вы можете (повторно) запускать любые процессы, используя bigdir
Результирующий каталог будет намного меньше оригинального.