Почему ufw регистрирует сообщения «BLOCK» относительно порта, для которого ufw настроен на «РАЗРЕШИТЬ» соединения?
Вот пример сообщения журнала:
May 25 10:36:07 myserver kernel: [7057243.392334] [UFW BLOCK] IN=eth0 OUT= MAC=00:02:55:67:82:eb:00:06:b1:3a:ef:62:08:00 SRC=69.197.128.26 DST=192.168.100.101 LEN=44 TOS=0x00 PREC=0x00 TTL=32 ID=0 PROTO=TCP SPT=48788 DPT=80 WINDOW=972 RES=0x00 RST URGP=0
Насколько я понимаю, DPT означает «порт назначения», но, поскольку я настроил ufw на , разрешить входящие соединения через порт 80, я озадачен тем, почему я вижу такое сообщение журнала - сообщение журнала, которое, кажется, указывает, что ufw заблокировал попытку подключения к этому порту.
Ниже приведены соответствующие строки из ufw status:
To Action From -- ------ ---- 80/tcp ALLOW Anywhere 80/tcp ALLOW Anywhere (v6)
Я уже видел это как в Ubuntu 11.10, так и сейчас (после обновления той же машины) в Ubuntu 12.04.
3 ответа
Мне тоже интересно об этом, поскольку я получаю похожие записи в журналах даже с серверов Googlebot.
В этой теме , похоже, говорится, что беспокоиться не о чем, но мне кажется очень странным, чтобы они регистрировались как BLOCK в UFW.
Поток, на который ссылается Caffeine Coma , указывает, что это связано с низкоуровневыми техническими средствами при закрытии сетевых подключений TCP ... Непонятные и тонкие различия между способами обработки подключений в операционных системах (Windows, Mac, Linux) завершение, по-видимому, приводит к некоторой безобидной путанице между сервером и клиентом, и это как-то приводит к описанным выше сообщениям журнала.
Я не совсем понимаю технические детали и то, почему это может привести к сообщениям журнала «BLOCK» в UFW, но я приму это, поскольку это единственный ответ, который я нашел, который имеет какой-то смысл, и я ' я не видел никаких других признаков того, что что-то не так на моем сервере - только эти безобидные (хотя и раздражающие) сообщения журнала UFW.
См. упомянутую ветку форума для более технического объяснения.
Я могу объяснить это немного подробно, не вдаваясь в технические аспекты.
Я просто использую сравнение.
Просто представьте, как два человека разговаривают друг с другом, и давайте предположим, что они ведут бизнес друг с другом и, кроме того, они соглашаются вести свой бизнес определенным образом.
Каждый раз, когда у них есть транзакция, это делается одинаково.
-
Встречайте и приветствуйте - они соглашаются, что сделка будет успешной, только если они сидят в одной комнате и пожимают друг другу руки в начале. Это обязательный шаг.
-
Прослушивание и повторная отправка. Они соглашаются с тем, что транзакция успешна, только если все данные, необходимые для этой транзакции, понятны, и если одна сторона не получает правильного ответа, они повторно оценивают статус и " Поговорите «об определенных аспектах этой транзакции, пока обе стороны не будут удовлетворены результатом и согласны с тем, что транзакция в порядке.
Это включает в себя
- а) Подтверждение в виде рукопожатия в начале каждой встречи и б) Окончательное подтверждение в конце с обеих сторон. Кроме того, продавец должен оставаться в комнате в течение определенного времени, пока он не будет уверен, что покупатель оставил насыщенным.
TCP-соединения работают аналогичным образом. Что-то не так, тогда брандмауэр говорит вам об этом.
Может быть фальшивый покупатель, который просто говорит привет, а затем снова уходит (зонд) Может быть реальным покупателем, который уже не так уверен в середине вещей и покидает комнату (пользователь) Может быть проблема со связью (маршрутизация, сеть и т. д.)
HTH, s1mmel