Risk Management The Big Picture – Part III

Chia sẻ: Huy Hoang | Ngày: | Loại File: PDF | Số trang:43

Thêm vào BST

Báo xấu

107
lượt xem 12
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Host-based intrusion detection could also be called host-specific intrusion detection, in that its primary purpose is to detect suspicious activity or known attack patterns on the specific host it is installed on. Some host-based intrusion detection systems (HIDS) have a number of host detectors reporting to a central management console that can flag alerts, centralize logs, and update the host detectors’ policies. Other HIDS are stand-alone.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Risk Management The Big Picture – Part III

Risk Management The Big Picture – Part III Host-based Intrusion Detection Information Risk Management - SANS ©2001 1 Host-based intrusion detection could also be called host-specific intrusion detection, in that its primary purpose is to detect suspicious activity or known attack patterns on the specific host it is installed on. Some host-based intrusion detection systems (HIDS) have a number of host detectors reporting to a central management console that can flag alerts, centralize logs, and update the host detectors’ policies. Other HIDS are stand-alone. The boundaries between HIDS, anti-virus packages, and personal firewalls are blurring. 3-1
Need for Host-based ID • Very fast networks • Switched networks • Back doors in local network • Insider on network • Network-based IDS may miss attack • Don’t trust corporate security that much Information Risk Management - SANS ©2001 2 To cut straight to the chase, you can’t do a thorough job of detection or protection without software layers at the host. In the future, it may be possible for the network fabric itself to have a significant role in these capabilities, but it isn’t going to happen in the next six to twelve months. Speed and the visibility limitation of switched and encrypted networks are network intrusion detection systems’ biggest limitations. We’ll examine them in a bit more depth in the next two slides. Host-based intrusion detection can be very valuable in detecting back doors into your network, such as unsecured modems or links from other organization units or business partners. It’s no good relying on your network sensors that watch your front door if the back door is wide open. Another aspect of host-based intrusion detection is that it can catch insider attacks that don’t cross the network or don’t pass through the instrumented perimeter. Network-based systems can miss some sophisticated attacks - for example, fragrouter – that HIDS will detect. Finally, HIDS have a lower cost of entry down to the level of protecting a single person or home PC for $50, versus the $10,000 or so for commercial network intrusion detection systems (NIDS). They also do not require a dedicated machine. 3-2
Very Fast Networks • The current limits for network-based IDS boxes are about 80 MB/sec fully loaded • A 200 MHz Pentium bus would only partially increase this • Bandwidth at large sites will probably always exceed network detection and processing speed Information Risk Management - SANS ©2001 3 There will always be a finite limit to the speed a network-based intrusion detection system can operate, and it will always be possible to engineer a network that confounds network-based intrusion detection technology. Therefore, host-based ID will be an important player for the long haul. High bandwidth is a major challenge for NIDS. Be wary of taking that 80Mbps as a solid number, since it is based on assumptions of packet size and the number and complexity of the filters. Once a sensor’s bandwidth limit is exceeded, its performance tends to degrade rapidly, not just discarding excess packets, but thrashing from resource exhaustion. Graceful degradation into “statistical sampling” is desirable. A response to the bandwidth limits of network sensors is to move the sensors downtream towards the leaf nodes of your network, trading multiple sensors for less bandwidth per sensor. One can view HIDS as this trend is taken to its logical conclusion but beware that you have traded your bandwidth problem for a deployment problem. 3-3
Switched Networks • Network-based intrusion detection systems rely on promiscuous mode for their NICs; this is not possible with switched networks • Intrusion detection in the switch is the future direction, not really here yet • Host-based is one reasonable solution Information Risk Management - SANS ©2001 4 Promiscuous mode allows the network interface adapter to collect all the packets, not just the ones addressed to the machine. Until switched networks, this was a very efficient way to collect packets. A switch is a network device used to connect multiple hosts to a network segment. It only forwards packets to the specific port that belongs to each host on the switch. So, any given host on the switch ONLY sees traffic addressed to it. This makes using a sniffer or IDS much harder. While switched networks are seen as a win for security in terms of reducing the sniffer threat, they do greatly reduce the potential for “white hat” sniffing, that is, network intrusion detection. Be aware that switched networks do not entirely remove the sniffer threat, since there are techniques to kick a switch into broadcast mode or reroute data streams past the sniffer, for example dsniff’s arpredirect tool. 3-4
Switched Network In a switched network, a virtual circuit is created between two peers across the switch fabric. Each port on the switch only supports the circuits to that host. Information Risk Management - SANS ©2001 5 Because of the virtual circuit, a network-based IDS with a promiscuous interface will not detect much. Similar to switched networks in terms of the problems they cause for network intrusion detection are VPNs and other encrypted channels. In this case, the only possible place to put a sensor is at one end of the encrypted channel, that is a host-based solution (attackers use encrypted channels for precisely this reason, that is, to hide from network intrusion detection). 3-5
Spanning Port Switched Networks S Sensors can be placed on a spanning port, but can usually only monitor one VLAN at a time. This does not work very well in practice. Information Risk Management - SANS ©2001 6 Some switches have a "spanning port" which is a special port used for administration that generally receives all traffic transmitted on the switch. There are many problems with spanning ports as a solution to support network-based IDS. One major vendor’s switch will only span a single VLAN at a time. Spanning also may affect the performance of the switch. The other problem with using a spanning port is that frequent network changes can often disrupt spanning port settings. This would typically be caused by a network engineer being unaware of the spanning port’s purpose or the intrusion detection sensor’s presence. Of course, the first you know of the problem is when you notice that the sensor isn’t reporting any detects. This is a problem with many current intrusion detection systems, namely that they don’t see “no traffic” as an error condition worth reporting, but merely fail silently unless connectivity to the management station is lost. Switch vendors are becoming more aware of the requirements of intrusion detection and in some cases are building network intrusion detection capabilities into the switch itself. 3-6
Network Taps http://www.sans.org/newlook/resources/IDFAQ/switched.htm Information Risk Management - SANS ©2001 7 Another way to instrument switched networks is by using taps. These hook directly into the coax, twisted pair, or fiber optic cable and can send the signal to one or more points as shown in the slide. Since using a spanning port can increase the load on the switch, taps can be an excellent way to instrument the network. 3-7
Host-based Intrusion Detection Methodology • Host systems monitor their network connections and file system status. For this to work, we have to acquire the aggregate logs of ALL critical systems at a minimum • Local processing/alerting may be done, but data is generally sent to a central location for parsing • When potential problems are found, alerts are raised Information Risk Management - SANS ©2001 8 Deployment and the choice of which systems to monitor is the major decision in your host intrusion detection plan. Your core servers, perimeter servers, firewalls, web servers, DNS servers, and mail servers are the obvious first choice for deployment. While it would be desirable to roll out host intrusion detection to all systems throughout the organization, the costs are usually prohibitive for commercial intrusion detection systems. Typical costs range from $50 to $500 per host. This makes the tradeoff ratio around 20 to 200 host intrusion detection systems for the cost of a single network sensor. The other issue influencing the deployment decision is that the more frequently a host is reconfigured, the more false positives the intrusion detection system will generate. Unless configuration management is one of your tasks, you generally only want to monitor stable servers, not test or development systems that change frequently. 3-8
Host-based Intrusion Detection Methodology (2) A connects B logs 3 to B 2 connection Logserver records and informs 1 A -> B connection, Logserver checks ruleset, A-> B is OK, waits. Information Risk Management - SANS ©2001 9 It is a Good Idea™ to write (or copy) the logs on a different computer than the system creating them. This way, if that system falls, it is harder for the attacker to cover his tracks. In fact, this attribute of network intrusion detection is often cited as a selling point. This makes it harder for the attacker to tamper with the evidence of the attack (of course, Unix Syslog has been doing this for years). Central secure log servers and remote consoles are important features allowing widespread deployment while retaining central management capability. A sophisticated attack on a server defended by HIDS would involve a denial of service attack on the log server, so it’s worth considering having additional measures - such as a single network intrusion detection sensor watching your log server or having your security management servers behind an internal firewall. 3-9
Unix Host-based Intrusion Detection • TCP Wrappers • Port Sentry • Syslog • Tripwire Information Risk Management - SANS ©2001 10 OK, enough theory. Let’s look at some of the popular host-based intrusion detection tools. We first look at Unix tools, before checking out Windows. 3 - 10
TCP Wrappers • Where to get it – ftp://coast.cs.purdue.edu/pub/tools/unix/tcp_wrappers/ • What does it do? – Without TCP Wrappers Inetd.conf 21 TCP 21 ftp 23 telnet Information Risk Management - SANS ©2001 11 With TCP Wrappers you can monitor and filter incoming requests for the SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other network services. The package provides tiny daemon wrapper programs that can be installed without any changes to existing software or to existing configuration files. The wrappers report the name of the client host and of the requested service; the wrappers do not exchange information with the client or server applications, and impose no overhead on the actual conversation between the client and server applications. Wietse Venema’s TCP Wrappers, now in version 7.6, is a first line of defense. It is free and often included as part of more recent UNIX and Linux versions. Without TCP Wrappers, all incoming TCP requests are serviced without question. TCP Wrappers allows your system to be more selective about who connects to it and adds a very valuable logging service. Many personal firewalls currently on the market have identical functionality, though only ported to Windows. 3 - 11
TCP Wrappers • What does it do? – With TCP Wrappers Inetd.conf Log Access 21 TCP 21 ftpd Check ACL 23 telnetd Call daemon Information Risk Management - SANS ©2001 12 In this example, an FTP request (which is TCP port 21) comes to our system with host-based logging. TCP Wrappers first prepares to log that the packet arrived with a time stamp and the destination host. Then it checks its Access Control List, (ACL pronounced ACK ull), to see if it will allow the connection. If so, it wakes up the FTP daemon and lets it process the request. If the ACL doesn’t allow the connection (based on source IP), the connection is dropped and the event is logged. 3 - 12
Host Deny ALL:ALL # Deny everything, add back with /etc/hosts.allow Information Risk Management - SANS ©2001 13 This is TCP Wrappers’ default setting in the /etc/hosts.deny file, a suitably paranoid “deny everything not expressly permitted” (this is always a good starting point for a security policy). You specifically permit allowed services and trusted sources in the /etc/hosts.allow file. 3 - 13
Host Allow ALL:LOCAL, .nnnn.abc.org, 192.168.2, friend.somewhere.edu sshd: sometrustedhost.somewhere. org Information Risk Management - SANS ©2001 14 In this example, we are saying for ALL services, let nnnn.abc.org, 192.168.2, and friend.somewhere.edu have access. For the secure shell, we list a specific host that we trust. Notice that the hosts.allow file takes precedence over the hosts.deny. If hosts.deny has a deny everything policy, and hosts.allow has an allow everything policy, the system is wide open. Many security rule sets have these sort of counterintuitive “gotchas”. Remember, configuration errors are a leading cause of security breaches. 3 - 14
Brief DNS Review (TCP Wrappers Paranoid mode) gethostbyname: Has name, gets address $nslookup host.snorthcutt.com 192.186.21.2 gethostbyaddr: Has IP address, gets name $nslookup 192.186.21.2 host.snorthcutt.com Information Risk Management - SANS ©2001 15 The default for wrappers is to do both a forward and reverse lookup and if they do not match, not to allow the connection. We are often playing games with DNS and get burned by this several times a year, so it certainly works. This will pick up DNS transient attacks, like cache poisoning, but won’t detect a social engineering attack on a registrar who doesn’t correctly authenticate domain changes. 3 - 15
Paranoid Mode • Default for TCP Wrappers –Checks both forward and reverse lookup –Both answers must match or connection is dropped –Adds a layer of security against spoofing Information Risk Management - SANS ©2001 16 This certainly works because we play tricks with DNS in certain aspects of Shadow and we get burned by this all too often. Paranoid mode DNS checking is strongly recommended - although this will block sites that aren’t in the DNS, for example corporate firewalls, so YMMV*. *Your Mileage May Vary. 3 - 16
TCP Wrappers (How it aids in intrusion prevention and detection) A Incoming FTP Check ACL Inetd.conf Attacker Not Allowed 21 ftpd Drop Connection 23 telnetd Log Refused Attempt Information Risk Management - SANS ©2001 17 In this example, the attacker does not match an ALLOW (and everything matches DENY ALL :ALL), so the connection is dropped and the attempt logged. The TCP Wrappers ACL can have different allowed and denied addresses for each service (FTP, Telnet, etc.) or it can have generic permissions for all services. 3 - 17
Psionic Port Sentry (TCP Wrappers with an attitude) • Runs on TCP and UDP • Stealth scan detection for Linux • SYN/half-open, FIN, NULL, X-MAS and oddball packet stealth scans. • PortSentry will react to a port scan attempt by blocking the host in real-time. • Will remember hosts that connected previously. http://www.psionic.com/abacus/portsentry Information Risk Management - SANS ©2001 18 From the SANS Securing Linux Step-by-step consensus project: [Bill Lavalette] “ *** Psionic Port Sentry: is by far one of the best intrusion detection mechanisms. Port sentry automatically detects all types of port scans, from basic to stealth, dumping the hostile host into host deny. It can also redirect the host to limbo, a bogus route is added and if you’re using a Linux firewall actively add firewall rules regarding the hostile host. Gentlepeople, I swear by three things: TCP Wrappers, Port Sentry, and common sense. We have had a Linux 5.2 box with everything from a "nukes, land teardrop, boink, etc. to nmap scans to exploits”. Basically, as soon as an unauthorized host tries anything, it is automatically put into host deny, I am mailed with the event, and a log entry is generated. This is a very simple program to install; when combined with the above precautions, it would be extremely hard to beat.” Xmas scans are scans by packets with six TCP flags set, that is URG, ACK, PSH, RST, SYN, and FIN. Null packets have no flags set. All of these odd packets attempt to be stealthy by being rejected by the TCP/IP stack instead of being logged. Even if they are dropped, they will cause ICMP port or service unavailable messages. 3 - 18
Psionic Port Sentry Jul 3 11:30:20 shepherd portsentry[418]: attackalert: SYN/Normal scan from host: node10453.a2000.nl/24.132.4.83 to TCP port: 143 Jul 3 11:30:20 shepherd portsentry[418]: attackalert: Host 24.132.4.83 has been blocked via wrappers with string: "ALL: 24.132.4.83" Jul 3 11:30:20 shepherd portsentry[418]: attackalert: Host 24.132.4.83 has been blocked via dropped route using command: "/sbin/route add –host 24.132.4.83 gw 333.444.555.666" Information Risk Management - SANS ©2001 19 Psionic Port Sentry combines host intrusion detection with automated response. The first log entry shows Port Sentry detecting an IMAP scan. The second entry shows it adding a “deny all” rule for all traffic from that address. In the last log entry, it “blackholes” that address by insuring the system has no route back to the offending address by setting a bogus route. This won’t stop incoming packets from the offending address, but it will prevent any replies ever getting back. These sorts of automated responses should be used with care to prevent an attacker tricking the system into a self-inflicted denial of service on important connections. An attacker could do this by spoofing the source addresses of hostile probes to match the addresses of trusted partner sites. 3 - 19
Syslog • TCP Wrappers logs to Syslog by default • Unix system logger can be on a local system or other system • Swatch or other tools can monitor syslog and raise alerts Information Risk Management - SANS ©2001 20 Syslog is the original distributed logging system found on all Unixes. By itself it can detect a lot of suspicious behavior if correctly configured. There are lots of tools to help monitor logs and fire off alerts when selected events occur or thresholds are exceeded. Unfortunately, the completeness of the logs can be suspect, as attackers’ rootkits have specific tools to selectively clear them, or Trojan versions of Syslog that turn a blind eye to the attacker’s activity. This is a major reason for logging to a different machine. Even if all logs are suspect after the rootkit install, the remote logserver should hold the original logs of the intrusion, at least until the attacker comes after your logserver. 3 - 20