-------------------------------- Use Case: Edge/Public-Facing Server --------------------------------- Version 0.1 (DRAFT) Last Modified Date: 8/11/05 Copyright (c) 2005 by The Open Source Development Lab, Inc. Verbatim copying and distribution of this document is permitted in any medium, provided this notice is preserved. Draft copies of this document may not be posted publicly without indicating the draft status. --------------------------------- Table of Contents --------------------------------- Description 1 Target Acceptance 2 Participants/Roles 2 Scenarios 3 Implementation Notes 4 References 4 --------------------------------- --------------------------------- Description --------------------------------- This use case describes what we call a “Edge Server” or “Public-Facing Server” found in a Data Center. The purpose of creating this description is so that the OSDL Security Special Interest Group (SIG) can use this description to evaluate the security needs for such a Server. The goal is to determine the operating system capabilities (the kernel and above) needed so that managers of these servers can create a secure environment. The assumptions need to be clearly defined to do that analysis. Once identified, the capabilities needed can be compared to what is available on any OS platform to identify possible gaps. This is one of a series of server usage profiles, which will be used to distinguish between security capabilities that are of general use, and those that have particular applicability to certain deployment scenarios. In particular, the environmental assumptions surrounding each scenario differ, and so the types of security capabilities each requires differ, too. Although the initial effort in creating server usage profiles is targeted at security, we intend this description to be good enough for other use cases to reference when they refer to server types, in this case“Edge Server”. In other words, we want the description to be useful for discussions beyond the topic of security. --------------------------------- Target Acceptance --------------------------------- This document is intended to help drive acceptance of any missing features into the mainline Linux kernel or any utilities that are impacted. Test cases for newly developed or modified features can be designed with this use case in mind. --------------------------------- Participants/Roles --------------------------------- --- * Systems Administrator * Operations Staff --- Special class of user that has special privileges on a given system. This is a role held by an individual that acts as the administrator for the system or by an individual that might have a specific role within the administration role, for example responsibility for system backup. --- * Application Administrator --- Special class of user that has special privileges for a given application. This is a role held by an individual that acts as the administrator for all aspects of an application. --- * User --- Any user on the system. This is a role that is held by all individuals using a system. The user can interact with the system through the processes associated with applications they are using. Root Users are users who have root privileges. They are typically the system administrator. Privileged users have some of the root user privileges, but not all. They are typically an operations staff member. --------------------------------- Scenarios --------------------------------- An edge, or public facing server performs many of the network guardian functions to limit methods of attack upon critical business systems. They'll typically be deployed in the data center, and be associated with a Firewall or Demilitarized Zone (DMZ) intended to isolate critical systems from pubic attack. Remote Access servers, modem pools and their associated terminal servers, Virtual Private Network (VPN) servers all fall into this category, as do public facing DNS, SMTP, and HTTP Proxy Portals. It is not unusual for such systems to: 1.demand authentication of requests before allowing access to the protected network, either from devices or from users of those devices, and 2.provide audit recordings for system administrators, 3.tally and record resource usage accounting records for system administrators or operations staff, and 4.provide access control policy enforcement based on the identity (either network address, user name, or other identifying information) associated with the connection. The typical security environment for an edge server is as follows: *Hostile attackers are expected and are likely frequent. *The system administrator implements the security policy for the system, the application administrator (if there are any on the server) will implement the security policy for applications. The policy will likely be part of a site-wide policy determined by one or more groups formed to apply corporate policy to a security policy, sometimes with people who do not have full grasp of the implications of their policy decisions. *There is usually very limited access by employees via login. In some provisioning models, there is no access, as the provisioning is automated, the server is removed if there are problems, and troubleshooting happens in an isolated lab. *Access by outside users is controlled by business units following authentication/authorization for pre-packaged roles only. These users are unlikely to get a shell prompts, but they use services (like web services) that require authentication/authorization. *Quite a few outside users access these systems, but a few to none will have administrative access to the system. *Separation of administrative duty is not necessary, excepting possible the audit administrative duty if the audit files are kept on the server. *Security auditing is important for (1) system and application/service login attempts, both successful and failed, (2) security changes made by the system administrator or application administrator, (3) anything else important to the site policy, (4) IDS style auditing of things like network traffic analysis, or binary/configuration file checksum intrusion detection (see [2] in References section).. *Retention on the server of sensitive information is unlikely, but flow through of sensitive information to other data center servers may happen. *Denial of service mitigation is expensive, so typically edge servers use primitive DoS blocking IP address, IP address blocking at the firewall, or throttling techniques. *Disaster continuance is covered by a geographically remote fail-over. Multiple edge-servers are usually configured in the event of failure of one. --------------------------------- Implementation Notes --------------------------------- There are currently no implementation notes for implementing security on Edge Servers. --------------------------------- References --------------------------------- [1] Security discussions can be found in the archives of the Security SIG: http://lists.osdl.org/pipermail/security_sig/ [2] Intrusion Detection Systems (IDS)on Linux Resources: http://www.linuxsecuritycentral.com/resources.php?title=Intrusion+Detection