Rsyslogd Entrada de log sobre ataque criado por aplicativo desconhecido

Eu tenho um servidor em execução para fins de teste que ultimamente capturou algumas entradas de log estranhas em / var / log / syslog, /var/log/user.log e / var / log / messages. auth.log não mostra nada de suspeito. Nenhum usuário (humano) deveria estar conectado durante esse período.

O servidor executa quase nenhum software, apenas o daemon sshd.

As entradas de log não revelam qual programa as criou; elas parecem se originar de alguma atividade de varredura de portas e sondagem.

Alguém tem uma idéia de onde essas mensagens podem vir? (SOMEDATETIME é o horário da entrada do log e SOMEIP é um endereço IP desconhecido)

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

É o resultado de alguém executando uma verificação do Nmap no servidor - o Nmap encontra uma porta TCP aberta e envia vários pacotes tentando descobrir se algum dos vários tipos de serviço comuns (HTTP, RTSP, SIP, ...) está ativo nessa porta.

(Eu apenas tentei executar o Zenmap 7.40 em um aplicativo de servidor que estou desenvolvendo e registrei exatamente a mesma sequência de strings).

Eu descobri que a explicação para esse comportamento está na configuração do rsyslog. Por padrão, o rsyslog aceita entrada UDP da porta 514 e registra todos os pacotes recebidos em mensagens, syslog e arquivos de log usr.log. Isso ocorre porque o rsyslog está configurado para atuar como um serviço de log remoto por padrão também. Isso pode ser desativado comentando

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

em /etc/rsyslog.conf

O log que você exibiu não é extremamente útil: não está claro se SOMEIP é sempre o mesmo ou não, ou se SOMEDATETIMEs são diferentes por muito, ou todos ocorrem em uma explosão ou estão agrupados em torno de um pequeno número de intervalos de tempo.

De qualquer forma, são basicamente tentativas de entrar em contato com o servidor Web, que você não está executando, portanto as mensagens são registradas em / var / log em vez de /var/log/apache2ou em algo semelhante. Parece um pouco estranho que alguém se esforce ao tentar abrir um servidor Web que não esteja escutando. Verifique se você não possui um servidor Web em execução, verificando a saída de

 ss -lntp

para servidores ouvindo em portas padrão (80.443) ou fora do padrão.

Os logs restantes se tornam mais interessantes, porque registram tentativas de contato com um PBX por meio do servidor da Web, PBX que, de acordo com o seu OP, você não está executando. No entanto, o protocolo (SIP), o endereço <sip:nm@nm>e o Protocolo de descrição de sessão ( Accept: application/sdp) falam muito sobre isso.

Mais uma vez, você tem certeza de que não está executando um PBX ? Parece que alguém plantou um em sua máquina. Novamente, se você acha que sua máquina não foi violada, o comando

ss -lnup

(para o protocolo UDP, em vez do protocolo TCP) informará qual processo está escutando em qual porta.

Porém , se sua máquina foi violada, as informações acima podem muito bem relatar nada de suspeito, enquanto, de fato, muita coisa ilegal está acontecendo. Você pode tentar acalmar seus medos (bem fundamentado, infelizmente) baixando e executando chkrootkite rkhunter. Você também pode ler aqui (desculpas por me referir à minha própria resposta, eu sei que não é legal, mas me poupa algum trabalho). E, acima de tudo, você deve se perguntar: desabilitei o login com senha no ssh e introduzi chaves criptográficas? Se a resposta a esta pergunta for Não , é provável que a sua máquina tenha sido violada. Você deve reinstalar a partir do zero e siga as instruções acima para desativar o login com senha sshem favor do uso de chaves públicas / privadas, que são imensamente mais seguras.