Newsgroups: gmane.linux.debian.user Date: Thu, 07 Sep 2006 12:56:57 +0200
Newsgroups: gmane.linux.debian.user Date: Thu, 07 Sep 2006 12:56:57 +0200
Hi
Hope I'm not starting a religious war here, but I'd like to know whether inetd or xinetd is preferred for a *personal environment*.
In my current system:
$ cat /etc/init.d/inetd #!/bin/sh # /etc/init.d/inetd has been diverted by the xinetd package. # The inetd service is provided by xinetd, which means inetd # doesn't need to be run. # # See /etc/init.d/xinetd, or /etc/init.d/inetd.real. exit 0
Does it imply xinetd is more favorable than inetd?
Thanks
T
> # /etc/init.d/inetd has been diverted by the xinetd package. ... > Does it imply xinetd is more favorable than inetd?
No, it only means you (or someone else) has installed xinetd and since inetd and xinetd cannot coexist on the same system, xinetd is used instead of the default inetd.
A 'diversion' in Debian parlance occurs when two packages occupy the same file on a system (in this case /etc/init.d/inetd). See 'man dpkg-divert' for a more elaborate explanation (but don't use it until you really know what you are doing).
Jochen Schulz
inetd is more than ok for a personal environment, why not also for a professional setup. xinetd is far more featured, though, and it's been the default for Red Hat systems for years.
Ismael Valladolid Torres
> > inetd is more than ok for a personal environment, why not also for a > > professional setup. > > Thanks Ismael for the reply. I value each respond. however, I can't > understand your last part of the sentence. could you rephrase it please?
I think inetd is more than OK for a professional setup. It's ancient and much debugged.
Ismael Valladolid Torres
> whether inetd or xinetd is preferred for a *personal environment*.
I prefer xinetd anywhere. IT's better configurable, even if some programs do not support it and I had to configure it myself yet
Matus UHLAR - fantomas
> inetd is more than ok for a personal environment, why not also for a > professional setup. xinetd is far more featured, though, and it's been > the default for Red Hat systems for years.
I would say that the choice between the two is defined not by how 'professional' your host is, but rather by the hostility of the networking environment. Xinetd can limit the number of connections and running processes, preventing some DoS attacks. Xinetd also has a more extensive logging. There are other improvements over inetd (see xinetd faq [0], for example, or this article [1]). So, if your network is not well protected, you may want to replace inetd with xinetd (and don't forget to configure it properly :))
[0] http://www.xinetd.org/faq.html [1] http://www.linuxfocus.org/English/November2000/article175.shtml
Dmitri Minaev
> ... So, if your network is not > well protected, you may want to replace inetd with xinetd (and don't > forget to configure it properly :))
You may also not care about it. My /etc/inetd.conf has nothing but comments, and it's not like I worked hard to keep it that way: the "normal" content of my inetd.conf (after a plain install plus some months of upgrade and things like that, none of which related particularly to inetd) is a single line that starts identd. I apt-removed pidentd and now it's completely empty. At that point, I really couldn't care less whether I'm using xinetd or inetd.
Stefan Monnier
PS: Funnily enough `apt-get remove openbsd-inetd' says that a whole bunch of packages depend on it:
> inetd or xinetd is preferred for a *personal environment*.
I like openbsd-inetd because it's straightforward, lightweight and got the OpenBSD seal of approval for daemon software. They make a good ssh as well.
Paul Johnson
> I like openbsd-inetd because it's straightforward, lightweight and ...
openbsd-inetd also has the advantage that it can be made to listen on a single network interface, rather than all interfaces.
Liam O'Toole
inetd <-> 64% xinetd <-> 27% others? <-> 8%
Unstable now uses openbsd-inetd as the default inetd. I like the security focus of openbsd, but I prefer to use Debian for a workstation and server OS for several reasons. Still, I was happy that the devs chose the superior openbsd tool over an aging default inetd recently. I am heartened to see cross-breading of good work in the FOSS community.
Anonymous (67.184.xx.xx) on Thu 7 Sep 2006
>I'm in the process of intalling Secure Shell Package. To boost security >of our cluster, I plan to disable telnetd, rlogind and maybe ftpd.
To disable most internet services, you have to edit the /etc/inetd.conf file. You should, after installing ssh, disable everysingle line in that file except the ftpd if your hardcore about setting up a secure server/workstation.
Send a HUP signal to the inetd process afterwards.
As far as configuring ftpd to only accept anonymous, create a file called /etc/ftpusers with a list of every single entry in your /etc/passwd file, except the anonymous user. This will disallow any user from ftp'ing into the box except 'anonymous'.
—Basit
Newsgroups: gmane.linux.debian.user Date: Fri, 14 Sep 2007
> Some services listed in /etc/services, might never be intended > to operate on a specific machine. bootps and finger are likely > examples. > > In interest of security, is there any benefit in commenting out > unused services?
No, you would disable services through changing /etc/inetd.conf (read "man update-inetd") and stopping programs in /etc/init.d/.
Mumia W @earthlink.net
comp.os.linux.security : Close the ports in /etc/services : check /etc/inetd.conf for daemons running on those ports.
What exactly do you mean by "Close the ports in /etc/services"?
This sounds like you're telling them to edit /etc/services or something, which is entirely the wrong way to go about doing it (it breaks functionality of the client as well as the daemon (and possibly other programs as well)).
If you mean that they should look at /etc/services to determine what ports telnet/ftp are running on, and then use ipchains or something to block those ports, you may as well just tell them to use ipchains to block off any unneeded ports.
You might also tell them to comment out any unneeded entries in /etc/inetd.conf, rather than just telling them to look in it :)
jessica
Inetd.conf will reveal to the user what services are directly run via inetd. Perhaps you should have listed how to run services using tcp_wrappers with tcpd. Learning how to utilize access.conf, hosts.allow and hosts.deny is extremely beneficial to users wanting to add security. After all, a good firewall only restricts the access points for intruders, you need to have security measures in place to handle those open access points.
> First of all, defining a port in /etc/services will allow a service to > "listen" on that port. Why do you limit yourself to checking only telnet > and ftp? There are several thousand port numbers defined by IANA.
Crap. A service will listen on a port regardless of whether the port has a friendly name or not. So you check what services you're running, block off what you don't want — What I meant to say was that this is a precursor to blocking off everything with a proper firewall, then enabling the services you want to connect to from <whichever> machines only. Y'know the story.
> Now it is true that not all daemons are defined by the contents of > /etc/services. > However, by directing the user to that file first, he/she will gain an > idea of what might be open. By remarking ports that are not to be > used, you are basically turning off the bright lights one by one on > your burger shack.
Perhaps you ought to start with a simple tool designed for the express purpose of checking what's listening instead of wasting everyone's time with a round-the-houses approach? `man netstat`.
: Guess what? A "client" is not a "service".
Yup. And guess what? Both the client and the service use /etc/services to look up their default port in many cases.
: Now it is true that not all daemons are defined by the contents of : /etc/services. : However, by directing the user to that file first, he/she will gain an : idea of what might be open. By remarking ports that are not to be : used, you are basically turning off the bright lights one by one on : your burger shack. : ((Have I mentioned yet that you need to spend some quiet time READING : a couple books on linux or even Unix system administration?))
Ok…
I just edited /etc/services, and commented out the lines for telnet.
I type "telnet hostname"
I get "telnet: tcp/telnet: unknown service"
Is this fatal? No. You can specify the port number as well, and still connect just fine.
But that's beside the point. Breaking functionality is *NOT* the way you solve the problem of open ports. Not starting the service in the first place is the correct way. By commenting out the entry in /etc/services, you're relying on the service breaking in the way you want it to. It could default to using a hardcoded port number, or some other unexpected behavior. Plus it may break other parts of the system (like the client) that you don't expect.
This also makes things more difficult to troubleshoot. For example, the user comments out the entries for www. But he can still connect to the web server. Why? Because the default port for apache is defined in httpd.conf, not /etc/services. Now, if he didn't start up apache in the first place, this wouldn't be an issue.
BTW, please tell me which UNIX/Linux book you read that reccomends disabling services by editing /etc/services. I'd love to read it.
jessica
>> 2000.05.27 Sat 13:22:25
Newsgroups: comp.unix.shell > Is there a way that I can tell (in my login script) that whether I'm > loggin in via telnet or rsh/rlogin? > > I realized that I need different mechanizm to set my DISPLAY for telnet > or rsh/rlogin. Thanks
As far as I can tell, there is no variable that is set as standard which tells the shell which method you used to log in. The only hope you have is that there is some difference in the set up which means that different environment variables are set depending on how you log in. I did a test on two different machines that I have access to at Uni. The test was:
$ rlogin machine password:
machine $ export > rlogin.export machine $ logout $ telnet machine
login: me password:
machine $ export > telnet.export machine $ diff rlogin.export telnet.export … possible output …
On one machine, a sparc SunOS 5.7, there were differences which could be used as a test. However, on another machine I tried it on, sparc SysV 4.0, there was absolutely no difference. I think that unless there is some difference in the initial environment when you first log in, it is going to be very difficult to tell one way or the other. The test would be very unportable and very "hit-and-miss".
Perhaps if you explained why you need two different DISPLAY variables for the different methods, somebody could come up with a solution to your problem.
Another possibility is to install ssh. In addition to being more secure than rsh or telnet, it automatically sets up the display: hence you wouldn't need to worry about it! ;-)
Dave.
>> 2000.05.05 Fri 19:51:01
rcp host:/path/to/my.file.tgz .
rcp - remote file copy
SYNOPSIS
rcp [ -p ] filename1 filename2
rcp [ -pr ] filename...directory
DESCRIPTION
The rcp command copies files between machines. Each
filename or directory argument is either a remote file name
of the form:
hostname:path
rcp does not prompt for passwords; your current local user name must exist on hostname and allow remote command execu- tion by rsh(1).
rcp handles third party copies, where neither source nor target files are on the current machine. Hostnames may also take the form
username@hostname:filename
NOTES
rcp can become confused by output generated by commands in a $HOME/.profile on the remote host.
rcp requires that the source host have permission to execute commands on the remote host when doing third-party copies.
The GPL version downloaded from
documented on: 2001.03.13
Newsgroups: comp.os.linux.networking Date: 1995/10/24
2) When I try to use the "talk" or "ntalk" commands, I get: Error on read from talk daemon : Connection refused (111)
Ahh, my favorite error…the old talk daemon 111. Bleh.
Let's assume for the sake of sanity that you're using a dynamic IP address.
You'll get that error unless you bother to change your /etc/hosts file every time to match the assigned IP from your provider and then sending the inetd a HUP (kill -1).
If you're using a static IP, just make sure you have /etc/hosts set up properly.
And incidentally, the only time I ever get the 111 refusal anymore is on a machine where it's been expressly disabled (Or they don't even have a talk daemon on the other end).
Ford Prefect
Newsgroups: linux.redhat.misc, comp.os.linux.misc Date: 2001-11-28 20:15:11 PST
I can't use talk in my newly installed RedHat 7.2. When I issue talk I get :
Error on read from talk daemon: Connection refused.
Please, somebody helps me. The following are my relevant info:
$ uname -a Linux 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown
$ mesg is y
$ ps -eaf | grep inet root 901 1 0 10:39 ? 00:00:00 xinetd -stayalive -reuse-pidfile /va
$ cat /etc/xinetd.d/talk
# default: off
# description: The talk server accepts talk requests for chatting with users \
# on other systems.
service talk
{
disable = no
socket_type = dgram
wait = yes
user = nobody
group = tty
server = /usr/sbin/in.talkd
}
To solve the problem:
enable ntalk istead talk deamon in serviceconf
add myself to group tty
/sbin/chkconfig —level 0123456 talk off /sbin/chkconfig —level 345 ntalk on
Perhaps the most popular IRC Unix server today is IRCD
Dalnet's DreamForge IRC Daemon will only work if you are setting up the server on the Dalnet network
A widely used console based client is irssi, http://www.irssi.org/
and a widely used X based client is X-Chat. http://www.xchat.org/
Newsgroups: comp.os.linux.misc
> I am using a proxy server on a linux box and have a connection through a > cable internet provider with a static IP. Now I am wondering if you can > setup Squid proxy server to let in my computers on the home network with > a different set of ip addresses.... > (e.g. cable IP = 24.183.219.xxx and home IP = 192.168.0.xxx) without the > use of another network card on server or router?
no problem, just setup your squid.conf the right way and restart squid via it's init script (SuSE) /sbin/init.d/squid…
You should have some lines in squid.conf like:
acl localhost src 127.0.0.1/255.255.255.255 acl MyEthernet src 192.168.0.99-192.168.0.100/255.255.255.0 http_access allow MyEthernet http_access deny all !localhost !MyEthernet icp_access allow MyEthernet icp_access deny all !localhost !MyEthernet
For easy setup look out for webmin or use swat, but configure it propably, to only allow access to it from one box.
Better, read the docs that come with squid…:-)
Good luck
Michael Heiming
rpmih dhcp-3.0pl1-9.i386.rpm rpmqm dhcp
sed 's/\.1\.1/.0.1/g' /usr/share/doc/dhcp-3.0pl1/dhcpd.conf.sample > /etc/dhcpd.conf l /etc/dhcpd.conf
ifdown eth0 ifconfig eth0 192.168.0.1 broadcast 192.168.0.255 netmask 255.255.255.0
service dhcpd start
No, didn't get it going. The following was what I changed:
rm /var/lib/dhcp/dhclient.leases
% dhclient eth0 Listening on LPF/eth0/00:07:95:37:6d:13 Sending on LPF/eth0/00:07:95:37:6d:13 Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 DHCPOFFER from 192.168.0.1 DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.255 -- renewal in 10748 seconds.
% cat /var/lib/dhcp/dhclient.leases
lease {
interface "eth0";
fixed-address 192.168.0.255;
option subnet-mask 255.255.255.0;
option time-offset -18000;
option routers 192.168.0.1;
option dhcp-lease-time 21600;
option dhcp-message-type 5;
option domain-name-servers 192.168.0.1;
option dhcp-server-identifier 192.168.0.1;
option nis-domain "domain.org";
option domain-name "domain.org";
renew 5 2002/12/13 07:03:31;
rebind 5 2002/12/13 09:19:23;
expire 5 2002/12/13 10:04:23;
}