System and Network Security Practices COEN 351 E-Commerce Security

Security Practices Harden / Secure Install only minimal OS configurations Install patches Install most secure and up-to-date versions of system applications Remove all privileges and access rights, then grant back access only on an “as needed” base. This could conflict with repeating the previous step. Enable as much system logging as possible. For forensics purposes.

Security Practices Prepare Assume that there are vulnerabilities that are not yet recognized. Administrator needs to recognize when these vulnerabilities are being exploited. Administrator needs to know the baseline state. Hardening solves known problems, preparation solves unknown problems.

Security Practices Detect Respond (includes recovery) Improve: Improve the security process by: Holding post-mortem reviews. Update policies and procedures. Update tool configurations and add new tools. Collect measures of resources required to deal with intrusion and security business case information.

Securing Network Servers and User Workstations Security practices implementation in four areas: Planning and executing the deployment of computers. Configuring computers to help make them less vulnerable to attack. Maintaining the integrity of deployed computers. Improving user awareness of security issues.

Securing Network Servers and User Workstations Security can be improved in three major ways: Securing the configuration of each network server and workstation host. Host security is first line of defense against internal threats. Faster incident detection. Promotion of consistency.

Securing Network Servers and User Workstations Identify the purpose of each computer: Categories of information stored on computer. Categories of information processed on computer. Security requirements of that information. Network services provided by that computer. Security requirements of those services. Users / user groups that have access to the computer. Trust relationships between computers.

Securing Network Servers and User Workstations Identify network services that will be provided. General Rule of Thumb: Servers should be dedicated to a single purpose. Reduces likelihood of configuration errors. Eliminates unsafe interactions between different services. Limits effects of compromise. Identify network service software to be installed. Services bundled with OS might not be the most appropriate. Identify users Determine user privileges Plan authentication Determine access enforcement measures. Some assets might need to be protected with encryption.

Securing Network Servers and User Workstations Develop intrusion detection strategies. Document backup and recovery procedures Backup data needs to be validated because it could have suffered from an undetected intrusion. For web-servers, content is usually created elsewhere and then transferred to the web-server. Determine how network services will be maintained / restored after various kinds of failures. Develop and follow a documented procedure for installing an Operating System. Determine how computer will be connected to the network.

Securing Network Servers and User Workstations Identify the security concerns related to day-to-day administration. Servers and workstations are physically distant from the offices of administration. Protect information contained on hardware no longer in use. Keep computer deployment plan current.

Securing Public Web Servers Security objectives: To maintain the integrity of all information resident on the web-site. To prevent the use of the web-host as a staging area for intrusions. Into our own network. Into somebody else’s network.

Securing Public Web Servers Step 1: Install a secure server. Step 2: Configure web server software and underlying web server host OS. Step 3: Maintain the web server’s integrity.

Securing Public Web Servers Isolate the web server After compromise, the web server cannot be used to gain access to other internal hosts observe and capture network traffic between internal hosts Place the web server on an isolated subnet This allows better monitoring of network traffic. Makes attack detection easier. Use firewalls to restrict traffic Web server needs to accept traffic on port 80/tcp and possible to port 443/tcp (https). Web server does not need to initiate TCP connections. All UDP and ICMP traffic can be blocked. Possible exception: DNS traffic (port 53/udp) Only allow traffic from web-server to internal DNS server

Securing Public Web Servers Isolate the web server webserver internal network internet firewall public web traffic internal traffic

Securing Public Web Servers Place server hosts providing supporting services on another isolated subnet Web-site might use , directory (LDAP), database services. Place these servers on protected networks. Only allow service specific data to flow between web server and other service providers.

Securing Public Web Servers Isolate the web server webserver internal network internet firewall SQL serverfirewall Only SQL Protocol permitted

Securing Public Web Servers Disable Source Routing and IP Forwarding Source routing is not really needed, but can be exploited for man-in-the-middle attacks, IP spoofing in general and scanning. IP forwarding can be used for scanning and for IP spoofing.

Securing Public Web Servers Alternative Approaches Place web server on internal network and then: use smart hubs, switches to separate web server from internal traffic. or: encrypt all internal traffic. Use ISP to host web-server.

Securing Public Web Servers Placement policies: Public servers should be placed on subnets separate from external public networks and from your internal network. Servers providing supporting services for your public servers should be placed on subnets separate from external public networks, from your public servers, and from your internal networks. Routers and firewalls should be configured to restrict traffic between external public networks and your public servers, and between your public servers and internal networks. Routers and firewalls should be configured to restrict traffic between servers providing supporting services for your public server and external public networks, your public server, and your internal networks.

Securing Public Web Servers Configure the web server with appropriate object, device, and file access controls. Perspectives: How to limit the access to your web server software. How to apply access controls for: server log files system software and configuration files application software and configuration files password files …

Securing Public Web Servers Establish new user and group identities. Server might have to run originally with root privileges in order to connect to server 80. Server should not continue to run in this mode.

Securing Public Web Servers Identify the protection needed: Public web content can be read but not written by web service processes. Directories in which public content is stored cannot be written by web service processes. Public web content files can be written only by processes authorized for web server administration. Web server log files can be written by service processes, but log files cannot be read or served as web contents. Web server log files can be read only by administration processes. Any temporary files created by web service processes are restricted to a specified and appropriately protected subdirectory. Access to temporary files created by web service processes is limited to the service processes that created these files.

Securing Public Web Servers Mitigate the effect of DoS Attacks. DoS attacks can involve: Gobbling up all network connections so that no new users can gain access. Filling primary memory with unnecessary processes to slow down the system. Filling file systems with extraneous and incorrect information. The following mitigates these attacks: Network connection time-outs. Assign priorities to web service processes. Separate directories for log files from system directories and user information.

Securing Public Web Servers Protect sensitive and restricted information: Run web server in its own partition under Windows. Avoid links to files not belonging to the web server. In more detail: Define a single directory for web server content files (excluding cgi scripts). Define a single directory for all external programs executed as part of the web server content. Disable the execution of CGI scripts that are not exclusively under the control of administrative accounts. Disable the use of hard or symbolic links as ordinary files and directories. Define a complete web content access matrix. (Which pages are accessible by whom?)

Securing Public Web Servers Disable the serving of web server file directory listings

Securing Public Web Servers Enable Logging Transfer log (access log) Error log Agent log: user client software used in accessing your web content. Referrer log: collects information relevant to HTTP access, including the URL of the page containing the link that the user client software followed to initiate the access to your web-page.

Securing Public Web Servers Configure the web server to minimize the functionality of programs, scripts, and plug-ins. Verify that acquired copy of external program is authentic. Use an isolated test machine to test all acquired programs. Run vulnerability checking tools. Mitigate the risk of distributing malicious code. Disable Server Side Include Functionality In particular, disable the execution of external programs. Check default configuration: Disable example scripts and other instances where external programs get executed.

Securing Public Web Servers Use authentication and encryption technology Do not trust address-based authentication. Do not trust HTTP basic authentication.

Securing Public Web Servers Maintain authoritative copy of web site content on a secure host. Establish normal protection mechanisms for these contents. Establish procedures for web-site content transferal.