Анализируем логи named'a
1. О чем говорит "WWW.N3T.COM.BR." в unmatched-логах named'a .
К категории "unmatched" Named относит запросы, которые он не может отнести ни к одной из известных категорий
(BIND 9 Administrator Reference Manual, chapter 6 "BIND 9 Configuration Reference"):
" Messages that named was unable to determine the class of or for which there was no matching view.
A one line summary is also logged to the client category.
This category is best sent to a file or stderr, by default it is sent to the null channel. "
Для того, чтобы задействовать эту категорию, нужно определить соответствующий канал в logging statement, например, так:
logging {
channel my_default_info {
file "/var/log/named_info.log" versions 10;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
channel my_debug {
file "/var/log/named_sec.log" versions 10;
//severity debug 1;
severity dynamic;
print-category yes;
print-severity yes;
print-time yes;
};
channel my_xfer {
file "/var/log/named_xf.log" versions 10;
severity debug 10;
print-category yes;
print-severity yes;
print-time yes;
};
channel my_unmatch {
file "/var/log/named_un.log" versions 10;
severity debug 10;
print-category yes;
print-severity yes;
print-time yes;
};
category default { my_default_info; };
category security { my_debug; };
category xfer-in { my_xfer; };
category xfer-out { my_xfer; };
category unmatched { my_unmatch; };
category lame-servers { null; };
};
Иногда среди unmatched-запросов встречаются запросы вида:
Nov 28 13:29:51.117 unmatched: debug 1: client 1.2.3.4#137: no matching view in class
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14
;; flags: rd ; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;WWW.N3T.COM.BR. CLASS256 RESERVED0
Поиск в интернете по ключевой фразе "WWW.N3T.COM.BR" дает информацию о вирус-черве Opaserv :
"... Вирус-червь со встроенной троянской программой типа "бекдор". Распространяется по локальным и глобальным сетям используя протокол NETBIOS, предоставляемый MS Windows.
Является приложением Windows (PE EXE-файл), имеет размер около 28K...
...Несколько версий червя были обнаружены в "диком виде" в конце сентября 2002, а в начале октября 2002 червь вызвал "эпидемию" по всему миру...
... При подборе паролей червь использует брешь в защите Win9x: см. http://www.nsfocus.com/english/homepage/sa_05.htm
Реализация проверки пароля NETBIOS в Win9x такова, что проверяется число символов,
присланное "клиентом". То есть, если "клиент" устанавливает длину пароля в 1 символ и
посылает пакет с паролем (в Plaintext-формате) на сервер, то сервер будет проверять только
первый байт пароля и, если он совпадет, аутентификация будет считаться успешной. Таким
образом, атакующей системе достаточно перебрать варианты одно-символьного пароля
Заплатка для данной бреши в системе безопасности доступна по адресу:
http://www.microsoft.com/technet/security/bulletin/MS00-072.asp ..."
Возвращаемся к подозрительной записи в unmatched-логе. Ip-адрес, указанный в этом запросе, принадежит вашей локальной сети, которой разрешено присылать запросы вашему bind-серверу ( вы же используете опцию "allow-recursion { mynet; }", не так ли ?)
Итак, эта запись означает, что компьютер в вашей сети заражен "Opaserv".
Ну и напоследок, маленький скрипт, который известит в установленное (man cron) время о подозрительных запросах bind'у из локальной сети:
#!/bin/bash
Предварительно нужно созать пустой файл named_un.cmp в директории /var/log/compar
qr=`egrep -c "quota reached" /chroot/var/log/named_info.log`
[ "$qr" != 0 ] && mail -sNamed_quota_reached! root
egrep "WWW.N3T.COM.BR." /chroot/var/log/named_un.log > /dev/null
[ "$?" != 0 ] && exit
egrep "WWW.N3T.COM.BR." -B4 /chroot/var/log/named_un.log > /chroot/var/log/named_un.tmp
diif=""
[ -s /cob/var/log/named_un.tmp ] && [ -s /var/log/compar/named_un.cmp ] && \
diif=`diff /chroot/var/log/named_un.tmp /var/log/compar/named_un.cmp`
[ "$diif" != "" ] && mail -sOPAserv_sign root < /chroot/var/log/named_un.tmp && \
mv -v /chroot/var/log/named_un.tmp /var/log/compar/named_un.cmp >> /var/log/tmprmv
[ "$diif" = "" ] && rm -v /chroot/var/log/named_un.tmp >> /var/log/tmprmv
2. О чем может говорить "no more recursive clients: quota reached " в логах named'a .
Однажды мой named-лог за день раздулся до 45MB за счет сообщений вида:
warning: client 1.2.3.4#1031: no more recursive clients: quota reached
Адрес 1.2.3.4 принадлежал днс-серверу нашей подсети, на которой админ той подсети установил Microsoft DNS,
и кроме того он forward-ил днс-запросы на мой сервер.
Почти сразу после этого случая на Bugtraq'e прошли сообщения с аналогичным содержанием, из которых стало приблизительно ясно, что
причиной многочисленных рекурсивных запросов мог являться продукт 3DNS компании F5 (аппаратная система балансировки веб-серверов):
Mike Lyman :
"... My guess is a newly installed 3DNS load balancer from F5. Back at
Microsoft we used to get lots of reports of this. So much so that we
contemplated many a late night mission into the data centers with wire
cutters :-) (As the former abuse microsoft com, I got quite a few of
the reports peronsally.)
3DNS is fairly intrusive in its default configuration and uses DNS like
traffic to try to determine which data center you are logically closest
to and route you there. It also periodically retests even if no client
in your network is currently connecting to the systems using 3DNS. Sets
off lots of IDS and firewall alarms. It can be configured so that it
does not set of so many alarms."
Нужно отметить, что значение по умолчаниюдля recursive-clients - 1000:
(BIND 9 Administrator Reference Manual, chapter 6 "BIND 9 Configuration Reference"):
recursive-clients
The maximum number of simultaneous recursive lookups the server will perform on behalf of clients. The default is 1000. Because each recursing client uses a fair bit of memory, on the order of 20 kilobytes, the value of the recursive-clients option may have to be decreased on hosts with limited memory.
А определяется это значение в секции options.
В моем случае увеличивать это значение не было смысла, достаточно было убрать forward на мой сервер с МS DNS.
Ну а первые две строчки приведенного выше скрипта теперь должны извещать меня о подобных ситуациях.
3. Если в /var/log/messages или в выделенном вами файле для сообщений named появляются сообщения вида: errno2result.c:109: unexpected error:
19-Dec-2005 03:33:29.304 general: error: errno2result.c:109: unexpected error:
19-Dec-2005 03:33:29.304 general: error: unable to convert errno to isc_result: 14: Bad address
19-Dec-2005 03:33:29.304 client: error: UDP client handler shutting down due to fatal receive error: unexpected error
Причина в ошибке ядер версии 2.6.14.
Исправлено в ядре 2.6.14.2. Но так как после этого были обнаружены другие баги, рекомендуется установить последнюю версию ядра.
У меня эта ошибка возникла при переходе на версию 2.6.14.1.
Ссылки по теме:
[1]
[2]
[3]
[4]