Recently, I've received a couple of emails about the Forensic Server Project (aka, FSP), seen it written up in the Helix 1.7 Beginner's Manual, and even seen it demo'd on the CERT VTE.
For a listing of sites that mention the FSP, go here.
Anyway, the one thing in common amongst all of these sites seems to be that the FSP is simply misunderstood. I talked about the FSP in chapter 8 of my book, but soon after the book was published, I made some updates to the tools, and released them as standalone executables (I compiled the Perl scripts with Perl2Exe).
So...what is the FSP? The FSP is a client/server architecture for effective, sound incident response procedures. The FSP, along with the client application (the First Responder Utility), provides a framework for quick, efficient, and effective data collection during incident response activities. The FRU can be run from a CD or thumb drive, and communicates via TCP with the FSP server component in order to get data off of a system.
Think of it like this...have you seen where netcat is used to get data off of systems? Each command is typed in by hand, or run via a batch file, and the output is piped out over netcat to a waiting listener on another system. The responder has to log each command entered, and do a lot of documentation manually. On the server end, the investigator either ends up with one huge file he must parse, or he has to shutdown and restart the listener for each new command.
The FSP, on the other hand, handles all that for you. The server component takes care of logging, hash generation (and comparison, if files are copied), timestamping of the logs, etc.
The FSP is also very flexible. The FRU runs off of ini files, which tell the application what commands to run, which Registry keys/values to collect, etc. With all of the necessary tools copied to the CD, the investigator create and choose from a variety of ini files, based on location, operating system, installed applications, etc. The ini file can be loaded on the CD or thumb drive, or run from a floppy or even a mapped drive.
So, yes, the FSP does require a little bit extra work in set up, but in providing the standalone executables, I've made that process MUCH easier. The flexibility simply can't be beat...there's no waiting for updates, as the FSP framework allows the investigator to run whichever third party tools she chooses.
There is still some room for improvement, though. For example, incorporating the ability to select files to be copied directly into the FRU. Another thing is the analysis suite...pulling together tools to parse and analyze that data that's collected.
Which brings me to something else that's beneficial about the FSP...it's written in Perl. A lot of folks may look at this and think "Ugh!" Well, being written in Perl, it's also open source. Which means that you can run the server component on just about any platform the supports Perl, and write your own client apps. The currently available FRU is the client for Windows, but clients can be written for Linux, the Mac, etc. And because the framework is open, you're not restricted to using just Perl. Use Python, Ruby, shell scripts...whatever you're most comfortable with.
So I guess I just added a couple of things to my ToDo list...a user manual, and a developer's manual.
Isn't a compiled perl script "dirty" when run on a target/comprimised system? Specifically, I recall that complied perl (I used an older version of ActiveState's perl-to-exe compiler) was "extracted" and then run and it left a footprint of garbage behind (.pll files and others). Is there a new way to create a statically-linked, stripped binary from perl that I am not aware of?
ReplyDeleteThe Perl2Exe compiler isn't the same thing as ActiveState's compiler. I've successfully run the FRU from a CD with no issues whatsoever...which wouldn't work if it had to write a file to the drive.
ReplyDeleteIf you're not familiar with Perl2Exe, you should check it out.