Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm new to Linux and need to tune my server that i leased.
I was looking for the internet super deamon(inetd & xinetd) however i can't find any trace of it in the machine
(i can't find inetd.conf or xinetd.conf either when i do find / -name inetd or xinetd).
However, i found /etc/services that have some listings as below.
My question is: Does anybody know how to make certain that inetd/xinetd deamons are not installed or hidden from such commands as(ls, ll)
I don't want bore you with the output of /etc/services which is rathar long so i'm pasting some of it
I just need to be 100% sure that this is harmless/garbage and how to remove stuff in /etc/services if i don't need it.
Needless to say, I don't need 99% of what's listed below.
Again, sorry to paste this long content below, i be glad to edit it and remove it if you think its garbage.
One of the places where you will find the most differences among distros is in /etc. Slackware's /etc differs significantly from Fedora's, for example, especially as regards startup configuration.
There is file /etc/services on my Debian box. It's a listing of the ports assigned to various functions and services. It looks similar to what you posted.
Last edited by frankbell; 11-14-2011 at 08:43 PM.
Reason: Accuracy
Yeah, I'm using Debian. and netstat is not showing anything open but i was just concerned the amount of stuff that /etc/services showed.
More importantly:
Does anybody know how to make certain that inetd/xinetd deamons are not installed or hidden from such commands as(ls, ll)
/etc/services simply maps "port-numbers and protocols" to symbolic names. So that, say, if you wanted to connect to prospero, you wouldn't have to know (and would not code into your program) the fact that to do so you must connect to port #191 using either TCP or UDP.
Don't touchany file that you do not clearly understand!
One day ... ... your forehead will thank me for saying that.
Needless to say, I don't need 99% of what's listed below.
Wow. Most people don't need 99.9% of what is listed there, so you must be running a lot of stuff...
Seriously though, not only does /etc/services not have anything at all to do with what is actually running, it also doesn't necessarily have anything to do with which port a service might actually run on, if it did run. It really is just an advisory saying '...if xxxx did run, the conventional port for it to use is yyyy...'.
So, for example, you'll find it easy to look up the conventional port for ssh, but many people run ssh on some other port and /etc/services won't get updated for changes like this, unless someone does it manually (and, as far as I can tell, no one does...I have seen people parse /etc/services for use in their firewall, but that is always subject problems if someone does use a non-default port, so that seems a bit risky, unless you really, really, know services will stick to their default port number, or that someone will update /etc/services. Which, as I say, they usually won't.)
It is always a bit of a problem if you can't trust the output from the normal utilities, but do you have any particular reason for not doing that? I mean, is it just general, multi-purpose, paranoia (that's not a judgement) or is there something specific that makes you think that something may be wrong?
So, as a suggestion, what about using a firewall? If you only allow the ports that you know are being used by services that you have decided to allow, isn't that a step forward?
All 3 of you have given good hints that i will try.
I had no idea what /etc/services did and thanks for the inputs.
Salasi:When i say i don't trust the commands such as (ls, cat) i meant that this being internet based system that i leased and attempts have been made in the past i have my suspicion and I'm eliminating one thing at a time which is why i stumbled upon the /etc/services.
Also, yes, I'm using firewall as well.
OK, assuming that you are using a firewall, and that you are happy configuring it...
Many people only do ingress filtering (ie, let the box send out what it likes, but only allow packets in if they are expected ports or related to someth that the box itself has started), but what about adding egress filtering?
That is, what about allowing out ports that you already know that you are using (based on services that you know that you use, and the ports that you know that those services are configured to use) and logging and dropping everything else? When you first try this, you'll get something wrong (you'll have either overlooked a service, or some service will use a few more ports than was immediately obvious) but you will rapidly build up a list, hopefully short, of things that you didn't know about or had overlooked, and you will have blocked off any random services which start up and claim unanticipated ports to communicate with the outside world?
Now if this is something like a colo box, there is the possibility that fiddling with iptables rules could break something that you need (eg, ssh), so you have to be careful that you don't get locked out (getting locked out is embarrassing, and brings to mind the phrase "... a trivial change is one that needs no testing before bringing down the whole system...") and maybe even doing something that automatically restores the old set of rules if something goes wrong - you can script this, but it all depends on your familiarity with the system, and what exactly the penalty for being locked out is - for a box with a 30 second walk to physically access, you'd probably be a whole lot less concerned than one which isn't in the same time zone. Arguably.
At, again, the possible expense of shooting off at a tangent, can I ask if SSH has been made secure? It seems that a lot of people assume, maybe because SSH has 'secure' in the acronym, that SSH should be secure by default. Well, whether it should or it shouldn't be, an out-of-the-box ssh isn't usually all that secure, and many people assume the opposite. (See here for a review of the different methods for improving ssh security - there are many of them - but, even with modestly good passwords, which aren't universal, if someone can take (quasi-)infinitely many guesses at your password, and that will allow them in as root, you have a potential problem).
what exactly are you leasing? the leasing agreement should clearly state what you are getting and what each party is responsible for. if its just a box with OS/disk/net then you should have full visibility and full control of the box. are you managing your box through a web interface, telnet, ssh, other ??
may we ask, if you dont know much about debian (or nix in general) then why have you leased a debian box from a place far far away?
you marked this thread as SOLVED, so how was it SOLVED?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Don't touch any file that you do not clearly understand! 
... your forehead will thank me for saying that.
