KFSensor

		Chapter 8 - Other Windows-Based Honeypots Honeypots for Windows by Roger A. Grimes Apress 2005

KeyFocus Ltd.’s KFSensor (http://www.keyfocus.net) is my favorite commercial Windows honeypot, but at $990, it is also the most expensive Windows honeypot reviewed in this chapter. If you’re looking for a Windows mid-level interaction honeypot, with a GUI-based setup, small resource footprint, and enough Windows services emulated out of the box to make it seem like a real Windows server, then it’s easily worth the cost. You can download the single executable and have it installed in under 15 minutes. First released in January 2003, each incremental release has brought more emulated services and features. I reviewed version 2.2.1 for this chapter. You can download KFSensor for a free trial from http://www.keyfocus.net/kfsensor/download.

KFSensor can be deployed on any Windows computer running Windows 2000 or above. The host machine does not need to be dedicated, but if you are running production services that conflict with KFSensor’s emulated ports, KFSensor’s duplicated ports will not be active. For example, if your host machine has NetBIOS or NetBIOS over TCP/IP enabled, as most Windows machines do, KFSensor will not be able to emulate ports 137, 138, 139, and 445. If you have IIS installed and are using port 80, you’ll need to stop IIS in order to let KFSensor monitor and respond on that port.

Tip 

In order to let KFSensor use the NetBIOS and SMB ports, disable NetBIOS over TCP/IP (located under Network Configurations) and disable the Server service (under Services).

Much as I like KFSensor, it has a few disadvantages, mostly because it is an application-level honeypot and does not work at the IP stack level. If a hacker pings or fingerprints a KFSensor honeypot, she will be identifying your honeypot host, not KFSensor. This is an important point, because if you install it on a Windows XP computer, and the hacker is able to fingerprint the host, it might be strange to find that it is also running IIS 6.0 and Exchange Server. KFSensor also contains a fair amount of small bugs, most of which are only inconvenient nuisances, but this is the case with all the honeypot emulation products.

KFSensor can run only one emulated honeypot per machine, and there is no way to tell KFSensor to automatically respond to all open port requests. If you wanted to use KFSensor to warn you about a port scan, you would probably need to manually add a bunch of ports in order for it to be accurate. Even then, KeyFocus doesn’t recommend using more than 256 listeners. (To be fair, this might be a problem with any application-level honeypot, but I haven’t stress-tested any of the solutions.) In contrast, because Honeyd has its own IP stack and has no GUI overhead, it can easily support thousands of ports.

A big advantage of KFSensor over other honeypots described in this chapter is the attention given to it by its author. Many honeypot software programs are languishing from neglect. Some haven’t been updated in years. KFSensor is routinely updated and bug-fixed. KFSensor version 3.0 is now in beta test. The big new feature is the ability to manage multiple remote KFSensor installations from a single machine. This allows you to view the logs from all the KFSensor sensors together and to reconfigure the honeypot remotely.

Installing and Running KFSensor

KFSensor installation is quick and easy. The binaries are installed to C:\Program Files\Keyfocus\KFSensor, and the log files are placed in C:\KFSensor\logs. KFSensor places itself in the HK_LM\SOFTWARE\Microsoft\Windows\Run Registry key, so that it automatically loads the next time Windows starts (this can easily be turned off). After you install it and reboot your computer, KFSensor automatically displays the help file and starts a setup wizard. I recommend that first-time users read and print all three manuals included in the help file as a handy reference.

KFSensor comes with two main binaries:

• KFSensor Server (kfsnserv.exe): This is the core executable, capable of listening on both TCP and UDP ports. It interacts with visitors (that is, hackers) and generates events. It can be installed to run as a service. KFSensor’s context help instructions, which are some of the best I have ever seen, will tell you how to accomplish this and how to harden KFSensor’s service account.

• KFSensor Monitor (kfsensmonitor.exe): This is the user interface to the sensor program, and it runs under the local logged-in user’s security context. The KFSensor monitor and server communicate with each other using sockets on the admin port, which is 9747 by default and can easily be changed. This port will show up in a netstat –an listing, but you’ll know it’s harmless because both the source and destination IP addresses are the local machine’s.

During installation, KFSensor will ask you to choose which components (such as listener ports) it should install by default, as shown in Figure 8-6. You can choose NetBIOS/NBT/SMB, Nonstandard Services, Simple Services, Standard Services, Trojans, and Universal Plug and Play. Unfortunately, in a rare help file weakness, KFSensor does not tell you which ports each component covers. See Chapter 3 of this book for that information.

Figure 8-6: KFSensor’s Setup Wizard components (port listeners) selection

Configuration and future changes are made easier if you choose all components during the initial installation. After the port listeners are created, you can still determine which of them to make active and which should be inactive. With everything selected, 58 TCP and 18 UDP ports are installed. The ports are a collection of very popular Unix TCP/IP ports (Character Generator, Daytime, SSH, and so on), ports common to most TCP/IP Servers (FTP, SMTP, DNS, telnet, and HTTP), common Windows ports (NetBIOS, Terminal Server, SQL Server, SMB, and Universal Plug and Play), and even PC Anywhere’s default Internet ports. The trojan ports are a dozen or so common malware ports, including Back Orifice, Kuang, and SubSeven. You’ll also be asked to put in a real or fake domain name. What you input here will be used in many of the emulated services presented to the hackers.

KFSensor installs a new system tray (systray) icon in the shape of a siren on the desktop. You click the siren icon to launch the KFSensor monitor, and it is used liberally throughout the program to indicate KFSensor’s current status. On the desktop, it will usually be gray, but it will flash red or yellow, based on event activity. The systray icon will flash until you view the KFSensor monitor, although its behavior can be customized. Low-priority events are just logged, and no alert is generated. Medium-priority events alert and make the systray icon flash yellow and orange. High-priority events alert and make the systray icon flash red and orange.

When the KFSensor monitor opens, it defaults to its Ports view, as shown in Figure 8-7. In this view, a siren icon appears next to each configured listener service. The icons are different colors based on current status: gray when KFSensor service is turned off, green when active and without any medium-priority or high-priority alerts, blue if there is a loading error, or red or yellow for an alert. Very recent alerts (as defined by the user) are red; recent events are yellow. Figure 8-7 shows errors on NetBIOS, FTP, and HTTP because of already existing services running on the Windows host.

Figure 8-7: KFSensor monitor in Ports view

The monitoring screen also has Visitors view, which sorts the different visits by the IP address and domain name. It obtains this information by doing a reverse lookup on the visitor’s IP address. This active fingerprint step should not be noticed by hackers in most cases, but it could if the hackers were running their own DNS server and monitoring queries. It would be nice if this feature could be turned off.

Emulating Services with KFSensor

Each port in the Port view represents a listener. Listeners are attached to actions. Actions can be close, close and read, or call up a simulated server. The close action will immediately close the connection and log the event. Read and close will wait for the visitor to send a request, and then close the connection without sending a response. A listener can also be attached to a server action.

KFSensor calls emulated services sim servers, short for simulated servers. A single instance of KFSensor can have an unlimited number of sim servers defined, although only 256 can be active at once. KFSensor has two types of sim servers: sim banner and sim standard. Some services, like FTP and SMTP, exist as both sim banner servers and sim standard servers, and listen on TCP or UDP ports, depending on the requirements of the environment.

Sim Banner Servers

Sim banner servers are simple port listeners with the ability to serve up text or encoded data as a banner in response to a visitor request. Each sim banner server can be edited, and new banner sim servers can be added.

The default sim banner servers include Echo (7), Daytime (13), Quote of the Day (17), Chargen (19), MyDoom worm (3127), Dameware (6129), and the SubSeven trojan (54283). Default text is provided for many of the services, or you can edit or customize your own messages, as shown in Figure 8-8.

Figure 8-8: KFSensor’s Edit Sim Banner dialog box

You can give a sim banner server a few more instructions on how to respond to a TCP request, using the following settings:

• Time out: The time in milliseconds that the KFSensor server will wait for the client to send data before closing the connection.

• Must Have Input: If checked, the client must send information to the server for the banner to be sent. This condition will have an effect only if the Read Before Banner option is checked.

• Read Before Banner: If checked, the KFSensor server will wait for the client to send data before sending the banner; otherwise, it will send the banner immediately.

• Read After Banner: If checked, the KFSensor server will wait for the client to send data after sending the banner; otherwise, it will close the connection immediately after sending the banner.

Banner text can include parameter variables to make the reply dynamic, mimicking real-life responses. The different parameters are listed in Table 8-2.

Table 8-2: KFSensor Sim Banner Server Banner Parameters

Parameter	Description
New Line	A carriage return/line feed pair
HTTP Time Stamp	Current time in GMT format, as used by HTTP servers
HTTP Offset Time Stamp	Current local time, followed by the offset from GMT
DayTime Time Stamp	Current time in the format hh:mm:ss dd/mm/yyyy
32 bit Time Stamp	Current time in seconds
Echo Received	A copy of the data sent to the server by the client
Server Domain Name	The server’s domain name
Server IP	Destination IP address
Server Port	Destination port number
Client IP	Client IP address
Source IP	Source IP address
Client Port	Source port number

Sim Standard Servers

Sim standard servers entail a higher level of interaction than a mere one-time banner response. KFSensor currently comes with the following emulated services:

• FTP (Guild, not Microsoft, on port 21)

• Telnet (port 23)

• SMTP (Microsoft Exchange Server 2003 on port 25)

• HTTP (IIS 6.0 and Apache on ports 80, 81, 82, and 83)

• POP3 (Exchange Server on port 110)

• NetBIOS (ports 137, 138, 139, and 445)

• SOCKS Proxy (port 1080)

• Microsoft SQL Server (ports 1433 and 1434)

• SubSeven trojan (ports 2794, 7215, and 27374)

• Hogle SMTP trojan (port 3355)

• Terminal Server (port 3389)

• HTTP Proxy (port 8080)

• VNC (port 5900)

Note 

KFSensor has two installation versions: Full Functionality and High Integrity. High Integrity will not allow you to enable HTTP, SMTP, or sim servers that relay traffic to other legitimate servers.

Servers are bound to TCP or UDP ports. Listener ports are collected into groupings called scenarios. You can create different scenarios that relate to particular types of computer roles. For instance, one scenario may mimic a Windows NT 4 box running IIS and Exchange Server. Another may mimic a Windows XP Professional workstation running NetBIOS and Universal Plug and Play. Only one scenario can be active at a time, but a simple menu command allows you to switch between scenarios. This also means that KFSensor can run only one honeypot per host computer. To review, listeners are bound to ports and protocols, which are in turn bound to actions. Actions can be bound to servers, and listeners are grouped into scenarios. It’s a little perplexing until you get the hang of it, but it seems natural after a few setups.

KFSensor has the best default Windows service emulation out of the box of any Windows honeypot. The sim standard servers that are particularly notable are IIS, FTP, Exchange Server, NetBIOS, and an antispam open proxy.

IIS Sim Server

KFSensor’s HTTP sim server takes great pains to emulate an IIS 6.0 server, even mimicking IIS’s inconsistent error messages and header responses. The IIS emulated HTML files are stored in C:\Program Files\KeyFocus\KFSensor\files\iis\wwwroot. As with IIS, \wwwroot is the virtual root of the server. By default, when a visitor connects to the service, it displays an error page similar to the error page you would get when connecting to a real unconfigured IIS 6.0 server, as shown in Figure 8-9.

Figure 8-9: KFSensor emulated IIS 6.0 Under Construction error page

You can modify the source files, and even host a legitimate-looking web site. KeyFocus’s HTTP engine runs as a stand-alone freeware web server (http://www.keyfocus.net/kfws) that is capable of sustaining 500 visitors at one time.

Like most honeypot emulated services, the IIS sim server doesn’t support anything beyond the basics. It doesn’t support ISAPI filters, directory browsing, write permissions, CGI scripting, or HTTP keep-alives. Of course, this same basic functionality also makes it resistant to buffer overflow, Unicode, and directory transversal attacks. The honeypot can avoid being compromised by hackers, while at the same time recording those same types of attempts.

FTP Sim Server

The FTP sim standard server mimics some of the basic functionality of Guild’s FTP Server (http://www.guildftpd.com). This could be a concern because a hacker might wonder why you are running an external FTP server when IIS 6.0 comes with one. It might lead a knowing hacker into concluding that you’re running KFSensor and not a legitimate Windows computer. KeyFocus acknowledges this by also including a basic FTP sim banner server that mimics IIS’s FTP server.

When you connect to the FTP sim standard server, KFSensor displays the domain name you typed during setup. The FTP service has the following behavior:

• It accepts any login name as valid, but allows only the anonymous login (with any password) to be completely successful.

• Requests to PUT or GET a file will be met with “invalid permission” or “file not found” messages.

• Running an LS or a DIR listing will result in a hung directory listing, as shown in Figure 8-10.

  
  Figure 8-10: FTP client screen when attaching to KFSensor’s emulated FTP server

• Trying to change directories with the CD command will result in “permission denied” messages, except to the root.

• If you don’t hang the session by using LS or DIR, the server will let you gracefully exit when you type the BYE command.

The captured information from the FTP session is saved to an Events Details screen. The information sent to and from the remote client is recorded. Figure 8-11 shows the remote hacker trying a login name combination of administrator and password.

Figure 8-11: KFSensor’s Event Details screen for an FTP session

Exchange Sim Server

KFSensor’s SMTP sim standard server emulates Exchange Server 2003 by correctly displaying the ESMTP 6.0.2600 version number during connections, as shown in Figure 8-12. You can modify that version number if you wish to emulate different Exchange Server versions. Unlike most emulation services, this one really works! If you turn on relaying, it functions as a real SMTP server with an open relay, and will forward incoming e-mail.

Figure 8-12: Example of KFSensor’s SMTP sim standard server

NetBIOS Sim Server

KFSensor is one of the few Windows honeypots with NetBIOS emulation. While it is not yet a default service, I’m sure it will be soon. KFSensor’s web site (http://www.keyfocus.net/kfsensor/kb/nbtsmb.php) gives details on how to build a rudimentary NetBIOS sim banner server for ports 137 through 139 and 445. I followed the instructions and created the necessary NetBIOS listener ports. I then tested the results by using Nbtscan.exe (http://www.unixwiz.net/tools/nbtscan.html) against the honeypot. As you can see in Figure 8-13, the results showed that KeyFocus’ instructions are a bit off, but the vendor indicated the problem might have been something peculiar to my test setup. There are a few characters out of place, but with a little tweaking of the output banner, it should return results clean enough to fool most hackers. It’s notable that no other Windows honeypot comes even close to this functionality.

Figure 8-13: Results of running Nbtscan.exe against KFSensor’s NetBIOS sim banner server

Open Proxy Server

Spammers are constantly looking for open proxies to send their massive volume of unsolicited mail. KFSensor and other honeypots have recently added open proxy offerings to their feature sets. KFSensor probably has the most sophisticated offering for a general honeypot, with three types of proxies available: SMTP, HTML, and SOCKS. It has eight different proxy emulation settings, including settings that will allow spammers to be partially successful in order to fool their initial testing attempts. KFSensor even supports proxy chaining requests, where spammers (or hackers) include multiple proxies in order to make forensic investigations more difficult. Outgoing spam and proxy requests can be sent to an internal emulation.

This is ideal for luring spammers. You can instruct the SMTP service, emulating an open replay, to forward a certain number of e-mail messages in a 24-hour period to a real server before messages are prevented. This is necessary, because spammers will always test for the existence of an open relay before sending their larger attack. Setting the relay counter to 1 or 2 should be sufficient to fool the spammer. If you set it to 0, no e-mail will be forwarded. In either case, all e-mail will be logged, and you can use this information for analysis. If you check Require Authorization, the interface will ask the hacker to authenticate, but will always reject the credentials.

HOW SPAMMERS WORK AND THE DAMAGE THEY DO

Unsolicited mail, or spam, is, for the most part, illegal throughout the United States and much of the world. How do spammers get away with spamming millions of messages a day without being sued, arrested, or shut down? They can’t use their own servers, because organized antispamming forces shut them down and the authorities could follow the data trail too easily. Instead, they use other people’s computers, as open relays, to send their unsolicited e-mail.

Sources of Open Relays

Open relays can come from one of four sources: SOCKS proxies, HTTP servers, SMTP open relays, or malware-infected computers (which install and use one of the other three types).

SOCKS proxy servers were the first widespread type of proxy servers used on the Internet. They were originally used to send legitimate traffic out of a network protected by a firewall. They allow traffic originating from any port and headed to any destination port to be proxied out of the firewall through a designated allowed port. Hackers can’t get in (because of the firewall), but legitimate users can get out if they know the SOCKS proxy port and configure their computer appropriately. Wingate (http://www.wingate.com) was one of the first proxy server software programs. Although used mostly by legitimate users for legal reasons, if any proxy software can be hijacked, it is only a matter of time before it will be used to send millions of spam messages.

Spammers can also use HTTP servers to spread their junk mail. The HTTP CONNECT command was initially created to allow users to connect to HTTPS servers, but this mechanism is frequently being co-opted by spammers. If spammers detect that a web server will accept a CONNECT command, they will then see if they can use the CONNECT command to proxy out a request to an external computer. If the external request is successful, the web server will soon be sending out more spam than web responses.

An SMTP server is considered an open relay when it will accept and forward mail not ultimately destined for a domain it serves. This was the default nature of every SMTP server until a few years ago, because it was the way the SMTP protocol was intended to function. The protocol creators did not envision that spammers would misappropriate other people’s servers. Spammers port-scan the Internet looking for active SMTP ports, and then send a test relay message to a known-good e-mail inbox that they monitor (called a drop box). Sometimes, the test message is disguised as an antispam e-mail message. If the message goes through successfully, spammers know they can use the SMTP server as their new bulk e-mail server.

Spammers are very clever. If they find a closed-relay server that sends them an error reply saying not to send open-relay e-mail, they can still use the server. They will send their bulk e-mail to the closed-relay server, but with the return addresses of the people they want to spam, instead of the spammer’s return address. The closed relay bounces the e-mail to the spammer’s intended recipient along with the error message. Spammers aren’t even taking the time to find open relays; they just create them.

It is becoming even more common for spammers to use Internet viruses, worms, and spam bots to infect end-user workstations. The malware program infects the computer, and then installs an open-relay SMTP server. Spammers then send spam using regular end-user PCs. The spam malware can deactivate after a few weeks, and find another host to infect or run until it is closed down. Some messaging vendors, like MessageLabs, say that more than 60% of all spam is sent using innocent people’s computers infected with different kinds of spam worms (http://www.messagelabs.com/emailthreats/intelligence/reports/monthlies/October04).

Spam malware is becoming very complex. These programs can “phone home” to update their code and behavior, and are even creating widespread peer-to-peer bot nets to minimize single points of failure. For example, the Hogle trojan (http://securityresponse.symantec.com/avcenter/venc/data/backdoor.hogle.html) installs itself as an open-spam relay. It accepts incoming spammer commands and content on port 3355. After installing itself, it will query antispam relay lists on the Internet for its newly installed IP address. If it finds its own IP address on the list, it will uninstall itself and move on.

What Happens to Open Relays

If you allow your honeypot to emulate an open proxy, it will be probed and attacked by a spam worm or bot fairly quickly (usually within minutes). If you allow the malicious creation to think it is successful (by letting a few of the messages be proxied during the initial probe), your honeypot will be sent millions of messages to be relayed. Spammers will even fight over the honeypot and knock each other off of it, in a “king-of-the-hill”-like power struggle. You’ll find the exercise either interesting or depressing, especially when you realize how this same process is probably happening on tens of thousands of machines that aren’t emulated honeypots. Compromised PCs are even used as a third-party commodity, where the spammer sells time slices on the now open-relay server to other spammers.

Besides just being annoying, spam can cause business-interruption issues. If you’ve ever had your company’s e-mail server blacklisted, you know what I mean. When people get spammed by your e-mail server (because it had an open relay), they can report you to an open-relay blacklist web site. When your domain name is submitted, the web site will automatically generate an open-relay test to your server. If an open relay is found, your e-mail server’s domain name will be added to several blacklists. Many e-mail servers around the world download these blacklists and will not accept e-mail from any e-mail server listed.

Getting “unblacklisted” can be quite frustrating. You need to close the open relay, and then submit a request to the blacklisting site to be retested. Often, by the time the open relay has been closed, the offending server is on multiple blacklist sites, and getting the e-mail server fully operational again can take days.

Spammers, we hate you.

Other Emulated Microsoft Services

KFSensor offers other rudimentary emulated Microsoft services, including Telnet Server, SQL Server, Terminal Services, and POP3. With the exception of the POP3 emulated service, no other Windows honeypot has these default services.

KFSensor’s telnet sim standard server mimics a Microsoft Telnet Server in a limited way. Visitors will be given the normal Microsoft banner and prompted for a username and password, but it will never be accepted.

The SQL Server sim server is a bit more involved. It handles protocol negotiation and decrypts login packets. It correctly refuses login requests and handles UDP information requests.

KFSensor’s Terminal Server sim standard server allows a connection attempt to be tried only on port 3389. It does record connecting information, but offers no other visible signs of compatibility. It’s only a port listener as best as I can tell (I don’t know why it isn’t classified as a banner server). But it still has better default functionality than most Windows honeypots.

KFSensor emulates a Microsoft POP3 server, displaying the banner:

 + OK Microsoft Windows POP3 Service Version 2.0 ([e-mail]) ready. 

The only POP3 commands accepted are USER, PASS, and QUIT. The visitor will never be able to authenticate.

Logging and Alerting with KFSensor

KFSensor is configured to alert on medium-priority and high-priority events. Logging is done on all events, including low-priority types.

Alerting can be in the form of logging, desktop icon flashing, alert sounding, or SMTP messaging. You can configure KFSensor to play a sound to indicate an alert, played just once during each alert event or during a set period of time. This way, you can avoid dozens of alerts sounding because of one common event, such as a port scan. You can configure SMTP alerts to send messages in long or short message format, as shown in Figure 8-14. Long message format is for regular SMTP e-mail; short messages are for the SMS format for PDAs and pagers.

Figure 8-14: KFSensor SMTP alert configuration dialog box

The on-screen logging capabilities of KFSensor are very flexible. By default, only the last two days are brought up when the program is activated (although this can be customized). You can filter what is on the screen and sort the information by time (newest or oldest), priority, and many other fields. You can add and remove columns of data, and change their order. The data columns available are listed in Table 8-3.

Table 8-3: KFSensor Event Column Fields

Name	Description
ID	The event identification number.
Type	The type of the event.
Description	Additional information.
Start	The date and time of the start of an event.
Start Date	The date of the start of an event.
Start Time	The time of the start of an event.
End	The date and time of the end of an event.
End Date	The date of the end of an event.
End Time	The time of the end of an event.
Sensor Bind	The address to which the sensor was bound (blank if the sensor is not bound to a single IP address).
Sensor IP	The IP address of the sensor on which the event was detected.
Sensor Port	The port number of the sensor on which the event was detected.
Sensor IP:Port	The IP address combined with the port of the sensor on which the event was detected.
Visitor IP	The IP address of the visitor that generated the event.
Visitor Port	The port number on the visitor’s machine used in the connection.
Visitor IP:Port	The IP address combined with the port number on the visitor’s machine used in the connection.
Visitor Domain	The domain name of the visitor that generated the event (obtained by a reverse DNS lookup on the visitor’s IP address).
Visitor	If the visitor’s domain name can be obtained, it is displayed; otherwise, the visitor’s IP address is displayed.
Name	The name of the listening sensor that generated the event.
Protocol	The communication protocol used in the event.
Action	The action taken by the sensor.
Sim Server	The name of the sim server used, if specified.
Closed By	Who closed the connection: the visitor or the sensor.
Limit Exceeded	If the visitor attempted to send more data to the sensor than the maximum permitted, this will be indicated.
Received	The data sent by the visitor to the sensor (only a limited number of bytes are displayed, and non-ASCII displayable bytes are encoded).
Response	The data sent by the sensor to the visitor (only a limited number of bytes are displayed, and non-ASCII displayable bytes are encoded).
Received Bytes	The length of the data sent by the visitor to the sensor, in bytes.
Response Bytes	The length of the data sent by the sensor to the visitor, in bytes.
Severity	The severity level of the event.
Sensor ID	The ID of the sensor on which the event was detected.

Events can be exported to HTML, XML, TSV, and CSV file formats. Although KFSensor can write logs to any SQL Server or ODBC-compliant database, it writes XML log files to C:\kfsensor\ logs by default (this location can be changed). Event logs are named Kfsenslog_yyyymmdd.log, where yyyymmdd represents the date the log file was started. The log files record payload packet information, as shown in Figure 8-15, but this is not a complete packet decode. You won’t find ARP entries, packet header information, or which flags were set. For that information, you’ll need an external sniffer (see Chapter 9).

Figure 8-15: KFSensor log example showing an FTP login session

Two other diagnostic ASCII logs are in the logs folder: System.log shows services startup and any error messages (like port binding conflicts or SMTP messaging problems), and Sensmon.log shows when the KFSensor monitor stopped and started.

Note 

Multiple KFSensor installations can be written to the same centralized SQL Server or ODBC-compliant database.

Alerts can also be sent to a Windows Application event log, as shown in Figure 8-16, which is convenient if you already have a centralized alert system based on Windows event log messages. Of course, you can log to a Syslog service, too.

Figure 8-16: Windows event log message generated by an FTP login session

Configuring KFSensor Listeners and Anti-DoS Settings

KFSensor allows you to define rules to modify each listener’s behavior. Each scenario can contain an unlimited number of rules based on IP range, protocol, or port number. Rules can be used to ignore or close certain ports, or change event priority. Rules can be defined by source-origination address to allow KFSensor to react differently depending on the remote machine. For example, attacks originating internally or from the DMZ to an internal KFSensor computer can create higher-priority alerts. Or, you can tell KFSensor not to alert to broadcast or vulnerability scans originating from certain IP addresses to minimize false-positives.

KFSensor promotes its anti-buffer overflow and anti-DoS attack coding. Its developers wrote KFSensor considering potential buffer overflows. They coded it in C++ and manipulated the input buffers to prevent buffer overflows. Although you cannot adjust KFSensor’s anti-buffer overflow functionality, you can modify the anti-DoS settings. KFSensor allows you to configure (in the DOS Attack Settings box, shown in Figure 8-17) how much traffic it will accept from one source IP at a time. High traffic will result in the source IP being blocked, and if multiple addresses try to cause a DoS attack, KFSensor will refuse to accept any connections from anywhere. Although at least two other honeypots (SPECTER and PatriotBox) offer DoS protection, KFSensor’s is the most extensive.

Figure 8-17: KFSensor’s anti-DoS settings dialog box