Software version: net-misc/quagga-0.98.5-r3 Steps to reproduce: 1) emerge net-misc/quagga 2) start /etc/init.d/zebra and any other routing daemons 3) run netstat -lnp 4) Note that zebra is running on 0.0.0.0:2601 Expected Results: zebra should be listening on 127.0.0.1:2601 for security reasons. Build date: 25 Mar 2006 on Gentoo Linux 2005.1 Package net-misc/quagga should use more secure default settings. In it's default state, the various quagga daemons listen on all addresses with their built in telnet servers. As telnet uses plaintext for all traffic, including passwords, the recommended default should be to listen on the localhost only. This can be done by editing the file /etc/conf.d/zebra to read: ZEBRA_OPTS="-l 255 -A 127.0.0.1" Additionally, the same should be done for all of the other Quagga daemons. For example, the file /etc/conf.d/ospfd should be created by default and read the following: OSPFD_OPTS="-l 255 -A 127.0.0.1" Of course, this would require that /etc/init.d/ospfd be changed from: start-stop-daemon --start --quiet --exec /usr/sbin/ospfd \ -- -d -f /etc/quagga/ospfd.conf \ --pid_file /var/run/quagga/ospfd.pid to read: start-stop-daemon --start --quiet --exec /usr/sbin/ospfd \ -- -d -f /etc/quagga/ospfd.conf ${OSPFD_OPTS} \ --pid_file /var/run/quagga/ospfd.pid These steps should be taken on each of the Quagga daemons to ensure much more secure default settings. Thoughts? emerge info: Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-gentoo-r5 i686) ================================================================= System uname: 2.6.14-gentoo-r5 i686 AMD Athlon(tm) XP 3200+ Gentoo Base System version 1.6.14 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distcc distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo http://gentoo.cccom.com/ http://gentoo.mirrors.pair.com/" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://loki.asgard.fu/gentoo-portage" USE="3dnow 3dnowex 3dnowext aac alsa apache2 audiofile avi berkdb bitmap-fonts bzip2 cdda cddb crypt dri eds emboss encode exif expat faad fam firefox flac fmpeg foomaticdb fortran gd gdbm gif gnutls gpm gstreamer hal howl imlib java javascript jpeg libg++ libwww mad mhash mikmod mmx mmx2 mmxext motif mp3 mysql ncurses net network nfs nls nptl nptlonly ogg oggvorbis opengl oss pam pcre pdflib perl php png python quicktime readline rrdtool snmp spell sse ssl stream streamout tcpd theora threads tidy tiff transcode truetype truetype-fonts type1-fonts udev unicode usb utf8 vorbis x86 xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Unless you configure a password, you cannot connect to vty ports remotely. By default, there is no password configured so I fail to see what advantage would you have if you listen only on local ports. I do see a disadvantage for those who want to connect on those vty ports remotely (they would have to setup a password then remove -A options from conf files).
That is my point. If a user want to connect to the vty remotely using an insecure protocol that passes all of the information, including the password, via clear text, then that user should purposely configure the server to do that. Otherwise, we should have the default settings as secure as possible. It is still possible to connect to the vty remotely, but in a much more secure manner. Simply ssh to the host, then telnet to the vty running on the localhost. This gives the flexibility of remote administration with the security of an encrypted connection thanks to ssh. This is probably a personal preference item, however, I think that we should make the default settings secure. I may be a little bit biased on this particular package because the first time I ran this package was while using Debian. The default on Debian is to listen on the localhost only. Of course, I now use Gentoo on many more hosts than I run Debian. But the secure mindset still exists. Thoughts?
Just thought of this. Sorry for the double post. The creation of daemon specific files in the /etc/conf.d directory would also allow a user to pass other command line options to the daemon as it starts. As I am sure you already know, quagga and all of its support daemons have many options that can be set at the daemon start up, and by creating the /etc/conf.d files, it would be much easier for the user to specify those options, without having to edit the /etc/init.d scripts. Thoughts?
(In reply to comment #2) > That is my point. If a user want to connect to the vty remotely using an > insecure protocol that passes all of the information, including the password, > via clear text, then that user should purposely configure the server to do > that. Otherwise, we should have the default settings as secure as possible. Yes, and user expressed his/her preference when he/she set the password in zebra. What would be the point in setting up a password when you do not intend to connect to vty TCP ports remotely? > It is still possible to connect to the vty remotely, but in a much more secure > manner. Simply ssh to the host, then telnet to the vty running on the > localhost. This gives the flexibility of remote administration with the > security of an encrypted connection thanks to ssh. Why do you need telnet for that? Just use vtysh as root or as quagga user and you will connect through /var/run/quagga/zebra.vty Unix socket. > This is probably a personal preference item, however, I think that we should > make the default settings secure. The default settings are secure: - remote vty logging isn't allowed. - only root or quagga user could connect, through vtysh (In reply to comment #3) > The creation of daemon specific files in the /etc/conf.d directory would also > allow a user to pass other command line options to the daemon as it starts. Yes, but are they really useful? Excepting zebra daemon (which already have a conf.d file), I failed to see any useful command line option.
Fair enough. I will continue to tweak my setup as shown below, as this is my preference, but if this would not be a useful change to the package, then we can leave the package as it stands and mark this bug as closed. Looking at the man pages for the add-on daemons in the quagga package show that you are correct. There really aren't too many options right now that would justify the file in the /etc/conf.d directory. I am not sure if any options in the future would justify the conf.d file, but if they crop up, I am sure that we can adjust accordingly. Thanks for your input on this.
closing this as invalid. if you find a single useful bgpd/ospfd/ospf6d/ripd/ripngd command line option (other than -A, which we established it isn't that useful), let us know.
