Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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? )
Oki, thanks very much. I've now stopped portmap by issuing,
sudo /etc/init.d/portmap stop
(now port 111 is closed), and disabled it by issuing,
sudo chmod -x /etc/init.d/portmap
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.
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
"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.
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:
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."
Last edited by MensaWater; 06-29-2006 at 07:26 AM.