PhxBUG - Phoenix BSD User Group

Introduction

What is a honeypot?

In information security, any closely-monitored device or application designed with the purpose of drawing attacks. They typically have no production value; a honeypot that is successfully attacked and compromised results in no loss of critical services, and should disclose no important information to an attacker.

What is the purpose of a honeypot?

Honeypots have a number of uses:

• Distract attackers from truly valuable systems or applications on the network.
• Provide insight into attacker methodologies. In other words, a honeypot can serve to answer the question, "How can we defend against an enemy, when we don’ t even know who the enemy is?"
• Assist in development of IDS signatures and collection of malware, exploits, tools, etc.

Honeypot Flavors

The community breaks honeypots down into 2 main kinds.

• Low-interaction - Emulates services, applications, and operating system interfaces, presenting the illusion of a target system to an attacker while only exposing a pseudo service to them. Tend to be low risk, easy to deploy/maintain, but capture limited information. A honeypot software application such as honeyd is an example of a low-interaction honeypot.
• High-interaction (research) - Usually consist of real services, applications, and operating system installations. Designed to capture extensive information, but higher risk and high maintenance. A full-fledged Windows XP installation on a physical or virtual machine is an example of a high-interaction honeypot.

Honeynets

Information has different value to different organizations. Some organizations want to deploy honeypots to identify infected or compromised systems on their internal network. Others want to identify snooping employees, looking for data they shouldn't. Others, such as ISPs, want to identify both nefarious customer activity and see what threats target them from the Internet. The ability to gather information is critical, and a honeypot that doesn't help you get valuable information to suit your purposes is just a sacrificial box.

Another flavor of honeypot (or concept related to honeypots) are the high-interaction honeypot collections designed to capture in-depth information, referred to as honeynets. A honeynet is a honeypot architecture you populate with live systems, not a product or software. Any traffic entering or leaving the honeynet architecture is destined to one or more honeypots, never to legitimate systems, and is therefore always suspect.

As noted, the key value to a honeynet is in being an architecture, not a product. There are several aspects of the honeynet architecture that lend value to the framework and analysis capabilities it provides.

• Control - better grasp on controlling our ins and our outs (packet filtering, scrubbing, and traffic policies.)
• Transparency - utilize bridging for isolation, rather than routing; honeypots can blend in with other legitimate systems, utilizing contiguous address space.
• Analysis - information gathering is enhanced through formalized structures for logging, alerting, and analysis consoles.
• Flexibility - One strength of the honeynet architecture is that honeypots are up to the implementor. They can be high- or low-interaction, any quantity, any flavor, any patchlevel, any operating system, and present any services to attackers.

The Honeynet Project CDROM

http://www.honeynet.org/tools/cdrom/

The Honeynet Project produces a free Linux distribution for the purpose of creating honeynet architectures. Their CDROM is currently based off of Fedora Core 3 and provides the role of a honeywall in the architecture. The honeywall has (at least) 3 network interfaces; 2 interfaces configured in a bridge, giving an inlet and outlet into the honeynet architecture, and a third interface to function as a management interface (the only one that has IP connectivity for remote administration.)

The distribution neatly integrates several components to form the core network flow controls at the honeywall:

• iptables firewall to apply filtering policies
• snort_inline to provide IDS/IPS capabilities

The honeywall serves as the core analysis system in the honeynet, as well. The core analysis utility on the system is Walleye, a web-based analysis console.

In Walleye, you can:

• View and analyze IDS events
• Review network flow data
• View captured packet data

Since any network traffic seen on the honeynet is illegitimate, it is important to be able to account for the traffic and analyze it. Walleye makes it easy to do this.

Honeynets and BSD

If the Honeynet CDROM is Linux-based, what does any of this have to do with BSD?

Although the core component of the honeynet (the honeywall) is Linux-based, you can still play off of the strengths that BSD has in any environment.

• Highly secure
• Stable
• Infrequently targeted by common attack vectors

So this means that you can integrate one or more BSD systems into your honeynet architecture as honeypots which perform specialized tasks:

1. Make it a honeypot and a target for attackers.
2. Use it in an analysis role.

In the first point, you can approach using BSD as a honeypot in a number of ways. BSD can be used to host several of the low-interaction honeypots (such as honeyd), which means it fits neatly into the architecture.

As for the second point, there are many ways you can do this. One is to establish a system of network-based syslog services within the honeynet. All honeypot systems should have some native event or system logging function which logs to the local system. A common attempt to cover an attacker's tracks on a compromised system is to erase or alter the logs on the system. Although an attacker can cover their tracks locally on a compromised honeypot system, it can be made more difficult if those logs are also sent to a remote system too. Configure the honeypots to send syslog data to a hardened and well-maintained BSD syslog server.

Another function that your BSD boxes can perform in a honeypot analysis role is that of centralized host integrity checking. Using Osiris or similar host integrity checkers on the honeypots, we can monitor for unapproved changes to our honeypots; file additions, deletions and modifications; user and group modifications, changes in listening network ports and so on. Using a hardened BSD host to run the centralized osirismd console means that this information is communicated to and stored on a system where it can be preserved, even if the compromised system is destroyed.

Yet another capability of a BSD system in the honeynet is that of a central event processing and alerting function. Using a utility such as SEC or swatch to parse out syslog events received by the system and respond to them in an automated manner lends a sense of automation to the analysis process. Coupled with some custom scripts to handle things like sending email to the honeynet analyst and restoring system configurations to defaults can help provide useful capabilities to the honeynet architecture.

It should be noted that you will probably want to give this box a separate management interface from which to deliver SMTP alerts and perform other alerting. While network activity on the interface that connects to the honeynet architecture will be visible to an attacker who has a presence on that segment, using a different network interface on the BSD systems will allow you to perform network transactions unbeknownst to the attacker.

Finally, the uses of the BSD system in the honeynet architecture will in theory make it an attractive target to attackers on the honeynet. While they may be able to disable local logging, alerting, and security functions on the honeypot systems themselves, they will also likely notice that logs are sent to the BSD system and that Osiris scan results are sent to it. This fact alone may be enough to deter unskilled attackers from continuing their activities as there is obviously an audit trail that they won't be able to disrupt. On the other hand, it is likely that this will present a new challenge for more skilled attackers to take on:

• They can't wipe tracks without breaking into this box.
• They can't disrupt messaging/alerting without taking this box down.

The possibility then is that more talented attackers will now target the BSD system in an attempt to fully cover their tracks. At this point, you might be able to acquire some useful information about the attacker. If an attacker has a remote repository of tools and connects out to it through the firewall, you may be able to gather IP addresses, user names and passwords for the attacker's repositories. You may find information about 0-day exploits or tools you didn't know about. If you set the honeynet up in such a way that the BSD box is inaccessible from the Internet (via filtering policies on the honeywall), attackers will be forced to launch their attacks from a system on the inside of the honeywall, meaning you won't see the attacks happening at the honeywall but you are likely to see communications between the honeypot and the Internet. Let the attackers pound away at the system in futility; running an updated OpenBSD host in a hardened configuration should present a challenging target to even highly skilled attackers.

Sample scripts

The following list of files are examples of configurations and scripts that can be used for analysis and alerting on the BSD system.

SEC configuration

The following SEC configuration file can be used to monitor for file alteration events in the default IIS document root directory. This configuration is run against the syslog log file where messages from osirismd are stored.

## Look for modifications to files in the IIS web root on WebServer.
## If detected, send email alert to analyst.
type=Single
ptype=RegExp
pattern=osirismd\[\d+].*\[(WebServer)]\[(cmp|missing|new)].*\\\\wwwroot\\\\.*
desc=The following modification was detected on the host '$1' during a \
routine host integrity check. This suggests an unforeseen change to content \
in the IIS document root, possibly as an attempt to deface a web site.^M^M$0
action=shellcmd /root/response/mail_alert.sh ­-s "Possible defacement, WebServer \ 
honeypot" ­-t '<analyst@example.com>' ­-f '"Honeynet Alerts" \
<noreply@puffy.example.com>' ­-d "<poohbear@example.com>" ­-i %s

SMTP alert script (mail_alert.sh)

The following shell script is called by the above SEC configuration to email an alert to the configured analyst's email address.

#!/bin/sh
# Default envelope recipient
mailrcpt="<soc@example.com>"
# parse script arguments
while getopts "s:t:f:r:d:i:" optchar; do
    case $optchar in
        s)  hdr_subj="${OPTARG}" ;;
        t)  hdr_to="${OPTARG}" ;;
        f)  hdr_from="${OPTARG}" ;;
        r)  env_to="${OPTARG}" ;;
        d)  env_from="${OPTARG}" ;;
        i)  msg_input="${OPTARG}" ;;
    esac
done
shift $(($OPTIND -­ 1))

# If no envelope recipient received as argument, assume default
env_to=${env_to:­${mailrcpt}}
# parsed out information, mail it as instructed:
/usr/sbin/sendmail ­-f ${env_from} ${env_to} <<-­ EOF
    From: ${hdr_from}
    To: ${hdr_to}
    Subject: ${hdr_subj}

    Alert description:

    ${msg_input}
EOF

Honeypot security, legality, privacy issues

Beware of problems a compromised honeypot can bring. In order for the honeypot to be a believable target for attackers, you need some bait. However, don't use what you really don't want someone finding. Watch out for attacks against your organization's public image (e.g. http://www.zone-h.org/). As with any decision that has legal or liability considerations, check with your organization's legal department and applicable management before implementing honeypots. Critical departments in an organization should be aware of their installation and use as well (think IT networking and/or security.)

One of the most frequently asked legal questions is whether a honeypot violates the Wiretap Act. This question has been answered by the the United States Department of Justice, recognizing that a
honeypot can qualify under an Exception to Wiretap Act, the Provider Exception (System Protection) clause. (http://www.honeynet.org/papers/edu/).

The second legal concern frequently raised is the question of entrapment. Given that honeypots are
deployed on networks and no advertisement enticing people to scan and/or break into the honeynet, the case of entrapment has little merit.

A final administrative legal concern is the privacy of data on the network. Information such a credit card numbers, user IDs/passwords, social security numbers, and a myriad of other data could be captured by a honeypot. Proper handling of this data is very important.

Resources

The Honeynet Project

http://www.honeynet.org/

Paper: Use of a Honeynet to Detect Exploited Systems Across Large Enterprise Networks

http://www.tracking-hackers.com/papers/gatech-honeynet.pdf

SEC: Simple Event Correlator

http://www.estpak.ee/~risto/sec/

Osiris: Host Integrity Monitor

http://osiris.shmoo.com/

Introduction

This presentation is a follow-up to dwc's PF introduction and is part 2 of the PF presentation series. We continue to explore the PF packet filter in its use as a firewall on its native platform, OpenBSD. This presentation covers a subset of the features presented in the PF FAQ and the pf.conf(5) manual page. Refer to these resources for more information.

More about PF

In the introduction to PF, we were presented with some of the fundamental components of a PF firewall including basic and stateful packet filtering, NAT, port redirection, and AuthPF. This presentation covers some of these in more depth and introduces other features of PF.

Order of evaluation

An important concept to understand with any firewall implementation is the order of evaluation, or in other words the order in which rules in the ruleset take effect. PF uses a last match wins paradigm, meaning that the last matching filter rule a packet hits takes precedence. Note that this detail can be changed for increased flexibility by using the quick keyword and various state tracking options. It also means that a default filter policy can be established by placing a default rule at the top of the ruleset; assuming none of the following rules in the ruleset specifically match packets as they traverse the firewall, the "catch-all" rule will match. Here is an example:

---snip---
block all
pass in on $ext_if inet proto tcp to $web_server port 80 \
    flags S/SA keep state
pass out on $int_if inet proto tcp to $web_server port 80 \
    flags S/SA keep state
---snip---

In this example, all traffic is blocked at the firewall, both inbound and outbound, unless it matches the HTTP traffic which should be allowed in to the web server.

As mentioned, normal rule evaluation can be altered with the use of the quick keyword on a rule. A packet which matches a "quick" rule will not continue to be evaluated against the remaining rules in the ruleset; a match against a quick rule is immediately considered "last match". As an example:

---snip---
block all
pass in quick log on $ext_if inet proto tcp from 192.0.34.166 \
    to $web_server port 80 flags S/SA keep state
pass in on $ext_if inet proto tcp to $web_server port 80 \
    flags S/SA keep state
pass out on $int_if inet proto tcp to $web_server port 80 \
    flags S/SA keep state
---snip---

The use of the quick keyword in the first pass rule above makes sure that traffic from 192.0.34.166 is logged; without the quick option, evaluation would continue and the packet would match the following rule which does not log the connection.

It is also important to understand the order in which translation rules apply in the ruleset. In PF, translations occur before filtering. This is important to understand when building a ruleset that uses both filtering rules and NAT or RDR rules; since translation happens before filtering, filter rules will need to use the translated addresses and ports to match properly.

Block policy

Firewalls can block traffic in two main ways, and which one you use depends on your goals. The first and most common way is to have the firewall silently drop packets which are not allowed to pass through the packet filter. This has the effect of simply causing the traffic to be discarded and disappear into a black hole. When this occurs, delays in connection attempts result; for example, a client attempting to reach a web server behind a firewall which drops connection attempts will experience a delay of several seconds until which point the user is notified that the connection timed out. This block policy is generally considered "stealthy" and oftentimes hides the fact that a firewall even exists; most of the time, users just notice that their communication is blocked with no indication why.

The alternative policy is to use one of the return options which causes the firewall to communicate back to the client when its connection attempts are blocked. While this will typically give away the presence of the firewall, it results in immediate notification that communication has been denied and eliminates timeouts. In certain cases this can be desired. One example of such a case is when a service uses the ident facility to attempt to find out information about a connecting client. Two services that can utilize ident are IRC and SMTP. As an example, when clients attempt to connect to some IRC servers, the connection cannot be completed until the IRC server completes an ident lookup against the client. If the incoming ident lookup is dropped silently, the connecting client will notice a significant delay in the connection until the lookup times out. If a return option is used, the inbound ident lookup can be sent a RST packet, immediately terminating the lookup and allowing the client to connect immediately. Example:

---snip---
block all
block return in on $ext_if inet proto tcp to any port 113
pass out on $ext_if keep state
pass in on $int_if keep state
---snip---

In the above example, incoming ident lookups match the second rule, which will return an immediate RST to the IRC server.

Logging

The ability for a packet filter to perform logging is important for two reasons. It gives the firewall administrator a way to debug the ruleset evaluation, and it can give audit trails information about policy violations for network traffic. PF supports logging, using an innovative method of integrating tcpdump(8) into the logging system. As well, PF internal operations are logged via the kernel and can be captured in syslog.

To enable logging for a rule, you can simply enable the log keyword. Logging may be used on pass and block rules alike. In order for logging to be enabled, the pflog(4) interface must be active and to write logs out to disk, the pflogd(8) daemon must be running.

ext_if = sis0
bad_pub_ports = "{ ssh, telnet, exec, shell, www, https }"
block in log on $ext_if inet proto tcp from any to ($ext_if) \
    port $bad_pub_ports

The above example enables logging for any protocols defined in $bad_pub_ports that are seen incomign on sis0. If any packets match this rule, a log message is sent to the pflog(4) subsystem for handling.

Stateful options

The stateful filtering options in PF are among the most important that can be used. Stateful filtering refers to connection state, and relates to the ability of the packet filter to gain an understanding of traffic as part of related flows rather than individual packets on the wire. TCP is a stateful protocol by design and its connection-oriented design lends well to stateful filtering. Even for relatively "connectionless" protocols such as UDP and ICMP, PF is able to filter in such a way that takes advantage of implicit state-like aspects.

The advantages of stateful filtering are twofold. First, evaluating connection flows based on a state table allows PF to acheive higher performance than it would evaluating each rule in the ruleset sequentially for a match. Prior to evaluating the rules in the ruleset, PF will consult its state table to find out if the packet is part of an already established connection or authorized flow. The structure of the state table allows very rapid searching. Also, analyzing packets based on state gives PF the ability to apply more intelligent decision making to its filtering policy, since it can take into consideration more specific details of the traffic flow such as sequence numbers and flags set as part of the connection.

In relation to the state tracking options supported by PF, several keywords can be used on the filter rules that impact how PF impacts the state tracking engine.

• keep state: Appending this option to the end of a rule enables state tracking on this rule. All established traffic related to a matching rule which establishes connection state is implicitly passed as well. This option applies to TCP, UDP, and ICMP traffic alike.
• modulate state: The modulate option behaves as keep state, but also applies additional security to TCP connections which it matches by modulating or strengthening the ISNs (initial sequence numbers) as they pass through the filter. Note that this effect only applies to TCP traffic, but it will serve to function as a keep state option for UDP and ICMP traffic as well.
• synproxy state: The synproxy option results in PF stepping in to become the middle man in a TCP connection establishment. Normally a firewall will simply pass packets between a client and server to each other directly, assuming the ruleset permits it. The synproxy option enables PF to first complete a handshake with the client before involving the server, effectively protecting the network from spoofed TCP packets and SYN flood attacks. While synproxy doesn't work the same way for UDP and ICMP packets, it also has the same effect that both modulate state and keep state have.

Operating system fingerprinting

A fairly unique feature of PF is to be able to filter packets based on the operating system of traffic matched by filter rules. It is given this ability by the clever use of the p0f passive fingerprinting utility, and is useful for driving OS-based filtering policies. Example:

pass  out proto tcp from any os OpenBSD keep state
block out proto tcp from any os Windows
block out from any os "unknown"

Interface modifiers

There are a number of options that make writing portable rulesets easier in PF, such as macros and interface groups. Another useful feature is that of interface modifiers, which allow you to define interface-bound attributes for filter targets.

For example, specifying the :0 modifier after an interface name specifies the primary IP address of the interface, disregarding any IP aliases that are tied to it. (The default is to apply the filter to all IP addresses on the interface, including aliases). Another option is the :network modifier, which consults the interface's IP settings and represents the locally connected subnet of that interface. In this way, if the network address range used on that interface's segment ever changes, any references to the subnet will be automatically reflected in those rules. Example:

pass in on $int_if inet proto icmp from $int_if:network to \
    $int_if:0 icmp-type echoreq keep state

The above rule allows the subnet attached to $int_if to ping the inside interface of the firewall, but only the primary IP address of the interface (assuming there are also aliases configured). So if the IP address of $int_if is 10.0.1.1 and the subnet mask is 255.255.255.0, $int_if:network will really be 10.0.1.0/24.

Symbolic protocol names

PF is capable of reading symbolic protocol names from the file /etc/services in order to determine the port number. This can make the ruleset more understandable in cases where unfamiliar protocols are used in the ruleset. For example:

pass in on $int_if inet proto udp from $monitor to $int_if \
    port snmp keep state

The above rule uses the word snmp for the port, which is looked up to be port 161 in the services file.

Logging

The final item we cover in this presentation is how logging is handled on a PF firewall. We saw above how to enable logging for rules in the ruleset. Depending on the configuration you've enabled, logs can now be viewed in one of two locations.

• The pflog(4) interface: Packets logged by PF are sent to the the '''pflog''' interface. Invoking tcpdump(8) on this interface allows you to interactively view logged packets as PF proccesses them in real time.
• The pflogd(8) log file: If pflogd(8) is started, it will take logged packets from PF and write them out to a pcap-format log file on disk, which can then be inspected using tcpdump(8).

The most useful aspect of using tcpdump to view the log files is the flexibility it provides in filtering the logs for particular attributes. Tcpdump on OpenBSD has been modified to allow you to use any of the BPF style filter options such as source and destination address and port number, protocol types, and several other attributes that are PF-specific, such as:

• ip|ip6 - address family is IPv4 or IPv6.
• on|ifname int - packet passed through the interface int.
• ruleset name - the ruleset/anchor that the packet was matched in.
• rulenum num - the filter rule that the packet matched was rule number num.
• action act - the action taken on the packet. Possible actions are pass and block.
• reason res - the reason that action was taken. Possible reasons are match, bad-offset, fragment, short, normalize, memory, bad-timestamp, congestion, ip-option, proto-cksum, state-mismatch, state-insert, state-limit, src-limit, and synproxy.
• inbound|outbound - packet was inbound or outbound.

Using these filter options, flexible log analysis can occur. Here are some examples:

$ tcpdump -nettt -i pflog0
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG
Sep 29 10:10:14.504313 rule 16/(match) block in on sis1: 10.0.1.4.33855 > 10.0.1.1.80:
 [|tcp] (DF) [tos 0x10]

Above we attach tcpdump to the pflog0 device and see a blocked packet logged. The host 10.0.1.4 attempted to connect to 10.0.1.1 on port 80, and we see that the filter policy contains a block rule for this connection on line 16 of the ruleset.

$ tcpdump -nettt -r /var/log/pflog action block and dst port 80 \
  and dst host 10.0.1.1
tcpdump: WARNING: snaplen raised from 96 to 116
Sep 29 10:16:00.667286 rule 16/(match) block in on sis1: 10.0.1.4.33678 > 10.0.1.1.80:
 S 3907633761:3907633761(0) win 5840  (DF) [tos 0x10]
Sep 29 10:16:03.664758 rule 16/(match) block in on sis1: 10.0.1.4.33678 > 10.0.1.1.80:
 S 3907633761:3907633761(0) win 5840  (DF) [tos 0x10]

The above example reads from the log file on disk instead of interactively from the pflog0 device. It also uses a specific filter statement to find any packets blocked going to port 80 on the host 10.0.1.1. This query returns two logged packets which match those parameters.

Marco gave a great presentation on using Nagios and some other utilities for system monitoring in OpenBSD. One of the things he touched on was creating custom plugins for service checks. I thought I'd share an example of a plugin that I wrote for my email server to alert me of an out of date virus signature database.

Kerberos is a network authentication protocol designed at MIT in the mid-eighties.

The overall idea behind Kerberos is to introduce a trusted third party onto the network that can serve to provide trust between users, servers, and services without passing credentials and duplicating authentication on the network. It is also an effective way of protecting the network from the bad guys on the inside of the network. This trusted third party is the Kerberos server.

Kerberos was designed during a time when a lot of cleartext protocols were in wide use, such as Telnet, rlogin, rsh, and so on. These protocols typically passed login information over the network in such a way that unintended recipients of the information could intercept it. Despite the fact that today many of these protocols are replaced by SSH or protected using SSL, Kerberos is still a strong candidate for a network authentication solution because user account information for multiple systems can be centralized in one database.