Sunday, October 31, 2004

Thoughts on NetBSD's New Logo

In other BSD news, NetBSD announced their new logo, pictured at left. Slashdot discussed the new logo, with the consensus being it is "uninspired," "corporate," and not "fun." I am not surprised that a tech crowd would think this way. One post broke from this trend by saying:

"If you're trying to get people interested in your product, the first rule is don't offend people. Like it or not, there are folks out there who don't understand the difference between daemon and demon."

I agree with this. I also found it fairly juvenile that Slashdot's moderators rated a complaint about the NetBSD daemons as being "funny." I get plenty of odd looks by airport security when I show them my laptop covered with FreeBSD daemon sticks.

Most importantly, the old NetBSD "logo" doesn't qualify as a logo at all. It's a piece of computer-inspired art that doesn't meet the conditions necessary for a logo. To get an idea of what a good logo looks like, visit Look at their Top 250 Logos as rated by visitors page for ideas of good logos.

All of these logos are simple, clean, and portable across various "platforms" -- T-shirts, mugs, stickers, etc. This sounds like NetBSD, doesn't it? I bet you could also name most or all of the organizations they depict, although the Sun logo is the only one to contain the designated company name.

I would like to see a real logo for FreeBSD as well, preferably one without a daemon. I believe in separation between a logo and a mascot. The FreeBSD mascot is "Beastie," a "daemon." The OpenBSD mascot is the puffer fish. Similarly, Tux the penguin is the Linux mascot, and not its "logo." All three operating systems would do well to follow NetBSD's lead. Maybe DragonFly BSD is ahead of the game?

FreeBSD 5.3-RC2 Released

img src="" align=left>The availability of FreeBSD 5.3-RC2 was just announced. The release engineer says "if no more show-stopper problems are found this will be the last test release done before 5.3-RELEASE." I intend to test this at work tomorrow morning. The release engineering team is doing everything they can to make this a release fit for the title STABLE.

Using A Digital Camera with FreeBSD

I decided to try to get my Canon Powershot S40 digital camera working with my FreeBSD laptop. I found that plugging in the USB cable only yielded this entry in /var/log/messages:

ugen0: Canon Inc. PowerShot S40, rev 1.10/0.01, addr 2

The ugen driver provides support for all USB devices that do not have a special driver, according to its man page. Running usbdevs showed the camera connected to the laptop:

sudo usbdevs -dv
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
Intel(0x0000), rev 1.00
port 1 addr 2: full speed, self powered, config 1,
PowerShot S40(0x3056), Canon Inc.(0x04a9), rev 0.01
port 2 powered

Unfortunately, I did not see the dymanic creation of a device like /dev/da0 that might have let me mount the camera and read files from it. (The problem was discussed in this thread.) I turned to the ports tree and found graphics/gphoto2, which I installed as a package:

orr:/home/richard$ sudo pkg_add -vr gphoto2

When done I followed the Gphoto2 documentation. First I checked for available ports:

orr:/home/richard$ gphoto2 --list-ports
Loading camera drivers from '/usr/lo... | \ 2.0%
Devices found: 1
Path Description
usb: Universal Serial Bus

Next I searched for cameras. I found that I needed to run some of these commands as root using sudo:

orr:/home/richard$ sudo gphoto2 --auto-detect
Loading camera drivers from '/usr/lo... | \ 2.0%

Model Port
Canon PowerShot S40 usb:

Once I found the camera I discovered what Gphoto2 thought of it:

orr:/home/richard$ sudo gphoto2 --summary
Loading camera drivers from '/usr/lo... | \ 2.0%

Detected a 'Canon:PowerShot S40'.
Camera summary:

Camera identification:
Model: Canon:PowerShot S40

Power status: on battery (power OK)

Flash disk information:
Drive D:
256'352'256 bytes total
207'917'056 bytes available

Time: 2004-10-31 11:51:51 (host time -1 seconds)

Now I could find files on the camera:

orr:/home/richard$ sudo gphoto2 --list-files
Loading camera drivers from '/usr/lo... | \ 2.0%
Detected a 'Canon:PowerShot S40'.
There are no files in folder '/'.
There are no files in folder '/DCIM'.
There is one file in folder '/DCIM/106CANON':
#1 IMG_0700.JPG rd 921 KB image/jpeg
There are 43 files in folder '/DCIM/107CANON':
#2 IMG_0703.JPG rd 1019 KB image/jpeg
#3 IMG_0704.JPG rd 1278 KB image/jpeg
#4 IMG_0705.JPG rd 885 KB image/jpeg
#5 IMG_0706.JPG rd 929 KB image/jpeg
There are no files in folder '/DCIM/CANONMSC'.

When I found a file I wanted, I retrieved it:

orr:/home/richard$ sudo gphoto2 --get-file 38-39
Loading camera drivers from '/usr/lo... | \ 2.0%
Detected a 'Canon:PowerShot S40'.
Downloading 'IMG_0741.JPG' from folder '/DCIM/107CANON'...
Receiving data... | \ 0.5%
Saving file as IMG_0741.JPG

After the files were downloaded to my laptop I was able to manipulate them using my preferred file editing programs. I removed the USB cable from the laptop and got this message from the kernel:

ugen0: at uhub0 port 1 (addr 2) disconnected
ugen0: detached

There's a graphical application for Gphoto2 called Gtkam but I got errors in the pango library when I tried to use it.

Friday, October 29, 2004

Former Foundstone Consultants Create New Firm

Earlier this month McAfee completed its acquisition of Foundstone. Previously I reported that several early refugees from Foundstone, led by Kevin Mandia, founded Red Cliff Consulting. Now a faction led by another former Foundstone director, Clinton Mugge, has created C-Level Security. Whereas Red Cliff focuses on computer forensics and incident response, C-Level concentrates on prevention-oriented services like vulnerability assessments and network architecture. C-Level's first press release emphasizes its independent nature, according to founder Mugge:

"Problems are solved by selecting and deploying the best products and solutions in an unbiased manner, something a product-centric vendor is just not focused on delivering. C-Level Security's clients are provided the knowledge and understanding to make strategic decisions in security roadmap planning and spending without the push toward a single vendor product line."

These departures are a good example why a company based on providing services sells for less than one selling a product. Less than one month since the acquisition of Foundstone, two groups who formerly provided substantial intellectual firepower have left McAfee for greener pastures. Until software grows its own legs, it will be difficult for it to walk out the door when acquired by a bigger company.

According to its Web site, C-Level has partnered with Red Cliff for services (no doubt IR and forensics) and with NT Objectives for technology. That is the same NTO against which Foundstone filed a restraining order two years ago for trying to release a product suspiciously similar to FoundScan. A recent Red Herring story reports

"Software company NT Objectives, based in Orange County, California, is just coming out from under trade-secret litigation from security consulting firm Foundstone, and has secured less than $1 million in funding... the company searched for funding, did not get it, and has since stopped looking and is getting by on product sales."

Thursday, October 28, 2004

Best Practices Chapter Now Online

In an arrangement with and Addison-Wesley, chapter 11 of The Tao of Network Security Monitoring: Beyond Intrusion Detection is now available online . Although the chapter discusses "Best Practices," typically a boring management concept, I managed to include several packet trace-driven case studies. Chapter 11 joins the foreward, chapter 2, and chapter 10 as being available online.

Red Sox Win!

Wednesday, October 27, 2004

PHK's Insights on Open Source Development

As an open source user and advocate, and especially as a FreeBSD user, I found this interview with Poul-Henning Kamp fascinating. PHK recently became famous for requesting and receiving funding from the community for FreeBSD development. PHK describes what it's like to be self-employed and working alone:

"[I]t is a mixed blessing for me. The situation is not as much a bold 'I answer to nobody!' as a worried 'Shit! I'm all alone...'

Normally then, as selfemployed, you have the separation from your customers, some kind of contract where you can draw the line, but in my case I answer to the FreeBSD community more or less on a contract of 'give me money and I'll do good things for FreeBSD.'

The pressure from within is worse than any pressure any boss have ever laid on me."

To me this is one of the greatest differences between open source software and commercial software. When I see someone commit code to an open source project, I can associate a specific person with that change. If that change is poorly coded, or controversial, people will notice and complain. Something similar to this happened recently and was documented in the FreeBSD cvs-src summaries.

When someone makes a change to Windows, it is completely opaque. As a result, open source achieves a level of accountability and transparency unlike anything in commercial software. Only when a single developer or a very small known group is responsible for a commercial product can a similar level of "pressure" be applied to proprietary, closed software.

On a related note, Slashdot featured a useful thread titled Switching to Contracting? that describes what it's like to go out on one's own.

MySQL 4.1 Now "Generally Available"

I read at that MySQL 4.1 is now Generally Available (GA). also issued a press release. GA status means the MySQL development team considers the software stable enough for production use. Previously MySQL 4.0 was the GA release and 3.23 was considered "Recent; still supported." Currently both MySQL 4.0 and 4.1 are GA, with 4.1 "recommended" over 4.0. The bleeding edge of MySQL development is 5.0, which is alpha code.

When I began writing Sguil installation docs, I advocated using MySQL 4.0. One of the advantages of MySQL 4.0 is UNION, or the ability to combine the result from many SELECT statements into one result set. While Sguil does not currently use this UNION feature, I expect to see it in future releases. The UNION function in MySQL 4.0 and higher results in much faster queries of session data in Sguil. The OSNews discussion mentions that replication has been enhanced in MySQL 4.1. Replication allows sharing data between two database servers, which is helpful for redundancy in security applications like Sguil.

Will Compromises at Universities Aid Security Research?

Last year I reported my experiences attending the 2003 International Symposium on Recent Advances in Intrusion Detection, also known as RAID. Many briefers complained that their security research suffered due to lack of good data. For example, intrusion detection analysts usually relied on the 1999 DARPA Intrusion Detection Evaluation data. Data like this may be sanitized for analysis by researchers but it pales in comparison to watching live traffic from production networks.

Several recent events may give security researchers the data they need. For example, UC Berekely suffered an intrusion on 1 Aug 04 which jeopardized a database containing names, addresses, telephone and Social Security numbers collected by the California Department of Social Services (CDSS). According to Carlos Ramos, assistant secretary at CDSS, the compromise "was discovered on Aug. 30 by Berkeley IT staff using intrusion detection software." I wonder if the IDS was Vern Paxson's Bro, developed in the International Computer Science Institute and featured in chapter 9 of The Tao of Network Security Monitoring? As I mention in the book, Vern previously used Bro to track intruders at UC Berkeley.

A second security powerhouse was just the victim of an intrusion. An intruder gained access to systems at Purdue's West Lafayette campus, according to published reports. The Center for Education and Research in Information Assurance and Security (CERIAS), where Gene Spafford is Executive Director, features Brian Carrier of Sleuthkit fame as a student. Might he be doing an incident response and forensic analysis on the affected systems?

Finally, while browsing Web site defacements at zone-h, I noticed a mirror for Texas A&M University is the home of the famous Drawbridge bridging firewall. Might the researchers there be preparing to study the compromise of "OurNet, the TAMU Career Center Intranet"? It looks like intruders defaced the TAMU Web site by exploiting a PHP application, as the defacement mirror prominently features PHP-Nuke.

Keep an eye open for papers on "real world intrusions" from these and other academic sources suffering compromises.

Friday, October 22, 2004

New Tao of NSM Review

I just read a review of The Tao of Network Security Monitoring by the acclaimed network information site From the review:

"Every once in a while you come across a book that really opens your eyes. One that talks in-depth about something completely different.

Unfortunately, most technical IT books are rehashes of a bunch of papers and tutorials off the net, and you often wonder whether the time you spent reading the book would have been better spent on google.

The Tao of Network Security Monitoring is not one of these books. It is with great pleasure that I am reviewing what I consider one of the most informative and well written books I have ever come across.

Network Security Monitoring (NSM) is half a science, and half a black art. It requires an in-depth knowledge of packets, protocols, applications, vulnerabilities and black hat tactics. This book focuses on the philosophy behind NSM, the skills required, the tools you need, and the way to set up an effective NSM operation.

The author, Richard Bejtlich, is a former Air Force intelligence officer, and the approach he dictates is almost military in nature. This book covers an introduction to security, what NSM is, how to deploy it, the best tools for the job and the types of things you will see."

Read on for more. I appreciate the review!

Ed Skoudis Reports on Anti-Virus Vendor Support

The October 2004 issue of Information Security Magazine offers an excellent study by Ed Skoudis. I saw Ed speak at a Computer Associates sales pitch a few weeks ago and he gave me preview of the new article. Now the whole study is available online. In Ed's words:

"As a follow-up to our technical review of desktop AV products, Information Security investigated the state of the AV industry's customer support, putting five vendors to the test: Computer Associates, McAfee, Symantec, Sophos and Trend Micro. We graded each on the entire support experience, putting the greatest weight on the ability to solve our test problems...

AV support has a long way to go before it achieves what we consider acceptable levels. It's not hard to figure out what's needed: The prescription for success is more or less distributed among the vendors we reviewed.

Sophos technicians displayed the technical savvy and problem-solving ability we expected from all of the vendors. Realistically, scaling that type of support to larger vendors like Symantec or McAfee would be a tough task, but stepping up the caliber of their support staffs would provide a competitive advantage.

CA demonstrated a model for quick, efficient response, without frustrating delays. Symantec's calls were clear and its technicians easy to understand; there's no excuse for poor audio quality or support personnel who are hard to understand. All the vendors need to improve their online help--if customers can solve problems themselves, they'll be happy and the vendor will have fewer calls."

I believe Ed's article is invaluable to anyone responsible for customer-facing operations. His findings should be a wake-up call for those who manage customer expectations and experiences.

I was struck by the poor service given to people paying for commercial software, since lack of "support" is frequently cited as a reason to avoid open source solutions. Why would a person be willing pay to wait on the phone for half an hour or more to receive incorrect advice, when an open source solution might exist? Open source anti-virus isn't really an option for a corporation, but there are solutions for home users (like Grisoft's AVG).

Thursday, October 21, 2004

Dual-boot FreeBSD 5.3 and Windows 2000

For my testing of FreeBSD 5.3 before it's available as a RELEASE, I decided to work on dual-booting it with Windows 2000. I did not want to use any third-party boot loaders unless absolutely necessary.

I preferred to use the FreeBSD boot loader as FreeBSD is the primary OS on my Thinkpad a20p. Unfortunately, I could not figure out a way to overcome the different ways Windows and FreeBSD see disk geometry while using the FreeBSD boot loader. The following describes how to dual-boot FreeBSD 5.3 and Windows 2000 with Windows in the Master Boot Record handling boot selection. I found these notes helpful although I did not following all of the author's recommendations.

First I installed Windows 2000 in a 7427 MB C: partition, formatted as NTFS. I also created a 30727 MB D: partition to hold FreeBSD, although I only let the Windows installation process create the partition and nothing more.

Next I began the FreeBSD installation process using a CD-ROM. When it came time to partition the drive I saw this message:

WARNING: A geometry of 77520/16/63 for ad0 is incorrect.
Using a more likely geometry. If this geometry is incorrect
or you are unsure as to whether or not it's correct, please
consult the Hardware Guide in the Documentation menu or use
the (G)eometry command to change it now.

Remember: you need to entry whatever your BIOS thinks the
geometry is! For IDE, it's what you were told in the BIOS
setup. For SCSI, it's the translation mode your controller
is using. Do NOT use a "physical geometry."

I hit 'ok' and continue to the partition menu. I deleted the partition identified by FreeBSD as ad0s2 "extended DOS, LBA" (the D: drive created while installing Windows) and created a FreeBSD partition. Crucially, I set the Bootable flag on ad0s1 which held the NTFS partition for Windows 2000.

When asked how to handle the MBR, I chose to Leave the Master Boot Record untouched. This preserved the Windows code in the MBR. Because Windows knew of another partition (originally D:) I believed the boot loader show know how to find the new FreeBSD partition in the same location.

After that I proceeded with the regular FreeBSD installation tasks of creating /, /usr, and so on. When done I rebooted and found myself again in Windows 2000. At this point Windows is not aware of FreeBSD and one cannot access the FreeBSD installation without a boot disk.

I inserted the FreeBSD installation CD-ROM and copied the boot/boot1 file to a new file called c:\freebsd. I then modified the c:\boot.ini file by running 'notepad c:\boot.ini'. You cannot find this file with 'Search' or via Explorer as it is hidden from normal view.

I added the following at the very end of the boot.ini file:

c:\freebsd="FreeBSD 5.3 REL"

After saving changes I rebooted Windows. The next time Windows appeared I had the choice of booting Windows 2000 or FreeBSD 5.3-REL. Either OS can now be started from this menu.

Improving Windows Baselining with Tlist.exe

Several people provided feedback on my Simple Post-Installation Baselines on Windows Blog entry. First, Beau Monday reminded me of his FirstOnScene incident response scripts. I haven't tried these out but you might want to see if they make life easier for your first responders.

Second, Harlan Carvey pointed out the program tlist.exe shipped with the Debugging Tools for Windows. This is apparently not the same tlist.exe found on some Windows systems. You can obtain tlist.exe by downloading and installing the debugging tools, and then copying the tlist.exe binary elsewhere.

I tested the independence of tlist.exe by running it on a system where no special debugging tools were installed, and where I did not have administrator privileges.

Here is an excerpt of tlist.exe output. This tool is especially helpful because it shows the full path for executables. This allows you to differentiate between a 'svchost.exe' started from "C:\WINDOWS\system32" (where it belongs) and "C:\WINDOWS\system32\temp" (where it doesn't):

c:\>tlist.exe -v

0 0 System Process
Command Line:
0 4 System
Command Line:
0 376 smss.exe
Command Line: \SystemRoot\System32\smss.exe
Process StartTime: 10/18/2004 6:54:42 AM
0 652 csrss.exe Title:
Command Line: C:\WINDOWS\system32\csrss.exe
ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On
SubSystemType=Windows ServerDll=basesrv,1
ProfileControl=Off MaxRequestThreads=16
Process StartTime: 10/18/2004 6:54:46 AM
0 676 winlogon.exe
Command Line: winlogon.exe
Process StartTime: 10/18/2004 6:54:48 AM
0 720 services.exe Svcs: Eventlog,PlugPlay
Command Line: C:\WINDOWS\system32\services.exe
Process StartTime: 10/18/2004 6:54:49 AM
0 732 lsass.exe Svcs: PolicyAgent,ProtectedStorage,SamSs
Command Line: C:\WINDOWS\system32\lsass.exe
Process StartTime: 10/18/2004 6:54:49 AM
0 888 svchost.exe Svcs: DcomLaunch,TermService
Command Line: C:\WINDOWS\system32\svchost -k DcomLaunch
Process StartTime: 10/18/2004 6:54:50 AM
0 952 svchost.exe Svcs: RpcSs
Command Line: C:\WINDOWS\system32\svchost -k rpcss
Process StartTime: 10/18/2004 6:54:51 AM
0 1040 svchost.exe Svcs:
Command Line: C:\WINDOWS\System32\svchost.exe -k netsvcs
Process StartTime: 10/18/2004 6:54:51 AM
0 1124 svchost.exe Svcs: Dnscache
Command Line: C:\WINDOWS\system32\svchost.exe -k NetworkService
Process StartTime: 10/18/2004 6:54:51 AM
0 1228 svchost.exe Svcs: LmHosts,RemoteRegistry,SSDPSRV,WebClient
Command Line: C:\WINDOWS\system32\svchost.exe -k LocalService
Process StartTime: 10/18/2004 6:54:52 AM
0 1364 CCSETMGR.EXE Svcs: ccSetMgr
Command Line: "C:\Program Files\Common Files\Symantec Shared\ccSetMgr.exe"
Process StartTime: 10/18/2004 6:54:54 AM
0 1392 CCEVTMGR.EXE Svcs: ccEvtMgr
Command Line: "C:\Program Files\Common Files\Symantec Shared\ccEvtMgr.exe"
Process StartTime: 10/18/2004 6:54:54 AM
0 1556 spoolsv.exe Svcs: Spooler
Command Line: C:\WINDOWS\system32\spoolsv.exe
Process StartTime: 10/18/2004 6:54:55 AM
0 1940 NAVAPSVC.EXE Svcs: navapsvc
Command Line: "C:\Program Files\Norton AntiVirus\navapsvc.exe"
Process StartTime: 10/18/2004 6:55:02 AM
0 1972 NeTmSvNT.exe Svcs: NetTimeSvc
Command Line: "C:\Program Files\NetTime\NeTmSvNT.exe"
Process StartTime: 10/18/2004 6:55:03 AM
0 324 NMSSvc.Exe Svcs: NMSSvc
Command Line: C:\WINDOWS\system32\NMSSvc.exe
Process StartTime: 10/18/2004 6:55:06 AM
0 480 SAVSCAN.EXE Svcs: SAVScan
Command Line: "C:\Program Files\Norton AntiVirus\SAVScan.exe"
Process StartTime: 10/18/2004 6:55:07 AM
0 896 svchost.exe Svcs: stisvc
Command Line: C:\WINDOWS\system32\svchost.exe -k imgsvc
Process StartTime: 10/18/2004 6:55:09 AM
0 1024 symlcsvc.exe Svcs: Symantec Core LC
Command Line: "C:\Program Files\Common Files\Symantec Shared\CCPD-LC\symlcsvc.exe"
Process StartTime: 10/18/2004 6:55:10 AM
0 768 SymWSC.exe Svcs: SymWSC
Command Line: "C:\Program Files\Common Files\Symantec Shared\Security Center\SymWSC.exe"
Process StartTime: 10/18/2004 6:55:11 AM
0 1844 msmsgs.exe Title:
Command Line: "C:\Program Files\Messenger\msmsgs.exe" -Embedding
Process StartTime: 10/20/2004 8:52:04 AM
0 3504 msiexec.exe Svcs: MSIServer
Command Line: C:\WINDOWS\system32\msiexec.exe /V
Process StartTime: 10/20/2004 8:52:35 AM
0 2156 cmd.exe Title: Command Prompt - tlist.exe -v
Command Line: "C:\WINDOWS\system32\cmd.exe"
Process StartTime: 10/20/2004 8:53:26 AM
0 172 dllhost.exe Svcs: COMSysApp Mts: System Application
Command Line: C:\WINDOWS\system32\dllhost.exe
Process StartTime: 10/20/2004 8:54:09 AM
0 2412 tlist.exe
Command Line: tlist.exe -v
Process StartTime: 10/20/2004 8:54:37 AM

There is a lot you can do with this data. I'm pointing it out because a small amount of work done prior to a compromise when a system is in a trusted post-installation state can make identifying and responding to compromise quicker, cheaper, and easier.

Tuesday, October 19, 2004

Benefits of Short Term Incident Containment

One of the regulars in the #snort-gui IRC channel of asked me the following question via email. This is an excerpt, and my response follows:

"I am very interested to hear your insight on the topic of 'incident containment' via TCP resets... I am concerned about whether or not incident containment should even be used. From a purely technical standpoint it seems like 'Sure, it's better than just leaving the connection live. It's helping to interfere, after-all.'

But when I think about it in a real-world application, it seems like many malicious hackers will notice TCP resets as a clear sign they have been spotted. It seems like this understanding on their part will cause them to attempt to shoot in again even if only for the brief seconds required to 'rm -rf /'.

The alternative, no TCP resets, it seems the intruder will most likely think their presence is yet unknown and they may be content with their backdoor...

I guess the overall idea is in some ways it seems safer to -not- implement 'incident containment' via TCP resets. If their access is limited to a lower level user access or something then sure TCP resets may be great in preventing them from escalating their privs further, but if they have gained root/admin access it seems very dangerous to try such an ad-hoc method of temporary containment.

Are TCP resets effective enough to prevent last-ditch efforts at wiping a machine?"

This is a good question. I will frame my answer using the concepts in The Tao of Network Security Monitoring. Let's start by describing a scenario. You're performing network security monitoring, and your sensor generates alert data indicating the compromise of your Web server. You check your session data and realize the intruder has connected to a back door installed as part of the initial exploit. Reviewing your full content data, you see the intruder has root level access on the target. (If the full content data were encrypted, preventing useful review of the back door communications, I would assume root level access anyway.)

The question at this point is "what now?" Your level of situational awareness is good, since you know the intrusion attempt succeeded and the intruder has control of the target. (If you were not following NSM principles and were not collecting alert, session, and full content data using something like Sguil, you'd still be at the alert review process wondering what the alert meant!) Now you have to decide what you value more: information about the threat or controlling the threat.

If you're running a Honeynet, the answer is clear: you value information about the threat. You will not take actions to deny further access to the intruder. What if the target is a normal production system? The decision to limit intruder further access depends on the knowledge the victim already possesses about the intruder.

In this scenario, we saw the method of entry and its effects. If we value learning the intruder's ultimate goal (vandalism, espionage, theft, etc.), we should not interfere with his back door. This is very risky, especially if we see credit card databases transferred to Russia while we sit and watch the intruder.

If we value recovering the security of the target, we should definitely cut off the intruder's access. In the case I described, I would immediately implement Short Term Incident Containment (STIC) to deny further intruder access (more on how shortly).

In a different scenario, we might stumble upon an indicator that a victim is compromised, without knowledge of the initial point of entry. For example, a review of our statistical NSM data could show an increase in ICMP traffic. Closer review of full content data shows the ICMP traffic does not meet normal standards and is indicative of an ICMP-based back door. Learning of an intrusion in progress is more common than seeing an intrusion from start to finish, in my incident response consulting experience.

In a case where we do not know how the intruder gained access, or how many targets he has compromised, we would probably value intelligence gathering over containment. In other words, we might let the intruder maintain access so as to determine his modus operandi and what other systems he has compromised. Once we have a sense of the scope of the compromise, we might then institute STIC.

The original question mentioned 'TCP resets.' These are a way for a sensor to spoof reset traffic to fool the source and destination hosts into thinking they each want to end an active connection. This technique is offered as a way for a sensor sitting off-line to interrupt an intrusion attempt. I've used this technique since 1998 and I can report it is not foolproof for a variety of reasons. TCP resets should be used as a last-ditch STIC method.

The best way to limit an intruder's manueverability is to use an access control device. This is best done with a true firewall, although stateful router ACLs can be applied as well. Sometimes a target will be cut off from the outside world after an attack, and then reconnected with special access control measures taken to limit an intruder's manueverability. This is called "fishbowling" a target.

As for whether an intruder will try to quickly destroy a target to eliminate evidence: I never consider this when making the deny/allow decision. You've got to decide whether you value information about the threat or controlling the threat.

I follow the rule that it is unwise to 'hack back' or otherwise touch intruders, since I don't want to tip off intruders that I've seen their activities. (Some consider deterrence a valid goal of NSM operations, and there is evidence that the Air Force had the best results deterring intruders due to its vigilance. I don't think the same applies to the commercial world because .gov is more willing to pursue and prosecute than .com or .edu.) I consider shutting down remote access and thereby alerting the intruder a necessary step when the victim values controlling the threat.

Any time an intruder has root level access, the situation should be immediately considered extremely poor. The only mitigating factor is the level of knowledge you have of the intruder's activity on the target. If your NSM operation has complete awareness of the intruder's actions, you may recover without completely rebuilding the target. If you have any doubt as to what actions the intruder may have taken on the target, I recommend a complete rebuild from trusted sources.

I talk more about STIC, the decision to watch intruders, and related issues in my book. Thank you for the question, and I look forward to comments and other queries.

Monday, October 18, 2004

FreeBSD 5.3-RC1 Released

FreeBSD 5.3-RC1 just appeared on the FreeBSD FTP servers. I was hoping to see it soon after the schedule was updated. If only one Release Candidate is built (as planned), then we might see 5.3 RELEASE in about a week. After having seven BETAs produced, I expect we'll have RC2 as well. I imagine 5.3 RELEASE will appear the first week of November, as the release engineers have high standards for this FreeBSD version. With 5.3 the STABLE tag will migrate from the 4.x line to the 5.x line. 6.0 will be CURRENT although it has been treated as such for a few months now.

Saturday, October 16, 2004

Simple Post-Installation Baselines on Windows

I just finished setting up a new Windows XP SP2 system on a Shuttle SB52G2 for my wife. This box screams compared to the 1998-era PII 333 MHz tower it replaced.

Now that the installation is done and I've loaded all the software we expect to use on the system and all appropriate patches, I've taken a few simple steps to record a baseline configuration. I use the free PsTools suite from to record key aspects of the operating system and installed software. Here are the tools I run and sample output for each. All of this information is redirected into text files that I store on the system and on a separate system for safekeeping. I ran all of these programs without administrator privileges.

Believe it or not, but not everyone who breaks into your Windows systems is a Uber Elite hacker. Sometimes they tools used by intruders or malware leaves evidence in output such as this. If you can compare this listing, taken in a known good state, to later records, you might discover unauthorized software. It is best to update these records each time you apply a service pack or hotfix.

PsInfo: This utility records essential system information, like patch levels and installed applications:

c:\>psinfo -h -s -d

System information for \\SCOUT:

Volume Type Format Label Size Free Free
A: Removable 0%
C: Fixed NTFS 15.0 GB 11.8 GB 78%
D: Fixed NTFS data 59.5 GB 55.9 GB 94%
E: CD-ROM 0%
OS Hot Fix Installed

KB834707 10/16/2004
KB885884 10/16/2004
Q147222 10/12/2004
7-Zip 4.09 beta
Adobe Acrobat - Reader 6.0.2 Update 6.0.2
Adobe Download Manager 1.2 (Remove Only)
Adobe Photoshop Album 2.0 Starter Edition 2.00.100
Adobe Reader 6.0.1 006.000.001
AutoUpdate 1.0
Avance AC'97 Audio
DivX 5.2.1
DivX Player 2.5.5
Intel(R) 82845G Graphics Driver Software
Intel(R) PRO Ethernet Adapter and Software
Intel(R) PRO Intelligent Installer 2.01.0000
IrfanView (remove only)
LiveReg (Symantec Corporation)
LiveUpdate 2.5 (Symantec Corporation)
MWSnap 3
Macromedia Shockwave Player
Microsoft Baseline Security Analyzer 1.2.1 1.2.4013.0
Microsoft Money 2002 10.0.80
Microsoft Money 2002 System Pack 10.0.80
Microsoft Office XP Standard 10.0.6626.0
NetTime 2.0
Norton AntiVirus 2004 10.00.00
Norton AntiVirus 2004 (Symantec Corporation) 10.00.00
Norton AntiVirus Parent MSI 10.0.0
Norton AntiVirus SYMLT MSI 10.0.0
Norton WMI Update 2005.1.0.111
PDFCreator 0.8.0
SymNet 4.7.1
Symantec Script Blocking Installer 1.0.0
WebFldrs XP 9.50.7523
Windows XP Hotfix - KB834707 20040929.110854
Windows XP Hotfix - KB885884 20040924.025457

PsList: This tool lists all processes running on the system. Again, you might notice an unauthorized process by comparing a later listing to this one taken under post-installation conditions. While the PsInfo output was easy to ready, it can be more difficult to make sense of processes based solely on their names.


PsList 1.26 - Process Information Lister
Copyright (C) 1999-2004 Mark Russinovich
Sysinternals -

Process information for SCOUT:

Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time
Idle 0 0 1 0 0 0:34:33.093 0:00:00.000
System 4 8 55 266 0 0:00:09.468 0:00:00.000
smss 372 11 3 21 164 0:00:00.984 0:40:50.680
csrss 664 13 11 498 1680 0:00:20.765 0:40:47.946
winlogon 688 13 20 532 7468 0:00:05.125 0:40:46.540
services 736 9 15 296 1912 0:00:07.703 0:40:45.540
lsass 748 9 20 366 3720 0:00:05.375 0:40:45.446
svchost 892 8 20 206 3008 0:00:01.343 0:40:44.086
svchost 960 8 11 376 1844 0:00:06.828 0:40:43.680
svchost 1000 8 72 1459 13024 0:00:11.953 0:40:43.461
svchost 1080 8 6 101 1252 0:00:00.343 0:40:42.665
svchost 1160 8 15 212 1656 0:00:00.328 0:40:42.071
CCSETMGR 1268 8 6 183 2400 0:00:00.765 0:40:40.774
CCEVTMGR 1296 8 22 202 2584 0:00:00.484 0:40:40.336
spoolsv 1460 8 14 144 3520 0:00:03.281 0:40:39.571
NAVAPSVC 1580 8 11 241 5648 0:00:11.937 0:40:39.071
NeTmSvNT 1616 8 7 74 844 0:00:01.203 0:40:38.805
NMSSvc 1668 8 6 136 1964 0:00:01.781 0:40:38.415
SAVSCAN 1724 8 7 60 8240 0:00:08.546 0:40:37.993
svchost 1768 8 8 135 3424 0:00:01.218 0:40:37.540
symlcsvc 1796 8 4 78 784 0:00:00.265 0:40:37.040
SymWSC 1904 8 8 254 7448 0:00:10.062 0:40:36.024
alg 240 8 6 105 1016 0:00:00.078 0:40:31.149
explorer 2740 8 11 325 11004 0:00:11.218 0:28:14.425
PROMon 3692 8 4 85 776 0:00:01.406 0:28:08.753
igfxtray 3764 8 1 58 1228 0:00:00.203 0:28:08.659
hkcmd 1156 8 2 67 1348 0:00:00.281 0:28:08.503
SOUNDMAN 3384 8 1 42 1708 0:00:00.031 0:28:08.409
CCAPP 1676 8 22 336 5092 0:00:04.156 0:28:08.347
NetTime 3716 8 2 33 744 0:00:00.203 0:28:08.284
iTunesHelper 3160 8 4 104 800 0:00:00.171 0:28:08.128
qttask 3144 8 2 38 500 0:00:00.125 0:28:08.066
iPodService 2220 8 6 112 1896 0:00:00.203 0:28:06.144
LUCOMS~1 3824 8 5 132 2244 0:00:00.578 0:28:04.925
cmd 3368 8 1 31 1928 0:00:00.578 0:05:26.631
msmsgs 4056 8 4 149 1176 0:00:00.156 0:00:17.109
pslist 3036 13 2 70 680 0:00:00.046 0:00:00.046

Netstat: Recently Windows has added the ability to show the process id (PID) of the process that opens a listening socket. That means the old netstat command can show the PID responsible for open sockets on a Windows system if passed the -o switch:

c:\>netstat -nao

Active Connections

Proto Local Address Foreign Address State PID
UDP *:* 4
UDP *:* 748
UDP *:* 1080
UDP *:* 1080
UDP *:* 1080
UDP *:* 1080
UDP *:* 1080
UDP *:* 748
UDP *:* 1000
UDP *:* 1160
UDP *:* 1000
UDP *:* 4
UDP *:* 4
UDP *:* 1160

You can get similar but not exactly the same output with Foundstone's Fport program:

FPort v2.0 - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.

Pid Process Port Proto Path
960 -> 135 TCP
4 System -> 139 TCP
4 System -> 445 TCP
240 -> 1025 TCP
1676 ccApp -> 1078 TCP C:\Program Files\Common Files\Symantec Shared\ccApp.exe

0 System -> 123 UDP
0 System -> 137 UDP
0 System -> 138 UDP
960 -> 445 UDP
4 System -> 500 UDP
240 -> 1031 UDP
1676 ccApp -> 1032 UDP C:\Program Files\Common Files\Symantec Shared\ccApp.exe
4 System -> 1033 UDP
0 System -> 1034 UDP
0 System -> 1035 UDP
0 System -> 1383 UDP
0 System -> 1900 UDP
0 System -> 4500 UDP

PsService: The last program I like to run shows the services that load under Windows. Only a few are shown for demonstration purposes:

PsService v2.12 - local and remote services viewer/controller
Copyright (C) 2001-2004 Mark Russinovich
Sysinternals -

Notifies selected users and computers of administrative alerts. If the service is
stopped, programs that use administrative alerts will not receive them. If this
service is disabled, any services that explicitly depend on it will fail to start.
WIN32_EXIT_CODE : 1077 (0x435)

DISPLAY_NAME: Application Layer Gateway Service
Provides support for 3rd party protocol plug-ins for Internet Connection Sharing and
the Windows Firewall.
WIN32_EXIT_CODE : 0 (0x0)

DISPLAY_NAME: Application Management
Provides software installation services such as Assign, Publish, and Remove.
WIN32_EXIT_CODE : 1077 (0x435)

Again, in a situation where you expect an intrusion, comparing new data to this baseline can help identify suspicious processes or services.

If you want to collect even more data, assume administrator privileges and run Listdlls. Listdlls displays all of the DLLs loaded on a Windows system.

If you're wondering how I identify potential intrusions on Windows systems, the answer is simple. One of the host-based steps involves "live response," or the collection of volatile information using certain Windows tools. My IR toolkit includes these and other tools. Quite often I can identify suspicious entries in records like those shown, and having a baseline in hand makes that job much easier. Of course, truly skilled intruders will use kernel mode rootkits to hide their presence. Under those conditions, other techniques must be applied.

Wednesday, October 13, 2004

Flash Sguil Demo Posted

The Sguil team just posted a trial version of our new Flash Sguil demo. There isn't any sound or text notes yet, but you can watch a user interact with the Sguil console on a Windows system. The user shows how to investigate alerts, generate transcripts, launch Ethereal, categorize events, and query for session data. The demo lasts a few minutes and shows some of what Sguil 0.5.2 can do. Provide any feedback to sguil-users at lists dot sourceforge dot net.

Article in Nov 04 Dr. Dobb's Journal

The November 2004 issue of Dr. Dobb's Journal features an Addison-Wesley-sponsored article I wrote titled Considering Convergence? (.pdf). I wrote it as an elaboration of thoughts I posted to focus-ids two months ago:

"I argue against 'convergence' between products doing 'detection' and those doing 'protection.' Too many people focus on detecting attacks when really they should be detecting failures in protection caused by poor access control, exposure of vulnerable targets, and misconfiguration.

This means the IDS remains a network audit device doing detection, and all products which filter, scrub, manipulate, or otherwise stop traffic be accepted as access control devices (aka 'firewalls') doing protection.

You can't have the same device do both functions. It's like a guard without a security camera thinking he's doing a good job when an intruder's already slipped behind him.

If any convergence should take place, it should occur within the detection market (signature/anomaly/flow/etc. network/host-based IDS) and separately within the protection market (XML/spam/SQL/etc. IPS/firewalls)."

Tuesday, October 12, 2004

Thoughts on Microsoft's Latest Security Bulletin

Microsoft's October 2004 security bulletin was released today. Some of the guys in #snort-gui were shocked that the bulletins ranged from MS04-029 to MS04-038. An astute Slashdot post notes that only one vulnerability, MS04-038, affects Windows XP SP2. The XP SP2 weakness is referred to as the drag-and-drop vulnerability as it allows intruders to install programs through malicious Web pages rendered by Internet Explorer.

This reminds me of a saying that I wish I could attribute to someone: "Q: What's the best security patch for Windows 2000? A: Windows XP." This is more than a joke. I have a difficult time being sympathetic to enterprises that continue to operate Windows NT 4 systems. I am beginning to lose faith in organizations that have no plans to upgrade their servers from Windows 2000 to Windows 2003. Let's remember that Windows NT was released in 1996 and Windows 2000 in the year 2000. An organization relying on an 8 year old Microsoft OS is not showing the proper appreciation for security, given Microsoft's track record.

I tried to imagine a situation where I've seen similarly old operating systems running in the free UNIX world. For comparison, FreeBSD 2.1.5 was released around the same time in 1996 and 4.0 just appeared in mid-2000. While the FreeBSD 4.x tree is just barely still marked STABLE (about to be replaced by the 5.x tree), I know of no one running FreeBSD 2.x or 3.x. For my Linux friends, the helpful Red Hat history site shows Red Hat 4.0 appearing in late 1996 and 7.0 in late 2000. While I know of no one running Red Hat 4.x, some people continue to run 7.0 (and should migrate probably migrate to 9.0, at least).

On the commerical UNIX side (ignoring Red Hat Linux), consider Solaris. This history shows 1996 as the year of Solaris 2.5.1 and 2000 as the year of Solaris 8. I imagine many organizations still run Solaris 2.6 and 7, and haven't given much thought to 8, 9, or the upcoming Solaris 10. The Solaris release page shows 2.5.1 is in the very last stages of support, while newer versions get better treatment.

Running an OS that can be kept current is one of the characteristics of what I call a defensible network in The Tao of Network Security Monitoring. A look at the Product Lifecycle Dates - Windows Product Family shows Windows NT 4 "extended support" will be "retired" on 31 Dec 2004. "Mainstream" support for Windows 2000 ends 30 Jun 2005 with extended support expiring 30 Jun 2010. According to Microsoft's Lifecycle Policy FAQ:

"Mainstream support includes all the support options and programs that customers receive today, such as no-charge incident support, paid incident support, support that is charged on an hourly basis, support for warranty claims, and hotfix support. After mainstream support ends, extended support will be offered for Business and Development software.

Extended support includes all paid support options and security-related hotfix support that is provided at no charge. Hotfix support that is not security-related requires a separate extended hotfix support contract to be purchased within 90 days after mainstream support ends. Microsoft will not accept requests for warranty support, design changes, or new features during the extended support phase."

I find it hard to believe Microsoft will extend security-related hotfixes for Windows 2000 for another five years. We've already seen concerns that security features introduced in XP SP2 will not appear in older versions of IE, despite Microsoft's spin of the issue. I expect to see more security enhancements to mainline Windows releases like XP and its successors, without concern for older versions of Windows, wherever Microsoft can get away with it.

If you're looking for a way to deploy Windows XP with SP2 integrated, check out AutoStreamer. It's a GUI which makes creating a custom .iso of Windows XP with SP2 very easy. I tested it this weekend and deployed Windows XP with SP2 on a new system without any problems. My deployment provided AutoStreamer with a Windows XP CD-ROM, a copy of xpsp2.exe obtained via CD-ROM from Microsoft, and plenty of hard drive space on an existing Windows system. When I was done I burned the new .iso to CD and used it to install Windows XP.

Playing with Hping3 alpha-2

O'Reilly recently featured an interview with Hping author Salvatore Sanfilippo titled Network Tool Development with hping3. Hping is a packet crafting tool with a long lineage. I recommend reading the interview if you'd like background on Hping and what the developer formerly known as antirez is doing. I downloaded hping3-alpha-2.tar.gz to a system running FreeBSD 5.3 BETA1 and gave it a try.

Before extracting and installing the new Hping3, you must have a Tcl interpreter installed. Tcl is required because Hping now works within a Tcl shell. It surprised me to see Tcl used in something other than Sguil. Here are highlights from the installation process:

fedorov:/home/hping3-alpha-2$ ./configure
build byteorder.c...
create byteorder.h...
===> Found Tclsh in: /usr/local/bin/tclsh8.4
system type: FREEBSD

MANPATH : /usr/local/man
TCL_VER : 8.4
TCL_INC : -I/usr/local/include/tcl8.4
LIBTCL : -ltcl84 -lm -lpthread
TCLSH : /usr/local/bin/tclsh8.4

(to modify try configure --help)
creating Makefile...
creating dependences...
now you can try `make'
fedorov:/home/hping3-alpha-2$ make
./hping3 -v
hping version 3.0.0-alpha-1
($Id: release.h,v 1.4 2004/04/09 23:38:56 antirez Exp $)

Here's what running Hping3 looks like. I followed some of the getting started tutorial. First I resolve a hostname and then I try to send an ICMP packet:

fedorov:/root# hping3
hping3> hping resolve
hping3> hping send {ip{daddr=}+icmp{type=8,code=0}}
Packet building error: 'Unknown keyword: 'ip{daddr''
in packet ip{daddr=}+icmp{type=8,code=0}

Notice how I got an error when I mistyped curly braces instead of parentheses. Below I fixed the error and sent a packet.

hping3> hping send {ip(daddr=,code=0)}

Next I receive a packet on the wire within Hping3:

hping3> hping recv em0

This packet is represented in Ars Packet Description (APD) format, a standard developed by Antirez. Check the Hping wiki for more information.

Thursday, October 07, 2004

Three Developments in Snort Community

Three noteworthy events have occurred in the Snort community during the last few weeks. First, Kevin Johnson has forked the ACID (Analysis Console for Intrusion Databases) project due to lack of formal releases by Roman Danyliw. Kevin announced his new Basic Analysis and Security Engine (BASE) project last month. I don't think ACID provides the information needed to collect, analyze, and escalate indications and warning to detect and respond to intrusions. For that, check out Sguil. The fork is good news for the people who use ACID and expect updates. From a community perspective, this BASE fork is a positive development allowed only by the open source nature of ACID. Trying forking a proprietary product!

Second, as discovered by Keith McCammon, another moribund project has been resurrected. Simon Biles has revived the Statistical Packet Anomaly Detection Engine (SPADE) project. SPADE is a plug-in for Snort. It appears in the Snort CVS tree as Spade-092200.1.tar.gz, although Spade-030125.1.tar.gz is the latest (as I reported in June.) It would be helpful to see SPADE work with the newest Snort releases.

Finally, the Bleeding Snort site has been relaunched as a security portal for Snort and Snort rule development. It has commercial sponsors, forums, and news. Bleeding Snort is best known as a central repository for new rules developed outside the official Snort and Sourcefire development community.

Tuesday, October 05, 2004

Ranum on Secure Code

I just read an interesting article by Marcus Ranum titled Security: The root of the problem. Marcus makes some very good observations:

"We're stuck in an endless loop on the education concept. We've been trying to educate programmers about writing secure code for at least a decade and it flat-out hasn't worked. While I'm the first to agree that beating one's head against the wall shows dedication, I am starting to wonder if we've chosen the wrong wall. What's Plan B?"

Marcus' "Plan B" is trying to add more security checking at compile-time, or at least pay attention to and address the warnings already output by compilers given the -Wall flag. In his words:

"I think that Plan B is largely a matter of doing a lot more work on our compiler and runtime environments, with a focus on making them embed more support for code quality and error checking. We've got to put it 'below the radar screen' of the programmer's awareness, just as we did with compiler optimization, the creation of object code, and linking. We've done a great job building programming environments that produce fast executables without a lot of hand-holding from the programmer. In fact, most programmers today take optimization completely for granted—why not software security analysis and runtime security, too? For that matter, why are we still treating security as a separate problem from code quality? Insecure code is just buggy code!"

I recommend reading the whole article and forming your own opinion on this matter, but I think Marcus' ideas makes good sense.

Latest Helix Release Features Sguil Client

I wrote about Helix in August. Helix is a Knoppix-based live CD. Drew Fahey at e-fense added the 0.5.2 version of the Sguil client to Helix. This means you can boot the Helix live CD and launch Sguil to connect to our demo server at

Although the client installation on UNIX is still difficult (due to the number of libraries and applications needed beyond most people's default installations), the Windows Sguil client installation is fairly simple. I documented the process for an older version last year, but the process is still sound.

Monday, October 04, 2004

Last FreeBSD 5.3 BETA Released

A few hours ago Scott Long announced the availability of FreeBSD 5.3-BETA7, the presumed last BETA in the 5.3 release cycle. The schedule has not yet changed to reflect this new BETA. Although only one release candidate (RC1) is planned, I would not be surprised to see a RC2 or maybe even RC3. Since FreeBSD 5.3 will be the first version of the 5.x tree marked STABLE, the release engineering team wants 5.3 to be the best FreeBSD version to date. I personally can't wait to deploy it on my laptop and servers.

One of the biggest changes in the current BETA is the replacement of BIND 8.x with 9.3. The release engineers felt that although it was late in the release process, they didn't want to have to support 8.x throughout the life of the FreeBSD 5.x STABLE tree. In other words, if BIND 9.x didn't appear in FreeBSD 5.3, BIND 9.x wouldn't be imported until FreeBSD 6.0. If you'd like to know more about this process, check out the thread from mid-September.

This decision highlights a difference between Linux and FreeBSD. When FreeBSD includes an application like BIND in the base system, it is imported. It isn't just downloaded and packaged with the distribution. This shows how FreeBSD is deployed as an operating system and not as a kernel with assorted userland tools (like Linux).

Of course some people might argue that keeping the "purest" deployment of an application like BIND, without patches for FreeBSD, is more effective. I share these sentiments when I see various Linux vendors deploying their own modified Linux kernels, making integration of default kernels from difficult.

Overall, however, I like the FreeBSD approach because the maintainers accept responsibility for the code they include in the base system. If you don't want to run the integrated version of BIND, you can run the version in the ports tree (dns/bind9/, for example) and modify /etc/rc.conf like so:

named_enable="YES" # Run named, the DNS server (or NO).
named_program="/usr/local/sbin/named" # path to named, if you want a different one.

This flexibility can become confusing when a program like OpenSSH is involved. OpenSSH is offered in three "flavors:"

1. OpenSSH is part of the base FreeBSD operating system.
2. OpenSSH exists as the security/openssh port. This version is like OpenSSH for OpenBSD due to the similarity between FreeBSD and OpenBSD's code.
3. OpenSSH exists as the openssh-portable port. This version is specifically for non-OpenBSD systems.

Confused? According to this thread, OpenBSD's lack of support for PAM means the OpenBSD native version (option 2) doesn't offer PAM. Since FreeBSD does use PAM, options 1 and 3 make use of PAM.

This means that if you want your OpenSSH authentication to use PAM on FreeBSD, you can use the OpenSSH integrated into the FreeBSD base (like using integrated BIND) or you can install the openssh-portable port (like using the BIND port).