Запис Rsyslogd про атаку, створену невідомим додатком

У мене для запуску тестується сервер, який останнім часом вловив дивні записи журналу в / 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

Це результат того, що хтось запустив сканування Nmap на ваш сервер - Nmap знаходить відкритий порт TCP, а потім надсилає різні пакети, намагаючись виявити, чи активний якийсь із ряду загальних типів послуг (HTTP, RTSP, SIP, ...). на тому порту.

(Я щойно спробував запустити Zenmap 7.40 проти серверного додатка, який я розробляю, і записав цю саме послідовність рядків).

Я виявив, що пояснення такої поведінки знаходиться в конфігурації rsyslog. За замовчуванням rsyslog приймає вхід UDP з порту 514 та реєструє всі вхідні пакети до повідомлень, syslog та usr.log. Це відбувається тому, що rsyslog налаштований таким чином, щоб діяти як служба віддаленого ведення журналу за замовчуванням. Це можна відключити, коментуючи

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

в /etc/rsyslog.conf

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

У будь-якому випадку, вони в основному намагаються зв’язатися з вашим веб-сервером, на якому ви не запущені, отже, повідомлення записуються в / var / log замість того /var/log/apache2чи іншого подібного. Це здається трохи дивним , що хтось - то повинен покласти стільки зусиль в спробі зламати веб - сервер , який не слухає, будь ласка , переконайтеся , що ви НЕ маєте запущеного веб - сервера, переглянувши висновок

 ss -lntp

для прослуховування серверів у стандартних (80,443) або нестандартних портах.

Решта журналів стають цікавішими, оскільки вони записують спроби зв’язатися з АТС через Ваш веб-сервер, АТС, який, згідно з вашим ОП, ви не працюєте. І все ж протокол (SIP), адреса <sip:nm@nm>та протокол опису сеансу ( Accept: application/sdp) все говорять про це.

Ще раз ви впевнені, що не працюєте з АТС ? Схоже, хтось посадив його на вашу машину. Знову ж таки, якщо ви вважаєте, що ваша машина не була порушена, команда

ss -lnup

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

Але , якщо ваша машина була порушена, вищезгадане може дуже добре повідомити про нічого підозрілого, в той час як дійсно багато незаконного відбувається. Ви можете спробувати зменшити свої страхи (обґрунтовано, на жаль), завантаживши та запустивши chkrootkitта rkhunter. Ви також можете прочитати тут (вибачення за посилання на мою власну відповідь, я знаю, що це не приємно, але це рятує мене від певної роботи). І перш за все, слід запитати себе: чи я відключив вхід пароля на ssh і замість цього ввів криптографічні ключі? Якщо відповідь на це питання - Ні , то шанси на те, що ваша машина порушена. Потім слід перевстановити з нуля та дотримуватися інструкцій, що були вище, щоб вимкнути вхід із паролем на sshкористь використання публічних / приватних ключів, які надзвичайно безпечніші.