LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 06-15-2004, 09:44 AM   #1
sbogus
Member
 
Registered: May 2004
Location: Germany, Munich
Distribution: SuSE Pro Releases 7.3, 9.0, CentOS 4.0, Kubuntu 6.0x
Posts: 103

Rep: Reputation: 15
Question Strange port scan results


Hi ya,

I'd like to apologize for asking such very discussed matter, but searching the forum for my question gave me not enough information.

Okay, here we go:

I recently ran a port scanner from my offise machine (W2k) to scan my home machine (SuSE 9.0) in order to check if there're security holes after the activating the firewall on the SuSE box.

What I got after the scan on ports 1 thru 65535 looks like this


Ping .... Ok, Time : 93
Port 22 (ssh) ... Ok ! (port 22 - SSH Remote Login Protocol)
Port 389 (ldap) ... Ok ! (port 389 - Lightweight Directory Access Protocol)
Port 1002 () ... Ok ! (port 1002 - )
Port 1720 (h323hostcall) ... Ok ! (port 1720 - h323hostcall)


First part of the question does SSHD need ldap in order to function properly? Represents this port some vulnerability on my machine and should I close it?

The second part of the question is:
What the heck are these ports for? 1002, 1720

Third part of the question:
I seems do not run anything that might use these ports (at least i do not find any information through netstat), but they still open! Should I consider a security compromise in my SuSE box? I'd hate to reinstall all the stuff there, since I'm diggin' and shufflin' with this over a month and now the box seems to be configured prety well.

Some background information about my connection to INet.
I use dialin for an ADSL ISP and use flatrate 1MBit/s download and 384KBit/s upload streams.
The dynamic IP of the connection changes every time i go into the network, so is there any chance that these ports belong to one of the servers on the way to my machine?

Many thanks in advance for the help!
Kind regards,
sbogus
 
Old 06-15-2004, 10:17 AM   #2
Crunch
Member
 
Registered: Feb 2003
Location: York, PA
Distribution: Slackware, FreeBSD, OpenBSD
Posts: 162

Rep: Reputation: 30
From what I've seen; h323hostcall is used for video conferencing. It has to do with Windows Netmeeting, I think. I could be wrong. The other port that's open(Port 1002)... not sure.
 
Old 06-15-2004, 10:54 AM   #3
sbogus
Member
 
Registered: May 2004
Location: Germany, Munich
Distribution: SuSE Pro Releases 7.3, 9.0, CentOS 4.0, Kubuntu 6.0x
Posts: 103

Original Poster
Rep: Reputation: 15
Quote:
Originally posted by Crunch
From what I've seen; h323hostcall is used for video conferencing. It has to do with Windows Netmeeting, I think. I could be wrong. The other port that's open(Port 1002)... not sure.
Thanks for the reply, could it be (the port 1720) from the XawTv application, because I tried recently to activate my WebCam and have installed and activated all Video4Linux components needed by XawTv in order to get the WebCam working... For no avail though - the cam still not work.

I've googled for the other opened port (1002), but nothing found, unfortunately...
I'm still confused with that one and with the ldap port (389), anyone to give me suggestions of how I should proceed?

Many thanks in advance.

Kind regards,
sbogus
 
Old 06-15-2004, 11:32 AM   #4
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 57
Try using:
netstat -pantu
which will give you the name or PID of the application using that port or if you system supports it,
lsof -i
 
Old 06-18-2004, 10:17 AM   #5
sbogus
Member
 
Registered: May 2004
Location: Germany, Munich
Distribution: SuSE Pro Releases 7.3, 9.0, CentOS 4.0, Kubuntu 6.0x
Posts: 103

Original Poster
Rep: Reputation: 15
Hi ya,

here's some update of what I've done in regard of the "problem" with the opened ports 389, 1002 and 1720.

Thanks to Capt_Caveman for his help with the commands

Here's the output of the command netstat -pantu

Code:
home:~ # netstat -pantu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:1024            0.0.0.0:*               LISTEN      3063/kdm
tcp        0      0 0.0.0.0:1030            0.0.0.0:*               LISTEN      3280/licq
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1850/portmap
tcp        0      0 0.0.0.0:6000            0.0.0.0:*               LISTEN      3113/X
tcp        0      0 0.0.0.0:5810            0.0.0.0:*               LISTEN      2942/xinetd
tcp        0      0 0.0.0.0:5910            0.0.0.0:*               LISTEN      2942/xinetd
tcp        0      0 0.0.0.0:631             0.0.0.0:*               LISTEN      2681/cupsd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      2741/master
tcp        0      0 :::22                   :::*                    LISTEN      2579/sshd
tcp        0     48 217.89.9.220:22         212.94.248.3:2314       ESTABLISHED 4697/4
udp        0      0 0.0.0.0:177             0.0.0.0:*                           3063/kdm
udp        0      0 0.0.0.0:68              0.0.0.0:*                           969/dhcpcd
udp        0      0 0.0.0.0:111             0.0.0.0:*                           1850/portmap
udp        0      0 0.0.0.0:631             0.0.0.0:*                           2681/cupsd
The only real port I see here used is the SSHD's one - port 22. Okay, that's correct because I'm connected remote from my office machine to my home machine.

But I do not see the other three ports in that report. I do not see them in the report of the command lsof -i too.
Here's the output:

Code:
home:~ # lsof -i
COMMAND  PID    USER   FD   TYPE DEVICE SIZE NODE NAME
dhcpcd   969    root    4u  IPv4   1264       UDP *:bootpc
portmap 1850     bin    5u  IPv4   2637       UDP *:sunrpc
portmap 1850     bin    6u  IPv4   2749       TCP *:sunrpc (LISTEN)
sshd    2579    root    5u  IPv6   3735       TCP *:ssh (LISTEN)
cupsd   2681      lp    0u  IPv4   6306       TCP *:ipp (LISTEN)
cupsd   2681      lp    2u  IPv4   6307       UDP *:ipp
master  2741    root   11u  IPv4   4262       TCP localhost:smtp (LISTEN)
xinetd  2942    root    5u  IPv4   6301       TCP *:5910 (LISTEN)
xinetd  2942    root    8u  IPv4   6302       TCP *:5810 (LISTEN)
kdm     3063    root    8u  IPv4   6595       UDP *:xdmcp
kdm     3063    root    9u  IPv4   6596       TCP *:1024 (LISTEN)
X       3113    root    1u  IPv4   6832       TCP *:x11 (LISTEN)
kdm     3114    root    9u  IPv4   6596       TCP *:1024 (LISTEN)
licq    3280 <localuser>   10u  IPv4  13464       TCP *:iad1 (LISTEN)
licq    3324 <localuser>   10u  IPv4  13464       TCP *:iad1 (LISTEN)
licq    3325 <localuser>   10u  IPv4  13464       TCP *:iad1 (LISTEN)
licq    3326 <localuser>   10u  IPv4  13464       TCP *:iad1 (LISTEN)
licq    3327 <localuser>   10u  IPv4  13464       TCP *:iad1 (LISTEN)
sshd    4697    root    6u  IPv6  24372       TCP pD95909DC.dip.t-dialin.net:ssh->212.94.248.3:cr-websystems (ESTABLISHED)
sshd    4700    root    6u  IPv6  24372       TCP pD95909DC.dip.t-dialin.net:ssh->212.94.248.3:cr-websystems (ESTABLISHED)
But the portscan application I use (IP-Tools for Windows) still say I've ports 389, 1002 and 1720 open. One thing I can imagine is that LIcq uses either port 1002 or 1720 for it's communication (currently, when the above commands ran, the Q was disconnected), but it should use only one port, not 2 or 3!

Anybody have a clue what's going wrong? I'm almost convinced tonight to close all these opened ports and to leave the port 22 only, but stll not sure if this will not dump something from vital importance for my system.

Any help is greatly apreciated.

Kind regards,
sbogus
 
Old 06-18-2004, 07:57 PM   #6
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 57
You have some really abnormal stuff listening for incoming connections, including an icq and remote X listener that I'd really be concerned about. If you've installed software like that which sounds familiar then maybe you have less to worry about. Also, the fact that the nmap scan doesn't agree with the netstat and lsof output is troublesome as well.

If you have no clue what that stuff is, then at the very least run some kind of rootkit detection software like chkrootkit or rootkit hunter. Though, I'd advise pulling the plug on the system and rebooting it with a cdrom-based distro like Knoppix or FIRE and mounting the old system readonly, then run chkrootkit and look around for suspicious files on the system, abnormal users, or strange log messages. The logic being that having trojaned binaries or the installation of a rootkit will often manipulate that output of netstat and/or lsof in order to hide the presence of remote backdoors. Clearly there are a number of abnormal daemons running which would suggest multiple compromises or sloppy work by a cracker. Either way you need to determine what is really listening on the system and why. If it's just a case of you monkeying around and testing things out, then that's one thing, but if you have stuff turned on that shouldn't be, then you have serious reason to be concerned.
 
Old 06-20-2004, 04:08 AM   #7
sbogus
Member
 
Registered: May 2004
Location: Germany, Munich
Distribution: SuSE Pro Releases 7.3, 9.0, CentOS 4.0, Kubuntu 6.0x
Posts: 103

Original Poster
Rep: Reputation: 15
Thanks for the recomendations Capt_Caveman!

I'd like to know what in your opinion looks suspicious? I don't know so much from Linux hacking and do not know what is chkrootkit nor what is rootkit at all.

The Licq stuff is there because on boot (I boot in init 5 state), after login the Licq is configured to load automaticaly, but not to connect automaticaly (I do that configuration), so I assume the listening should be normal. As for the other suspicious listening stuff (X, kdm) I do not know if this should be system-defined state or there's someone's malicious hand playing... I thought the xinetd deamon should be there as I boot in runlevel 5, but I might be wrong - please advise me! Which things seems to you to be wrong started and listening?
I'm really concerned about this issue as I've installed the firewall about 30 min after I got my DSL connection working, so to get hacked in 30 min among tousends of other on-line boxes seems to me to be almost impossible.

Furthermore, I've another question - I got the SystemRescueCD 0.2.14 burnt from an ISO, few weeks ago, but burned it on my Linux box at home - does this make the CD compromised?! Should I burn another CD from another more secure machine? I got the contents list of that CD so I know there's a tool named chkrootkit-0.43 - ist this Okay for checking for "rootkits"? Do I need another software to download and burn, in order to be able to verify the security of my box?

Many thanks in advance.

Kind regards,
sbogus
 
Old 06-20-2004, 04:25 AM   #8
ppuru
Senior Member
 
Registered: Mar 2003
Location: Beautiful BC
Distribution: RedHat & clones, Slackware, SuSE, OpenBSD
Posts: 1,791

Rep: Reputation: 46
you can prevent X from listening on 6000 by adding

-nolisten tcp

in your {g,k,x}dm.conf
 
Old 06-20-2004, 12:45 PM   #9
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 57
The main reason for concern is that you have conflicting results from a portscan and from the netstat/lsof commands. That in of itself is a red flag. There are really 3 explainations:
1)The port scan results are incorrect possibly due to user error (scanning the wrong IP or something) or because the scanner itself sucks.
2)The port scan results are correct and the netstat/lsof results are incorrect. This suggests that the commands have been replaced with trojaned versions or a LKM rootkit is obscuring the true state of the system.
3)Both the port scan and the netstat/lsof commands are correct and something is occuring in between the two systems (for example your ISP filtering certain ports). This doesn't seem likely though. Another possibility is that the services running on the system have changed in between the port scan and the netstat/lsof commands were run.

In particular the ports that are abnormal (not normal defaults) are:
ICQ --> you already explained this one
KDM/XDMRC --> xdmrc is a remote display manager the allows someone to login remotely and get an X session. Having X listen on port 6000 is pretty standard (though not particularly secure), but xdmrc is not a SUSE default as far as I know.

I'm not suggesting that you immediately wipe your box and reinstall, but you definitely need to find out why the port scan doesn't agree with the netstat output and why those ports are open. I would definitely try to duplicate the port scan results by scanning from another system. If that windows system is your only option, try using a different scanner. I believe that nmap has a windows port that you might want to try. I'd also run chkrootkit. The most recent version is 0.43, so the version on your CD is fine.

With regards to the short amount of time between activating you firewall; having a firewall on isn't a guarantee against getting hacked. It certainly reduces the risk if your firewall is properly configured, but there are many other components in securing a linux box (applying patches, turning off services, using secure computing practices. etc)
 
Old 06-21-2004, 04:19 AM   #10
sbogus
Member
 
Registered: May 2004
Location: Germany, Munich
Distribution: SuSE Pro Releases 7.3, 9.0, CentOS 4.0, Kubuntu 6.0x
Posts: 103

Original Poster
Rep: Reputation: 15
Hi again,

To ppuru: I didn't found anything of the files {g,k,x}dm.conf. Where are they supposed to reside in?. I've checked /etc and subdirectories as well as /opt +subdirs and /usr + subdirs.

To Capt_Caveman:
Thanks again for the explanations and for the suggestions. I've made the following things to investigate the issues with the strange differencies between the port scan and the internal port usage report from my box.

First of all I boot from a newly burnt (on a secure machine) SystemRescueCD version 0.2.14, which includes the chkrookit version 0.43 (the last available). The check gave only negative results (i.e. no rootkit was known to be installed on my machine). I did the check with a read-only mount of my partitions. Then I boot from the FIRE Forensic CD version 0.4 (the last available I think), mount the partitions read-only again and did the checks described in the CDs READMEs (they were so many so I do not remember all names anymore ). These tests also went withouth notification of presence of any instrussion or system crack. Then I dared to boot directly from my box, but specifying runlevel 1. I did then check with the netstat and lsof commands the ports usage - of course there was nothing lurking out of the box
Well then, started the next stage - runlevel 3, then check with netstat and lsof again. Aha! I got seen all the deamons there (dhcpcd, portmap, sshd, master, cupsd) with exception of the X ones (xinetd, kdm and X). I switched then to runlevel 5, logged in and checked again the ports usage. The X deamons were there, but when I closed the Licq application it disappears from the port usage list. I think the xdmcp module, which lurks as part of the kdm deamon, should be there as I use non-standard localization on my box, so on boot there's different codepage and keyboard layout loaded and at the GUI boot login I can use several languages. I assume xdmcp is the codepage deamon from the X server, which along with the font server ensures proper work at the GUI login prompt. I might be wrong of course, so if anyone thinks he/she knows better, please tell me!

Then, I download the chkrootkit from their homepage, compiled it and ran the checks again several times.
One "suspicious" thing was there notified - for just one single run I got a warning telling me that the file "/proc/4727/fd:" does not exist. I'm not sure if the colon char at the and of the file name was really there or not. I checked the /proc directory immediatelly and there was no such PID present, nor was it present in the list of the running processes. I ran the chkrootkit tests several times more after that case, but such alike warning didn't appear anymore.

The last thing I did was to download and install the Samhain intrussion detection system. It compiled without errors, I got it installed properly and I got it running at boot time. Now Samhain co-operates with the firewall (I don't know how did they found each other, but now both Samhain and the SuSE_ Firewall application know from each other and co-operate in the common task of blocking instruders/hackers/crackers and etc.) There's nothing suspicious from the Samhain's reports - I'll check them regulary to ensure nothing goes unnoticed.
If someone means such co-operation is suspicious and in general they should not mess up with each other, please feel free to advice me here! Many thanks in advance!

So, the resumee:
  • According to the checks, my box seems to be clean and uncompromised (of course no 100% security at all!)
  • Should be the chkrootkit (once) warning The file "/proc/4727/fd:" does not exist., where no such PID was seen in the system, something to be concerned about?
  • Should be the apparently easy co-operation/integration of Samhain and the SuSE_Firewall applications, such concerning case too?
  • I didn't used the command nmap -p <IP-address> to do the port scan on my box at home. I used instead a Windows application (my work machine runs W2k Pro) named IP-Tools, which provides several Net-tools and among them a port scanner. I plan to do second port scan with the nmap command but I'll then use a Cygwin implementation of that. Could this be the reason for the port usage difference?


Many thanks in advance.

Kind regards,
sbogus
 
Old 06-22-2004, 12:26 AM   #11
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 57
I think the xdmcp module, which lurks as part of the kdm deamon, should be there as I use non-standard localization on my box, so on boot there's different codepage and keyboard layout loaded and at the GUI boot login I can use several languages. I assume xdmcp is the codepage deamon from the X server, which along with the font server ensures proper work at the GUI login prompt.
You might want to try changing to the default layouts and seeing if it goes away. Normally xdmrc isn't a default, but then again it sounds like your system isn't very default.

One "suspicious" thing was there notified - for just one single run I got a warning telling me that the file "/proc/4727/fd:"
Chkrootkit is prone to these types of false positives, usually the best way to verify them is to re-run chkrootkit.

The last thing I did was to download and install the Samhain intrussion detection system.
Usually you'll want to install a file integrity scanner IDS like Samhain immediately after doing a fresh install and before connecting to the net, as it's main functions is to detect alteration of critical system files. If someone had already broken into your system and installed trojaned binaries, then it would be quite as effective. Still a good thing to have on your system though.

So, the resumee:
  • According to the checks, my box seems to be clean and uncompromised (of course no 100% security at all!)
  • Should be the chkrootkit (once) warning The file "/proc/4727/fd:" does not exist., where no such PID was seen in the system, something to be concerned about?
  • Should be the apparently easy co-operation/integration of Samhain and the SuSE_Firewall applications, such concerning case too?
  • I didn't used the command nmap -p <IP-address> to do the port scan on my box at home. I used instead a Windows application (my work machine runs W2k Pro) named IP-Tools, which provides several Net-tools and among them a port scanner. I plan to do second port scan with the nmap command but I'll then use a Cygwin implementation of that. Could this be the reason for the port usage difference?


Still not sure of what the cause is, but a compromise is starting to sound less likely. You might want to try a different port scanner to check the system. Even better, try scanning from a completely different box altogether.
 
Old 06-23-2004, 01:50 AM   #12
sbogus
Member
 
Registered: May 2004
Location: Germany, Munich
Distribution: SuSE Pro Releases 7.3, 9.0, CentOS 4.0, Kubuntu 6.0x
Posts: 103

Original Poster
Rep: Reputation: 15
Hi Capt_Caveman,

Quote:
You might want to try changing to the default layouts and seeing if it goes away. Normally xdmrc isn't a default, but then again it sounds like your system isn't very default.
Yeah, switching back to standard US Locale&Keyboard settings lets xdmcp deamon disappear, but it only disappears after reboot (in the newly configured US Locale&Keyboard settings). I assume it stills be there when I do a warm switch, because of the non-standard locale modules still be load and operating.

Quote:
Chkrootkit is prone to these types of false positives, usually the best way to verify them is to re-run chkrootkit.
I ran chkrootkit several times after thant, and no such or warning alike was to seen anymore, so according to your assumption, this should be just a false alarm.

Now the bad update of the story
Yesterday late evening, as I was about to go sleep, I noticed some CRIT messages from Samhain when I went to shutdown the machine (by Tux, this software rocks - I does its job very, very, very well!). I boot then again in runlevel 1 to see what these messages were about.

I found that some files on my machine have changed either their m_time, their attributes or their owner (now that was very suspicious to me!!!). The changing application were one and the same - the CUPS deamon and the PPPOE deamon for the PPP0 connection device.
ALARM! was my first thought, *Now I got it, I got the f$%$n' cracker what was rooting up my machine!*
By the way - chkrootkit stills say there's nothing installed/found from the known rootkits, nor it detects any trojaned binaries.

Now the questions about this finding:

A. The changed/modified file is /etc/resolv.conf. It contains no hosts in form of IP addresses, but rather than (currently) it contains one single hashed checksum (I believe it is a MD5 checksum, but it could be result of any other hash function). Furthermore, at boot time the SuSE_Firewall stage 2 and 3 tell me that there's no known hosts in the resolv.conf file. After I installed the firewall several weeks ago, it started to tell me so on each boot. I though it was normal state, so I ignored it, but now I can connect this notice to the message from the Samhain log file, so it now looks very strange to me. Is the modification and the state of the resolv.conf file a *normal* state?
B. The second modification was detected in the directory /etc/certs/cups/, therein the directory /etc/certs/cups/certs and the certificate file /etc/certs/cups/certs/0 were modified. The certificate file has changed its owner from root to lp, has got attributes several times changed from read-only to read/write and back to read-only and has got its m_time changed. The attributes and the m_time have been changed for the certificate directory too. The application that caused this was one and the same - the CUPS deamon. Is this something usual or should I consider the CUPS binary yet trojaned?

Also to say it again - all the checks from the chkrootkit, including ifpromisc tell me that nothing is wrong. I know that this is not to be 100% trusted as there's no 100% security at all, but I trust Samhain so I'm sure the PPPOE and the CUPS deamons play with these files, but I'm not sure if this *game* has some malicious background or it is a system issue.

Again, any information, recomendation, suggestion or just *hallo* is greatly appreciated.

Kind regards,
sbogus
 
Old 06-23-2004, 10:39 PM   #13
ppuru
Senior Member
 
Registered: Mar 2003
Location: Beautiful BC
Distribution: RedHat & clones, Slackware, SuSE, OpenBSD
Posts: 1,791

Rep: Reputation: 46
{g,k,x}dm.conf normally resides in /etc/X11/{g,k,x}dm directories on RedHat/Fedora.
 
Old 06-24-2004, 03:23 AM   #14
sbogus
Member
 
Registered: May 2004
Location: Germany, Munich
Distribution: SuSE Pro Releases 7.3, 9.0, CentOS 4.0, Kubuntu 6.0x
Posts: 103

Original Poster
Rep: Reputation: 15
Quote:
Originally posted by ppuru
{g,k,x}dm.conf normally resides in /etc/X11/{g,k,x}dm directories on RedHat/Fedora.
Thanks, but I've SuSE and not Fedora/Red Hat, so it is not in /etc/kdm nor in /etc/gdm nor in /etc/xdm.

Thanks anyway.

Kind regards,
sbogus
 
Old 06-24-2004, 08:01 PM   #15
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 57
Quote:
Originally posted by sbogus
Thanks, but I've SuSE and not Fedora/Red Hat, so it is not in /etc/kdm nor in /etc/gdm nor in /etc/xdm.

Thanks anyway.

Kind regards,
sbogus
In /etc/opt/kde3/share/config/kdm/Xservers add the -nolisten tcp to the end of the following line:

:0 local /usr/X11R6/bin/X vt7
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Strange installation results of Snort serverpimp Debian 3 11-01-2005 04:41 PM
Strange results from dmesg JimBass Linux - Newbie 11 03-27-2005 06:15 PM
Nvidia driver gives e strange results broken-cog Linux - Hardware 9 03-17-2005 10:25 AM
nmap scan results ! dimgr Linux - Security 3 01-21-2005 12:39 PM
nmap scan results juanb Linux - Security 5 11-16-2004 02:31 AM


All times are GMT -5. The time now is 03:45 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration