Why are these ports open: 111, 898?
 

On Ubuntu Dapper, a portscan on 127.0.0.1 returns
sunrpc appears to be related to the Linux kernel but I don't think I need Remote Procedure Calls. How do I disable the application that opens the port?

As for port 898, how can I find out which application has opened it?

Thanks

BTW, I'd also like to learn how to do a portscan by using the shell.

lsof -i :111
lsof -i :898

Should show you what process has the port open. RPC is used for various networking things (NFS e.g.) The process running is "portmap". Do "man portmap" to see what this is.

the sunrpc is initiated by the portmap service. So stopping that service from bootup should do it.

I wish I could tell you what exactly to do, but I never used Ubuntu. Maybe try :

chkconfig portmap off
chmod -x /etc/rc.d/init.d/portmap
chmod -x /etc/rc.d/portmap

There could be a nice pretty gui thingy in Ubuntu where you can just take a check mark off of the portmap service and save settings.

but with the hints, either A) you'll figure it out, or B) an Ubuntu user will tell you exactly where to go.

as of port 898, usually that is caused by Solaris Management Console server (usually) so maybe that'll lead you in the right direction, not sure.

So, port 898 is related to RPC, too. Hhmm...

And yes, there is a GUI tool in Ubuntu, indeed: the Boot-up Manager. When I try to uncheck portmap there (I'd started the program as root), there'll be the message,
Also, /etc/init.d and rc is not the only place where there are scripts that start portmap: There are also
After all, I'm not sure whether I should close these ports at all. All I can say is, they haven't been open few days ago...

Thanks

------------
BTW,
So root is listening, directly at the networking interfaces??

The scripts in /etc/rc?.d are typically links (usually soft links) back to the scripts in /etc/init.d. The ? in rc is the run level at which the script runs. File that have names beginning K## are the stop (Kill) scripts and the ones that beginning with S## are the start scripts. They are links to the same script so the start and stop routines exist within the script and it is the naming convention that makes them decide whether to start or stop.

You can therefore try running the stop on the script (/etc/init.d/<scriptname> stop) to see if stopping portmap causes the listeners to go away and if so whether it causes you any problems. Note that some things daemonized at start up only go away at a shutdown.

In answer to your last question: rpc.statd is Listening. rpc.statd is running as root so you can say "root is listening" semantically but technically doesn't give the pictur. Unless there is an exploit of rpc.statd it doesn't matter that root is running it and for most daemons root MUST be the owner as they interact at a level for which other users wouldn't have permission. (You don't really want billybob deciding when to reject network packets do you? :D)

Oki, thanks very much. I've now stopped portmap by issuing,
(now port 111 is closed), and disabled it by issuing,
Web and mail are still working so I'd just remember this if there were problems connecting to some LAN.

Now what about port 898?
I didn't find any script that starts this thread, and haven't been able to find out for which purpose it has been started.

"Unless there is an exploit" - yup, that's what I'm about. I'll tell you of my current understanding (please correct me if that's wrong): If, i.e., port 80 is open, noone can access it - until there's some application behind it. Let this application be Apache HTTPD. Apache is quite secure, hence I wouldn't worry too much. Nevertheless, at the moment I link some PHP forum application (like LinuxQuestion.org's ;)) to it (there are security issues with them all the time), there was a major risk of exploits, indeed.

I'd like to ensure only proven and mature processes open ports to the outside network. Additionally, I'd like to know when they are doing so, and why.

When a port is "open" (actually "listening") then it can be attached to (try telnet hostname 80) and hackers can therefore try to find an exploit. While apache can have fairly tight security it can also have fairly loose security. (Its only as good as the person that compiled and configured it - are you running all your processes as root for example?) Also while apache is the web server of choice there are other things that can and do use port 80 for web services (that is to say I've seen things that open port 80 but don't run any process named "httpd" or "httpsd".

Exploits are generally known and mitigated fairly rapidly. You can search the web specifically for rpc.statd exploits to see if there are any known then take the remedial action listed for same if there is. Have a look at CERT stuff for more details.

The port itself is not the concern but rather the application that is listening. For example sshd does NOT have to run on port 22 but that is its default port. If sshd can be compromised it can be compromised on whatever port it runs on. Despite that some users will run sshd on a non-standard port just because it hardens the target by making the hacker find not only that your port is open but trying to determine what is running on the port instead of just attacking well known ports.

The above doesn't mean you shouldn't lock down unnecessary ports but rather that you should determine if the port is necessary and if so make sure you've mitigated the risks as much as possible.

Hehe,
- I've also disabled rpc.statd now by issuing,
(and killed the process by using the System Monitor).
Internet's still working... Let's wait if there'll be errors on boot time...

Thanks for the information. I.e., I've noticed the notes on "default and other" ports, and,
Well, this ain't Microsoft Windows, ain't it? (Using Windows without a Firewall is, using Windows for 20 minutes, only ;))

-----
Although my current issues are solved (both irritating ports are closed now, and no errors occured after closing them), I'd really like to know for what these RPC ports could be useful?

Thanks again

RPC stands for Remote Procedure Call. The only reason I've ever really needed to do anything with rpc is for NFS purposes. However on Linux as seen it appears portmap wants to listen on port 111. That doesn't mean that rpc is only used for NFS but rather that the only times I've truly been conscious of it were in troubleshooting NFS issues.

Just for the heck of it I did a Google search for "rpc.statd" and found the following CERT advisory from 2000:

http://www.cert.org/advisories/CA-2000-17.html

I liked it because it talked about an exploit as I'd mentioned (along with CERT).

It gives the options of upgrading your rpc.statd (since this is from 2000 you probably already have a newer one - I'm just using it as an example) or disabling it.

In comments about disabling it says:
"If an update cannot be applied, the CERT/CC recommends disabling the rpc.statd service. We advise proceeding with caution, however, as disabling this process can interfere with NFS functionality."