1

I have a server running for testing purposes which lately caught some strange log entries in /var/log/syslog, /var/log/user.log and /var/log/messages. auth.log does not show anything suspicious. No (human) user should have been logged in during this time.

The server runs almost no software, only sshd daemon.

The log entries do not reveal which program created them, they seem to originate from some port-scanning and probing activity.

Anyone has an idea where these messages can come from? (SOMEDATETIME is the time of the log entry and SOMEIP an unknown IP address)

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
0

3 Answers 3

2

It's the result of someone running an Nmap scan against your server - Nmap finds an open TCP port, and then sends various packets trying to discover if any of a number of common service types (HTTP, RTSP, SIP,...) is active on that port.

(I just tried running Zenmap 7.40 against a server application I'm developing, and logged that exact same sequence of strings).

1

I found that the explanation for this behaviour is in the rsyslog configuration. By default, rsyslog accepts UDP input from port 514 and loggs any incoming packages to messages, syslog and usr.log logfiles. This is because rsyslog is configured to act as a remote logging service by default as well. This can be disabled by commenting

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

in /etc/rsyslog.conf

0

The log you displayed is not extremely helpful: it is not clear whether SOMEIP is always the same or not, or whether SOMEDATETIMEs are different by much, or they all occur in one burst, or they are clustered around some small number of time intervals.

At any rate, they are basically attempts to contact your Web Server, which you are not running, hence the messages are logged to /var/log instead of /var/log/apache2 or some such thing. It seems a bit strange that someone should put so much effort into trying to pry open a Web server which is not listening, please make sure that you do not have a running Web server by checking the output of

 ss -lntp

for servers listening on standard (80,443) or non-standard ports.

The remaining logs become more interesting, because they record attempts to contact a PBX via your Web server, PBX which, according to your OP, you are not running. Yet the protocol (SIP), the address, <sip:nm@nm>, and the Session Description Protocol (Accept: application/sdp) all speak volumes to this.

Once again, are you sure you are not running a PBX? It looks like someone has planted one onto your machine. Again, if you think your machine has not been violated, the command

ss -lnup

(for the UDP protocol, instead of the TCP protocol) will tell you which process is listening on which port.

But, if your machine has been violated, the above may very well report nothing suspicious, while indeed much illegal is going on. You can try assuaging your fears (well-founded, alas) by downloading and running chkrootkit and rkhunter. You may also read here (apologies for referring to my own answer, I know it is not nice but it saves me some work). And above all, you should ask yourself: did I disable password login on ssh and introduce cryptographic keys instead? If the answer to this question is No, then chances are your machine has been violated. You should then re-install from scratch, and follow instructions above to disable password login on ssh in favor of the use of public/private keys, which are immensely more secure.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .