On Tue, Mar 30, 2004 at 12:46:54PM +0200, Alexander Schmehl wrote: > The new sarge install on my workstation (choosed tasks to install: > »Desktop environment« and »Office environment«), portmap and nfs-common > (and some other stuff, I sure I won't need, thats the bad thing about > the tasks). Thanks for this information. > An »nmap -sV« shows me this: ¿How about an 'lsof -ni' run in the system (as root)? Ok. Let's find the culprits. > PORT STATE SERVICE VERSION > 9/tcp open discard? > 13/tcp open daytime Those two are default in netkit-inetd. IMHO they are not really needed, but don't pose a huge risk [1] > 22/tcp open ssh OpenSSH 3.8p1 (protocol 2.0) Ssh is 'standard' priority. It is good to have it installed when a user only want's a Desktop? Risk could be mitigated if access to it was correctly restricted through tcp-wrappers. > 37/tcp open time That's provided by netkit-inetd. Again, not really useful for a Desktop-Office environment but doesn't pose much risk [1] > 111/tcp open rpcbind 2 (rpc #100000) That's portmap. Again 'standard' priority. And useless in a Desktop-Office environment unless you use RPC services (which you don't seem to) > 113/tcp open ident OpenBSD identd That's probably open because of 'pidentd'. Standard priority, but shouldn't be there. > 515/tcp open printer BSD/Linux lpd (access denied) That's 'lpr', again, standard priority. I would rather have it configured to _not_ listen on the tcp port, or, at least, access to it should be limited through tcp-wrappers. It could be replaced with other printer daemons that don't do TCP but are as useful in Desktop-Office environments [2] > 835/tcp open status 1 (rpc #100024) That's probably rpc.mountd? (nfs-common, 'standard' priority). I could make a gross estimate of risk-assesment based on the DSAs we have published since 1997: - openssh: 10 DSAs (19981210, 19991215a, 20001118, dsa-025, dsa-027, dsa-086, dsa-091, dsa-119, dsa-134 and dsa-382) - lpr: 4 DSAs (19980828a, 19991030, 20000109 and dsa-267) - nfs-common: 1 DSA (20000719a) OpenSSH's bugs are remote root in many cases, lpr's are usually local vulns (there is one remote buffer overflow) and nfs-common's was a buffer overflow. Of course, I'm omitting the security vulnerabilities these had which didn't affect our stable releases (openssh's security bugs would be higher). Based on this info I still advocate for implementing/fixing #62145, openssh, lpr, portmap and nfs-common all use tcp-wrappers (though libwrap) Either that or find a way to avoid having openssh/lpr/portmap/nfs-common installed in the environment Alexander describes. Only lpr is needed in that environment and it still could be replaced with other non-network aware printer package or configured to only listen on the loopback interface. Or do we have to be hit by a worm targeted to our stable release in order to get this done? [3] Can't we learn from past mistakes? [4] > May I help you in an other way, before I start configuring that machine > to my needs? Thanks a lot for the info. Javier [1] At least _known_ risk, besides the fact that they can be used to fingerprint the system. [2] Cups? It has been more vulnerable to remote attacks than lpr in the past. PDQ was available in stable but is not available any more (why?) Please send patches if you think you can improve this: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s5.5 [3] Hint: Red Hat added firewalling configuration in the default installation in the next release after the Ramen/Lion worm propagated in the default installation of RedHat 6.0-6.2 [4] Hint: The Ramen/Lion worm exploited a number of services available in the default installation of RedHat 6.0-6.2, namely: CVE-2000-0573 (wu-ftpd), CVE-2000-0666 (rpc.statd) and CVE-2000-0917 (lprng), the worm appeared (on average) 161 days after the patches for these were available. The only one we (thank god) don't provide is wu-ftpd, but think openssh =~ wu-ftpd
Attachment:
signature.asc
Description: Digital signature