With Sourcefire ASA software modules we are able to control what file types are allowed and what are not to be downloaded or uploaded. What can be tracked depends on protocols supported by the Sourcefire and the direction of file transfer can be upload, download or both, again depending on the supported protocols.
Before we go any further, in order to utilize file detection and/or blocking, we have to have a valid license. This license is named AMP and more about this can be found here.
Now, with a valid license, we can’t do whatever we want. Currently, with the version of 5.3.x of the Sourcefire, we can play with the following supported protocols:
And we can only check for files within regular, non-encrypted versions of these protocols. With this ASA version of Sourcefire, at least. On regular Sourcefire appliances we can decrypt HTTPS traffic, for example, check the files within that protocol, and then re-encrypt the traffic and send it on its way. Without user knowing anything. But we cannot do that with the current version of Sourcefire on the ASA software module. It should be available to us soon.
For some of these protocols we can watch for files in both directions, upload and download, for example for FTP, but for some, it makes sense only for uploads, for example with the SMTP.
What we can detect is also limited, but in time the number of supported file types should increase. For now, we can detect the following file types:
- System files (ISO, PCAP, REG, VMDK, …)
- Graphics (BMP, PSD, …)
- Encoded (UUENCODED, …)
- PDF files (PDF, EPS, …)
- Executables (MSEXE, MSI, ELF, RPM, …)
- Multimedia (FLV, MIDI, WAV, MP3, …)
- Archive (ZIP, RAR, MSCAB ,…)
- Office Documents (XLSX, DOCX, ONE, PST, …)
Important thing to note about Sourcefire file detection engine is that it is not extension dependable. This means that the Windows executable will be detected based on its structure not its extension. So if we changed the extension from .EXE to .EEX, or even delete the extension, the file will still be detected as Windows executable. Same goes with other file types.
So, why would we do such thing as detecting and blocking files? Well, for several obvious reasons:
- Our security policy does not allow transfer of any kind of executable files. Period! They are nothing but bad idea. Viruses, trojans, spyware, …
- Although Sourcefire is not considered to be a DLP product, we can save any Office document going out and see if we are leaking information. Not to mention that Office documents can also be a carrier for some sort of malware
- The office is no place for playing videos or listening music, so we can block these files as well
Now when we know the basic idea behind this, let’s create our security policy with regard to file checking, so that the policy meets the following requirements:
- We are concerned only about SMTP, FTP and HTTP protocols
- For SMTP protocol, we will check file uploads in such way that we
- Check if the file is malware and if it is, we drop it and save a file for further analysis
- If we are not certain if the file is malware or not, we will send it to the cloud for sandbox analysis
- We will drop the executable files with no inspection. We don’t want them at all
- For all other supported files, we will check them, as described
- For HTTP protocol, we will do the same, but in both directions
- We will treat FTP transfers the same way as HTTP
Let’s begin with SMTP file policy. Under “Policies->Files->New File Policy” we begin creation of our policy. We give this policy a name, for example, “WP FILE POLICY SMTP“. Now we click “Add File Rule” and an “Add File Rule” dialog box opens. We fill it in based on our defined security policy for SMTP:
Please note that we selected all files but Executables, then clicked the Add button. For the protocol we selected SMTP, for direction Upload and for the action “Block Malware” with sub options of “Dynamic Analysis“, which will send unknown files to the sand boxing analysis, and “Reset Connection“, which will terminate this SMTP session if the malware is going through it. We also selected to store malware files on the module for further analysis. We then click Save.
Now we repeat the process only for executable files:
For these file types we don’t want to waste any resources, we simply drop them.
Now our SMTP file policy looks like this:
We saw two options for actions on files: “Block Malware” and “Block Files“. We can also select “Detect Files“, which only logs the event on the Defense Center, and “Malware Cloud Lookup“, which will send the file to the cloud for sand boxing analysis. We should have in mind that sending the file for analysis still allows the file to pass through. These are our options for dealing with files:
Looking at our SMTP file policy, we can see two rules and two warnings. Let’s hover over these warnings and decode them (hover-over! Sweet 🙂 ):
So, “Warning 2” says: “Malware lookups won’t occur on MSEXE files because the rule marked with ‘Warning 1’ will block these files.”
And the “Warning 1” says: “This rule will block malware lookups on MSEXE files for the rule marked with ‘Warning 2‘”.
This is ok. The system is warning us that it won’t send any executable files to the cloud analysis because we are dropping them. Exactly what we want.
With file policies, the rules are not evaluated in the order they are listed, but rather in order of restrictiveness (is this a valid word?). So, most restrictive action will be carried out first. The order is:
- Block Files
- Block Malware
- Malware Cloud Lookup
- Detect Files
Now it’s good time to say something about file white lists and blacklists. We have these like we have them with Security Intelligence. The are called:
- Clean List, represents files that are ok with as in any case (aka white list)
- Custom Detection List, is just the opposite (aka black list)
So, files which are listed in “Clean List” are not going to be inspected by file rules and will be allowed. Files from “Custom Detection List” won’t be inspected either, but they are to be blocked. If we have two lists, which one takes precedence? Guess what? The “Clean List” or white list. So if we had a file with the same SHA-256 value in both lists, the file will be allowed. This is something we should have in mind, because with the security intelligence, black list wins over white list.
We cannot specify our custom file lists and the two defaults can be found in “Objects->File Lists“.
We now have our SMTP file policy. Let’s create HTTP file policy:
The only difference between this and SMTP file policy is that we check both direction in this policy.
The FTP file policy is just as easy to create as two previous file policies. Important thing to note about inspecting files transferred through the FTP protocol is that while we create an access control policy rule for FTP, we have to include both FTP and “FTP Data” protocols.
After creating each file policy, we have to save them and apply them to access control policy.
One way of doing this is to create one access control policy rule for each protocol and attach a file policy to it. Let’s create very broad access control rules:
We know how to create access control rules. The difference between these rules is in protocol being matched and file policy being applied. For HTTP, within the Application tab, we selected HTTP, and within the Inspection tab, we attached appropriate file policy:
Likewise, for SMTP:
And finally, FTP:
Again, for FTP access control policy rule, we have to include both FTP and “FTP Data” protocols. We should remember this.
It’s time to apply our access control policy to our device(s) and do some testing …
First, we will download legitimate file putty.exe using HTTP. Based upon our settings, this file should be blocked. Indeed, the file is blocked, which can be verified in our file events log under “Analysis->Files->File Events“:
By clicking this file event, we open another windows with more details:
From the above screenshot, if we click red squared icon, we would go to the file trajectory window. This is very good place for security engineer to be. Here we can see lots of details regarding this file download event. Because I have dealt with this executable before, there is lots of details to explain, so let’s begin.
With number one, the SHA-256 sum is marked. This is how Sourcefire identifies individual files. With number two, we can see that this file had two names so far, putty.exe and putty.doc. The extension does not matter, it’s still the same file type and the same file, identified with this SHA-256 sum. This is pretty awesome thing. No matter how the file name and/or extension got changed, it’s still the same malicious file. The number three indicates the type of file and number four gives us a file disposition, which is clearly a malware. By clicking the yellow pencil icon, we can add this file to either “Clean List” or “Custom Detection List“.
On the right hand side of the “Network File Trajectory“, we can see that our Sourcefire first saw this file on June the 18th and it came from 22.214.171.124. We saw this file 13 times so far and last time we saw it on July the 9th from 10.x.y.43. This file was delivered to two our hosts from total of four servers. Total of five hosts were involved in spreading this file. Nice info.
In the middle of this screen we can see graphical view of this file spreading through our network:
This part of the screen is pretty cool. We can see from which host to which host and when this file was seen. We can see the file direction, as well as its disposition at that specific moment. We can click on any host or any icon on this diagram to see the file trajectory. For example, if we click the green circle marked with number one, we would get:
We can see that, at the 12:22 on July 7th, this file was received on host 10.x.y.1 from 126.96.36.199 and at that time, it was marked as clean. As we can see later on July the 8th, this disposition has changed. Typically the disposition changes from Unknown to Clean or Malware, but this illustration is good enough for understanding the process. If we hover over (hover-over 🙂 ) one of two selected green circles, we can see more information:
Finally, on the bottom of the screen we can see all events related to this file, sorted by the time the file was seen. This lists gives us the same info we have already seen.
This “Network File Trajectory” is a perfect way of detecting a malware spread. Where, when and how it got introduced to our network and how it got spread. We now have enough information to proceed with our remediation.
I owe you guys a small explanation. I explained this file trajectory on a file that I was playing with for a while and hence this many occurrences of this file. If I was playing with a file that my Sourcefire did not see before, we would see that the file is blocked and there would be no network file trajectory info. But this way I got a chance to explain a little bit the network file trajectory capability of Sourcefire.
Ok, we got this working. Let’s now try downloading some Office Word document from our server and see the result:
We can see that, at this time, this file has a Disposition of Unknown and that the file is sent to the sand boxing analysis. Important note here is that while the file is sent to the cloud for analysis, it’s still downloaded to the client. If later it turns to be a malicious, its disposition will change and we will see that on “Network File Trajectory” page, and then we can take corrective measures. For now, the file trajectory looks simple:
After cloud analysis returns the verdict, the file disposition should change. In our case it should turn from Unknown to Clean.
We saw how we can view individual network file trajectory info. We could see the summary of all files gone through the Sourcefire by going to “Analysis->Files->Network File Trajectory“. Here we can see all files seen so far and by clicking on a SHA-256 link, we can go to individual file trajectory.
Now I realized that I could go with this forever, but unfortunately I don’t have that much time. So, I will stop here and continue next time with other cool features of Sourcefire product. Stick around.