No, the Policy Compliance module was not built to be a DLP (data leak prevention). Does that mean we can’t use it like one? I had a clever customer bring a scenario to my attention. They have 120 print servers running Solaris. The Solaris platform normally stores all the files dynamically in the “/var/spool/lp” directory (no different than most print spools). You might know Qualys is not able to read dynamically created files. This of course is because we have no idea what the file might be named in the sequence (file1, file10, fileABC).
So how do I get around this issue on my printers? A static data-rich file in another folder becomes very interesting: “/var/lp/logs/requests”. This file contains all the history that that print spooler is storing. Most Unix platforms (FreeBSD, OpenBSD, and Solaris) use this same file as the history log for all print jobs on the system.
What does this mean for using Qualys to check print history? It’s easy to imagine how a user defined control (UDC) could search through your printing history for any unusually named files, users, or even descriptions. Let’s examine some of the options you can read in this file.
(Thanks to our friends at Oracle http://docs.oracle.com/cd/E19455-01/805-7229/printref-36/index.html):
# tail requests
= slw2-20, uid 200, gid 200, size 5123, Tue Jun 17 10:16:10 MDT
The table below shows the lettercodes and the content of their corresponding lines in the LP requests log.
Table 8-4: Letter Codes in the LP requests Log
Content of Line
The separator line. It contains the following items: request ID, user ID (UID), and group IDs (GIDs) of the user, the total number of bytes in the original (unfiltered) file size, and the time when the request was queued.
The number of copies printed.
The printer or class destination or the word any.
The name of the file printed. The line is repeated for each file printed; files were printed in the order shown.
The name of the form used.
One of three types of special handling: resume, hold, and immediate.
The type of alert used when the print request was successfully completed. The type is the letter M if the user was notified by email or W if the user was notified by a message to the terminal.
The printer-dependent -o options (for example, nobanner).
The priority of the print request.
The list of pages printed.
A single-letter line that is included if the user asked for "raw" processing of the files (the lp -r command).
The character set, print wheel, or cartridge used.
The outcome of the request, shown as a combination of individual bits expressed in hexadecimal form. Several bits are used internally by the print service. The bits and what they mean are describe in the table below.
The title placed on the banner page.
The type of content found in the files.
The name of the user who submitted the print request.
The slow filter used for the print request.
The list of special modes for the print filters used to print the request.
The printer used for the request. This printer differs from the destination (the D line) if the request was queued for any printer or a class of printers, or if the request was moved to another destination.
Using this new-found knowledge we could for example want to know if Bill in accounting (who was walked off campus last week) was printing tax forms. Using Qualys we could make sure he didn't print in build B where he normally works in building A. I can regex for files named “accounting”, “taxes”, “financial statement”, “salaries”, and many other key words you might be interested in. Luckily for us the default settings are to only roll this file over every so often to results, making this daily check very effective. Most of the research I reviewed indicates they rarely cycle unless you hit a size limit within the config or create your own cron job. Even if they are moved to another directory that’s just another user-defined control for results and results.
I recognize this does not help us look within the contents of the documents. This of course would require you to configure your printer to use static names (not impossible) as well as not clean them out as soon as there finished. This is generally considered a bad practice in the world of print administration and you’re likely to get shut down by your IT group. The history file on the other hand has been recognized as the first place to go for troubleshooting and unlikely removed. Even though it’s not a true DLP solution, it is a nice quick wayto search hundreds or even thousands of print spoolers for names of interest or users that should not be printing.
Let me know if you have any questions. Have fun and happy hunting.
Ever want a good US social security number regex? See below this one has worked for me. I know it’s nothing fancy, but it gets the job done. Lets hope nobody names a file with a SSN in it, but I have seen crazier things.