Xem mẫu
- 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
nguon tai.lieu . vn
