Rsyslogd Запись в журнале об атаке, созданной неизвестным приложением

Question

У меня есть сервер, работающий в целях тестирования, который в последнее время обнаружил некоторые странные записи в журналах /var /log /syslog, /var/log/user.log и /var /log /messages. auth.log не показывает ничего подозрительного. Ни один пользователь не должен был войти в систему в течение этого времени.

На сервере практически нет программного обеспечения, только демон sshd.

Записи в журнале не показывают, какая программа их создала, они, кажется, происходят из-за некоторых действий по сканированию портов и проверке.

У кого-нибудь есть идея, откуда могут прийти эти сообщения? (SOMEDATETIME - время записи в журнале, а SOMEIP - неизвестный IP-адрес).

SOMEDATETIME GET / HTTP/1.0#015
SOMEDATETIME SOMEIP #015 
SOMEDATETIME SOMEIP #015 
SOMEDATETIME SOMEIP #015 
SOMEDATETIME OPTIONS / HTTP/1.0#015
SOMEDATETIME SOMEIP #015 
SOMEDATETIME OPTIONS / RTSP/1.0#015
SOMEDATETIME SOMEIP #015 
SOMEDATETIME SOMEIP HELP#015 
SOMEDATETIME SOMEIP #026#003#000#000S#001#000#000O#003#000?G���,���`~�#000��{�Ֆ�w����<=�o�#020n#000#000(#000#026#000#023 
SOMEDATETIME SOMEIP #026#003#000#000i#001#000#000e#003#003U#034��random1random2random3random4#000#000#014#000/ 
SOMEDATETIME SOMEIP #000#000#000qj�n0�k�#003#002#001#005�#003#002#001 
SOMEDATETIME GET /nice%20ports%2C/Tri%6Eity.txt%2ebak HTTP/1.0#015
SOMEDATETIME SOMEIP #015 
SOMEDATETIME SOMEIP #001default 
SOMEDATETIME SOMEIP #002 
SOMEDATETIME OPTIONS sip: nm SIP/2.0#015
SOMEDATETIME SOMEIP Via: SIP/2.0/TCP nm;branch=foo#015
SOMEDATETIME SOMEIP From: <sip:nm@nm>;tag=root#015
SOMEDATETIME SOMEIP To: <sip:nm2@nm2>#015
SOMEDATETIME SOMEIP Call-ID: 50000#015
SOMEDATETIME SOMEIP CSeq: 42 OPTIONS#015
SOMEDATETIME SOMEIP Max-Forwards: 70#015
SOMEDATETIME SOMEIP Content-Length: 0#015
SOMEDATETIME SOMEIP Contact: <sip:nm@nm>#015
SOMEDATETIME SOMEIP Accept: application/sdp#015
SOMEDATETIME SOMEIP #015

Answer 1

Это результат того, что кто-то запускает сканирование Nmap на вашем сервере - Nmap находит открытый порт TCP, а затем отправляет различные пакеты, пытаясь обнаружить, активен ли какой-либо из нескольких общих типов служб (HTTP, RTSP, SIP, ...) в этом порту.

(Я только что попытался запустить Zenmap 7.40 для разрабатываемого серверного приложения и записал ту же последовательность строк).

Answer 2

Я обнаружил, что объяснение этого поведения находится в конфигурации rsyslog. По умолчанию rsyslog принимает UDP-вход от порта 514 и регистрирует все входящие пакеты в сообщениях, файлах журнала syslog и usr.log. Это связано с тем, что rsyslog по умолчанию также настроен для работы в качестве удаленной службы ведения журнала. Это можно отключить, комментируя

#$ModLoad imudp
#$UDPServerRun 514
#$ModLoad imtcp
#$InputTCPServerRun 514

в /etc/rsyslog.conf

Answer 3

Отображаемый вами журнал не очень полезен: неясно, всегда ли SOMEIP одинаков или нет, или SOMEDATETIME сильно отличаются, или все они происходят в одном пакете, или они сгруппированы вокруг небольшого количества временных интервалов.

В любом случае, это в основном попытки связаться с вашим веб-сервером, который вы не используете, поэтому сообщения записываются в /var /log вместо /var/log/apache2 или чего-то подобного. Кажется немного странным, что кто-то должен приложить столько усилий, чтобы попытаться открыть веб-сервер, который не прослушивает, пожалуйста, убедитесь, что у вас нет запущенного веб-сервера, проверив вывод

 ss -lntp

для серверов, прослушивающих стандартные (80 443) или нестандартные порты.

Остальные журналы становятся более интересными, потому что они регистрируют попытки связаться с УАТС через ваш веб-сервер, который, согласно вашему OP, не запущен. Тем не менее, протокол (SIP), адрес <sip:nm@nm> и протокол описания сеанса (Accept: application/sdp) - все это говорит о многом.

Еще раз, вы уверены, что не используете УАТС? Похоже, кто-то посадил один на вашу машину. Опять же, если вы считаете, что ваша машина не была нарушена, команда

ss -lnup

(для протокола UDP вместо протокола TCP) скажет вам, какой процесс прослушивает какой порт.

Но, если ваша машина была нарушена, вышеприведенное может очень хорошо сообщить ничего подозрительного, в то время как на самом деле происходит много незаконных действий. Вы можете попытаться успокоить свои страхи (обоснованно, увы), загрузив и запустив chkrootkit и rkhunter . Вы также можете прочитать здесь (извинения за ссылку на мой собственный ответ, я знаю, что это не очень хорошо, но это спасает меня от работы). И, прежде всего, вы должны спросить себя: отключил ли я пароль входа в систему по SSH и вместо этого ввел криптографические ключи? Если ответ на этот вопрос - « Нет», скорее всего, ваша машина была нарушена. Затем вы должны переустановить его с нуля и следуйте приведенным выше инструкциям, чтобы отключить вход с паролем в ssh в пользу использования открытых / закрытых ключей, которые намного более безопасны.