From: "Mike Schmidt" Date: Mon, 7 Apr 1997 16:19:45 -0600 To: csac@ncar.ucar.edu Subject: Re: UDP services to consider Since there have been so many csac messages recently, I will attempt to respond to everyone's LDM questions in this one message. Let me know if I have misrepresented the context of your message with my hacking; DH> ... Mike, do you DH> know if the LDM also uses TCP to for this connection establishment? Setup of an LDM connection currently requires UDP, but an established connection uses TCP. The LDM can be run through a firewall by allowing port 388 TCP *and* UDP only. GW> 2) LDM, like any service which needs to be accessible to the outside world, GW> should be run on exposed hosts only. I disagree - if we allow DNS on non-exposed hosts, we have a precedent for allowing other UDP services. BIND has a hell of a lot more potential for security problems and it has the CERT, CIAC, ... advisories to prove it. Besides, some of the equipment that will be used to propagate the data won't need to be exposed for any other reason. This equipment might include networked real-time satellite receivers, ... GW> 4) It is conceivable that an LDM gatekeeper could be provided as an GW> alternative to running LDM on exposed hosts (my understanding is GW> that the design of the LDM lends itself to this). This is an option GW> to consider only if the workings of the LDM require security GW> standards that CSAC considers unacceptable. (I have grave doubts GW> about the security of giving the outside world access to RPC, for GW> instance, which has been mentioned in this discussion) In a sense, this is what we already have. Access to/from port 388 TCP/UDP from external hosts could be restricted significantly. As mentioned above, access to rpc's (ala portmapper) is not required. Enclosed for your reading pleasure is the official word on LDM and security from our director; |... Security has been an important consideration |in LDM design, and we have dealt with many of the associated issues, |including simple spoofing attacks and the use of LDM with firewalls. | |The ldm server normally uses a privileged, reserved port, which requires |that it run with "root" privilege while binding the service socket. The |code is designed so that root privilege is available to the process only |during the brief window of time when necessary. For sites that distrust |this, the server can be configured to run, WITHOUT special privilege, on |an unreserved port. The LDM server only writes to a single file, which |we recommend that users place in a volatile file system; the actual data |processing is done by separate programs which do not require any special |privileges. These security features are not accidents. | |Security conscious sites outside of UCAR have evaluated the LDM and |found it acceptable. The provider of our NIDS data, who sells and is |very jealous of these data, scrutinized the LDM design before agreeing |to our contract. The Battelle DOE lab audited the program before using |it to receive data. | |The consensus is that the primary vulnerability of LDM is to "denial of |service" attacks. Unauthorized sites can tie up the system by flooding |it with requests for service (which will be denied). Such sites might |also spoof the DNS to appear as authorized sites, permitting them to |acquire or to deliver phony data, perhaps in quantities that would flood |the system. This is really a DNS/TCPIP security problem, not an LDM |security problem. There are no known mechanisms by which the LDM |service can be used to gain unauthorized access to a system. | |Finally, the new administration tools that we are developing should |simplify LDM operation and reduce the likelihood of mis-configuration, |accidental or otherwise. | |In light of the above, I am not planning any additional security |measures beyond the following, ongoing practice: the LDM code is freely |available, and we invite study that exposes vulnerabilities, which we |subsequently correct. Please advise me if you think a different course |should be pursued. | |Best regards, |Dave LS> Moreover, it is my perception that this very type of service, if not this LS> specific one, is the reason for some groups wanting to be completely LS> outside of the security perimeter. No, not entirely, just another factor to consider. LS> I am hopeful that some may come back inside. I think it's reasonable to LS> bring up the discussion again regarding the requirements and how they can LS> be technically accomodated. I bet Mike has been continually reevaluating LS> this as our understanding and decisions progress. I'm not closed minded to the benefits that the security perimeter offers and I seriously think about the possibilities. We have a fair number of systems that could gain a lot of protection and make my life easier. Anyway, to wrap up with the information we agreed to gather -- a quick UDP survey reveals the following services traversing the boundary of our subnet(s) to what will be inside the security perimeter; NTP (we don't have to peer with migs and tijeras) RSTAT (should turn this off anyway) PORTMAP (LDM operations, workaround possible) RPC (LDM operations, workaround possible) SYSLOG (not required) DNS (required for tcpd lookups, anon ftp, ...) Other services mentioned that we use; OPSMON (not required) MULTICAST (LDM development, potential future use) With the exception of the LDM, none are required. mike