RE: [suse-security] scans to port 111
There are numerous vulnerabilities in rpc services and demons, such as snmpXmid, rpc.statd and wu-ftpd, buffer overflows in various services, and so on. Look at Cert's collection of the current cracker/kiddie activity on http://www.cert.org/current/current_activity.html#scans . And keep your system free of rpc.
Let's say I have a home network of 3 computers, which share disks with NFS. What's the risk if all NFS-related ports are blocked on the firewall to the outside? There doesn't seem to be much of an alternative to NFS, or is it unreasonable to assume the internal net is trustworthy? Volker
I would not worry about running nfs on a local lan, provided all nfs and rpc related ports are blocked on the firewall (and dont make your firewall and nfs server - I know people that have). On Fri, 13 Jul 2001, Volker Kuhlmann wrote:
There are numerous vulnerabilities in rpc services and demons, such as snmpXmid, rpc.statd and wu-ftpd, buffer overflows in various services, and so on. Look at Cert's collection of the current cracker/kiddie activity on http://www.cert.org/current/current_activity.html#scans . And keep your system free of rpc.
Let's say I have a home network of 3 computers, which share disks with NFS. What's the risk if all NFS-related ports are blocked on the firewall to the outside?
There doesn't seem to be much of an alternative to NFS, or is it unreasonable to assume the internal net is trustworthy?
Volker
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Chad Whitten Network/Systems Administrator Nexband Communications chadwick@nexband.com
Hi, maybe you should also have a look at ftp://ftp.porcupine.org/pub/security/index.html, there is an RPC daemon which supports ACL's, it's for Solaris, but maybe it also run's out of the box on Linux Volker Kuhlmann wrote:
There are numerous vulnerabilities in rpc services and demons, such as snmpXmid, rpc.statd and wu-ftpd, buffer overflows in various services, and so on. Look at Cert's collection of the current cracker/kiddie activity on http://www.cert.org/current/current_activity.html#scans . And keep your system free of rpc.
Let's say I have a home network of 3 computers, which share disks with NFS. What's the risk if all NFS-related ports are blocked on the firewall to the outside?
There doesn't seem to be much of an alternative to NFS, or is it unreasonable to assume the internal net is trustworthy?
Volker
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
On 12-Jul-01 Volker Kuhlmann wrote:
There are numerous vulnerabilities in rpc services and demons, such as snmpXmid, rpc.statd and wu-ftpd, buffer overflows in various services, and so on. Look at Cert's collection of the current cracker/kiddie activity on http://www.cert.org/current/current_activity.html#scans . And keep your system free of rpc.
Let's say I have a home network of 3 computers, which share disks with NFS. What's the risk if all NFS-related ports are blocked on the firewall to the outside?
Assume some local configuration errors on your firewall and/or buggy system demons which may be used to gain r00t on it, and a local network behind this faulty machine where anything goes NFSwise because of the assumption that, because the number of nodes in your LAN is very small, you trust your users more than you would if you'd run a net of 100+ nodes. So there we have all these NFS shares, lingering around w/o protection in the internal LAN, and a cracker who just entered your vulnerable firewall...
There doesn't seem to be much of an alternative to NFS, or is it unreasonable to assume the internal net is trustworthy?
To add some statistical data here, 55% of all problems related to computer fraud, cracking/hacking or simply power problems are caused by human error, followed by physical security problems (20%) and dishonest/disgruntled employees/users (9 - 10%) (Source: Computer Security Institute, O'Reilly 2000). This, added to my personal experience regarding attacks from "trusted" users, is reason enough to protect valuable ressources from internal users as well, because they're already within the security perimeter and could cause more trouble (deliberately or not) than anyone coming from outside in the first place. I'm still waiting for a *stable* AFS server to be released for Linux, as this seems to be a promising alternative to nfs. Take a look at http://www.stacken.htk.se/project/arla/ and http://www.helpdesk.umd.edu/linux/afs/faq.shtml .
Volker
-- [...]
---
Boris Lorenz
Let's say I have a home network of 3 computers, which share disks with NFS. What's the risk if all NFS-related ports are blocked on the firewall to the outside?
Assume some local configuration errors on your firewall and/or buggy system demons which may be used to gain r00t on it, and a local network behind this faulty machine where anything goes NFSwise because of the assumption that, because the number of nodes in your LAN is very small, you trust your users more than you would if you'd run a net of 100+ nodes. So there we have all these NFS shares, lingering around w/o protection in the internal LAN, and a cracker who just entered your vulnerable firewall...
So presumably you ensure general NFS access is root_squashed and that any NFS mounts are explicitely noaccessed from the firewall. Is there anything else you could do to reduce the risk? Apart from not running any services on the firewall and setting it up right ;0). JB -- John Bland M.Phys (Hons) AMInstP / \ PhD Student & Sys Admin Email: j.bland at cmp.liv.ac.uk / \ Condensed Matter Group http://ringtail.cmp.liv.ac.uk/ / \ Liverpool University "Hey, I wonder how much meat you get on a womble?" -- Eddie
participants (5)
-
Boris Lorenz -
dog＠intop.net -
Gerd Bitzer -
John Bland -
Volker Kuhlmann