Default Services in Debian

This morning I started reading Debian GNU/Linux 3.1 Bible by Benjamin Mako Hill, David B. Harris and Jaldhar Vyas. I installed Debian 3.1r1 in a VM. I did not select any software packages. When done, this is the netstat output I saw:

richard@debian:~$ netstat -na -A inet
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:819 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:813 0.0.0.0:*
udp 0 0 0.0.0.0:816 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*

Am I seriously seeing portmapper (111 TCP, UDP) listening? Port 113 TCP is ident. I used lsof to discover that rpc.statd was opening other ports I didn't recognize:

debian:~# lsof | grep IPv4 | grep 81
rpc.statd 2757 root 4u IPv4 13603 UDP *:813
rpc.statd 2757 root 5u IPv4 13612 UDP *:816
rpc.statd 2757 root 6u IPv4 13616 TCP *:819 (LISTEN)

I do not see any reason for a system installed in 2006 to have portmapper or rpc.statd enabled by default.

Comments

Anonymous said…
Must be something that creeped into r1. r0 (the version with the book) only has smtp running on localhost. BTW, versions aren't necessarily 'problematic'; take a look at any RedHat Enterprise release and you'll see 'vulnerable' versions running, mainly because they patch the version that specific distro number was released with.
Hello Anonymous,

I don't care what versions are running. I'd like to know why RPC services are enabled at all. Didn't we learn our lesson with the multitude of exploits for RPC services on Unix (pre-2000 or so), before Windows was the target-du-jour?
John Ward said…
Its a little annoying the some Linux distros install services and activate them, even if you specify not to install them. I had the same issues with a few Red Hat based distros. I can’t remember off the top of my head if I had the same thing happen last time I installed Debian, but I wouldn't be surprised.
John Ward said…
Oh yeah, and we are only 2 days into 2006, so I don't think too much innovation is going to happen 2 days past 2005 progress in this area ;)

But good point, this shouldn't really be the case in this day and age. For a OS that is "more secure" than Brand X OS, services should be turned off by default and enabled as needed.
Hi jeraklo,

Are you referring to The Debian System? I plan to start reading that book tomorrow. Debian GNU/Linux 3.1 Bible is full of what you talk about -- how to set up Apache, DNS, etc. -- stuff I don't care for either.
Anonymous said…
The reasons behind services listening on default instead of being enabled on default are explained in the --same goes for the reason that portmapper and ident are installed and enabled.

From the Debian security manual:

11.1.14.1 Why are all services activated upon installation?

That's just an approach to the problem of being, on one side, security conscious and on the other side user friendly. Unlike OpenBSD, which disables all services unless activated by the administrator, Debian GNU/Linux will activate all installed services unless deactivated (see Disabling daemon services, Section 3.6.1 for more information). After all you installed the service, didn't you?

There has been much discussion on Debian mailing lists (both at debian-devel and at debian-security) regarding which is the better approach for a standard installation. However, as of this writing (March 2002), there still isn't a consensus.


11.1.14.3 Why do I have port 111 open?

Port 111 is sunrpc's portmapper, and it is installed by default as part of Debian's base installation since there is no need to know when a user's program might need RPC to work correctly. In any case, it is used mostly for NFS. If you do not need it, remove it as explained in Securing RPC services, Section 5.13.

In versions of the portmap package later than 5-5 you can actually have the portmapper installed but listening only on localhost (by modifying /etc/default/portmap)


11.1.14.4 What use is identd (port 113) for?

Identd service is an authentication service that identifies the owner of a specific TCP/IP connection to the remote server accepting the connection. Typically, when a user connects to a remote host, inetd on the remote host sends back a query to port 113 to find the owner information. It is often used by mail, FTP and IRC servers, and can also be used to track down which user in your local system is attacking a remote system.

There has been extensive discussion on the security of identd (See mailing list archives). In general, identd is more helpful on a multi-user system than on a single user workstation. If you don't have a use for it, disable it, so that you are not leaving a service open to the outside world. If you decide to firewall the identd port, please use a reject policy and not a deny policy, otherwise a connection to a server utilizing identd will hang until a timeout expires (see reject or deny issues).


Me personally, I disagree with the Debian project's decision to even have portmap and identd be installed on default let alone running and I tend to disable those two services. If I recall before the release of Sarge, portmap was required (it was a dependancy for fam) to run Gnome on Debian though--not anymore thankfully.
Anonymous said…
Richard:

Unfortunately, any services automatically turned on during installation leave a potential security hole. The only OS that doesn't do this (from my experience) is OpenBSD. However, RPC is not uncommon in the *NIX world. Considering that you are a FreeBSD user, the only *officially* recognized method (according the the FreeBSD Handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/small-lan.html ) of ensuring uniform multiple machine updates for the BSD's is NFS mounts following a buildworld and buildkernel. This, of course, requires RPC. Although Debian doesn't use this method, it is quite apparent that RPC usage is still widespread amongst *NIX network applications. The only way I see of ensuring that RPC and portmapper no longer get used, is to make sure that network applications no longer use RPC! Shouldn't our community (the open source community) that touts 'Security, Stability' in many of its slogans STOP using insecure services? Shouldn't we follow our own advice?
Anonymous said…
Richard,

Just as an FYI: Ubuntu, a Debian derivative, has a default install which leaves no open ports. Not one.

I used Debian for years, and still feel it's a great distro, but as of Ubuntu 5.10, I did migrate completely to it, both on my desktops and on my servers. I've not regretted it. Check it out at: http://www.ubuntu.com

Dave
Anonymous said…
Remember, you can use "-p" with netstat for view what apps are opening ports, dont need lsof :-)
Anonymous said…
Hi Richard,

Debian 3.1 is the first release with the new debian-installer installer, and there are still vestiges of the old boot-floppies scheme around -- for instance, the configuration that occurs on the first boot after the installation.

One of the items on the base-config menu is task selection (tasksel), which installs additional packages even if no tasks are selected. If you did a standard installation (enter or 'linux' or 'linux26' at the installer boot prompt), you won't get a chance to circumvent tasksel. If you do an expert install ('expert' or 'expert26' at the boot prompt), the installer asks more questions and allows you to select installation items from a menu, i.e. one can skip tasksel entirely.

On Debian 3.1r1 i386, skipping tasksel entirely in expert mode results in these core 137 packages installed:

adduser apt apt-utils aptitude at base-config base-files base-passwd bash bsdmainutils bsdutils console-common console-data console-tools coreutils cpio cramfsprogs cron dash debconf debconf-i18n debianutils dhcp-client diff discover1 discover1-data dpkg dselect e2fslibs e2fsprogs ed eject exim4 exim4-base exim4-config exim4-daemon-light fdutils findutils gcc-3.3-base gettext-base grep groff-base grub gzip hostname hotplug ifupdown info initrd-tools initscripts ipchains iptables iputils-ping kernel-image-2.6-k7 kernel-image-2.6.8-2-k7 klogd libacl1 libattr1 libblkid1 libc6 libcap1 libcomerr2 libconsole libdb1-compat libdb3 libdb4.2 libdiscover1 libgcc1 libgcrypt11 libgdbm3 libgnutls11 libgpg-error0 liblocale-gettext-perl liblockfile1 liblzo1 libncurses5 libnewt0.51 libopencdk8 libpam-modules libpam-runtime libpam0g libpcap0.7 libpcre3 libpopt0 libsigc++-1.2-5c102 libss2 libssl0.9.7 libstdc++5 libtasn1-2 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libtextwrap1 libusb-0.1-4 libuuid1 libwrap0 locales login logrotate mailx makedev man-db manpages mawk module-init-tools modutils mount nano ncurses-base ncurses-bin net-tools netbase netkit-inetd nvi passwd pciutils perl-base ppp pppconfig pppoe pppoeconf procps psmisc sed slang1a-utf8 sysklogd sysv-rc sysvinit tar tasksel tcpd telnet usbutils util-linux wget whiptail zlib1g

(The installer selected the k7 flavor of the kernel-image since I installed on an Athlon MP in VMware.)

Running tasksel, but selecting none of the options, results in these additional 86 packages:

bc bin86 bind9-host binutils bison cpp cpp-3.3 dc dictionaries-common dnsutils doc-debian doc-linux-text dpkg-dev file finger flex ftp g++ g++-3.3 gcc gcc-3.3 gdb gnu-efi gnupg iamerican ibritish ispell less libbz2-1.0 libc6-dev libdb4.3 libdns16 libevent1 libgc1 libgpmg1 libident libidn11 libisc7 libkrb53 libldap-2.2-7 libldap2 liblwres1 libmagic1 libncursesw5 libnfsidmap1 libnss-db libreadline4 libreadline5 libsasl2 libstdc++5-3.3-dev libtasn1-0 linux-kernel-headers lpr lsof m4 make manpages-dev mime-support mpack mtools mtr-tiny mutt ncurses-term nfs-common patch perl perl-modules pidentd portmap procmail python python-newt python2.3 rcs reportbug sharutils slang1 ssh strace tcsh texinfo time traceroute w3m wamerican whois

The services you found active come from the packages pidentd, portmap, and nfs-common.

To more effectively control the exact package set you want installed (perhaps as part of a standard rollout), you should check out the --get-selections and --set-selections flags to dpkg(1):

dpkg --get-selections [package-name-pattern...]
Get list of package selections, and write it to stdout.

dpkg --set-selections
Set package selections using file read from stdin. This file should be in the format 'package state',
where state is one of install, hold, deinstall or purge. Blank lines and comment lines beginning with '#'
are also permitted.

Both the first boot configuration and tasksel are supposed to be removed, hopefully in the next Debian release, and their functionality reworked and integrated into debian-installer.
Unknown said…
This comment has been removed by a blog administrator.

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics