Up until this point we relied on Cisco/Sourcefire to provide us with signatures that will protect our network. But, at some point in our IPS expert career the need will arise to create our own signatures. This time we will create a signature with the “IPS Signature Editor“.
First, let’s recall our topology:
We are protecting the laptop on the left hand side from bad guys coming from dark cloud on the right. We are going to attack our laptop.
Let’s come up with a scenario: the attack emerged that uses UDP/2015 port as a destination, because there is some vulnerable service listening on that port. Because this service is not so common, up to now there is no signature for it. The attack is carried out by sending the hex string “53 6f 75 72 63 65 66 69 72 65” to the victim. This hex string is actually a text Sourcefire. We need to create the signature that will detect UDP packets with this payload and drop them.
Before we do that, we must come up with a solution that tests our connectivity before we create our signature. There are several applications that can aid this effort, such as PackETH, TcpClientServer, UdpClientServer, … For the sake of this blog, we will use UdpClientServer. This application is used for testing connectivity from some point in our network to another point. We should install this application on our laptop and run int as a server, and also install it on the attacker PC, from which we will carry the attack. The installation is pretty straight forward.
On our laptop, we start it up and set it to act as a server. We select the interface and listening address, as well as port. We then click “Start Server” button:
Now our server (in this case laptop) is ready. Let’s go now to our test PC and start UdpClientServer. We select the interface we will be using for sending data, the IP address of our target server, or the victim, and the port number:
In order to try this, on our test PC in the Send edit box we type in our attack string, which is Sourcefire. We then click “Send Text“:
After we click the “Sent Text“, we go the our victim and check out our Receive field:
So our test worked. Before we create our IPS rule that will prevent this, we will create an “Access Control Policy” rule that will allow this kind of traffic and we will change this ACP rule in a way that we will attach the IPS policy to it. Our ACP rule should look like this:
We placed this rule at the top of our access control policy, and make it allow the traffic through. Remember, if we made it block the traffic, we could not attach the IPS policy. After we commit our changes, we try our connection again and check the result on the “Defense Center“:
We can see the the event is logged and further to the right we can see what policy and what rule matched.
Now we are ready to create our IPS rule…
We can create our IPS rule inside our current policy and apply that policy to our “Access Policy Rule“, like we did with that CWD ~root IPS rule. But, we already know how to do this. Let’s create an “empty” IPS policy and within that policy, we will create our rule.
Let’s go to “Policies->Intrusion->Intrusion Policy” and click “Create Policy“:
We gave it a name and description and selected that no rules should be active. We want to dedicate this policy only for our custom service. We click “Create and Edit Policy“:
We can see all zeroes. No rules active in either layer. This is kinda empty policy. It is not actually empty, but rather all rules are disabled.
Now we are going to create our custom IPS rule. Let’s go to “Policy->Intrusion->Rule Editor“. We will focus on “Local Rules” category, because these are the ones we create. We have no custom rules created so far. We click “Create Rule” at the top right:
The “Create New Rule” dialog needs to be filled in. We type the Message text in, select Classification, Action, Protocol, Direction, “Source IPs“, “Source Port“, “Destination IPs” and “Destination Port“:
Under the “Detection Options” we select content and click “Add Option“. We can now specify the string we are hunting and other parameter regarding this search. More about this later. For now, in the content field we type sourcefire. Because original scenario stated that the attack string is Sourcefire (with the capital S), we can type exactly Sourcefire (upper case S), or sourcefire (lower case S) with the option “Case Insensitive“:
We click “Save As New“. We can see that the new rule created with the 1:1000000:1 designations. These are GID:SID:REV, “Generator ID“, “Signature ID” and Revision. For now we need to remember that for custom rules GID is always one, SID begins with one million and the REV is revision number for this rule, beginning with one. If we go back to the “Rule Editor” we can see our newly created rule:
Let’s navigate back to our “WP CUSTOM POLICY” IPS policy, under “Policy Layers->My Changes->Rules“, under Category we select local and we can see our rule:
We can see that our rule is not enabled. So, we select it, click “Rule State” and select “Drop and Generate Events“:
Now our rule is active:
We have a yellow warning sign next to “Policy Information“:
We click there and then “Commit Changes“. Let’s go back to our policy, and click “Policy Layers“. As we learned so far, our custom rule is placed in the top “User Layers” layer, in this case “My Changes“:
Finally, we need to attach this IPS policy to our “WP CUSTOM IPS SIGNATURE” within the “WP TEST POLICY” access control policy” rule:
We save and apply our “Access Control Policy” changes.
Now it’s time to test our application again. We start UdpClientServer in server mode on our laptop, and start it in client mode on some PC in the outside network. Now if we type in Sourcefire text on the client side and click “Send Text“, we should not get that text on the server side. This is because our IPS rule detected and prevented this attack. Some other text should go through. Let’s verify that under “Analysis->Connection->Events“:
We can see that the connection is dropped and the reason is “Intrusion Block“. This can also be viewed by going to “Analysis->Intrusion->Events“:
Indeed, this is our triggered rule. By clicking the event we can dive deep into it. We can see that the Priority is low, the Impact is three and the “Inline Result” is drop, which is represented with the black down arrow:
By selecting the event (click the check box) and clicking View, we can investigate even further:
We can see what signature triggered, when, from where and where to. Also we can see who is the attacker and who is the victim, what policy and what rule triggered this event. Finally we can see the Snort rule as if it were written in text. Yes, Sourcefire does use Snort engine 🙂
At the bottom of this page we can see the whole frame or packet captured from the network. This is the packed which triggered the event. We can use this information to further investigate the issue, or even save the packet in the PCAP format and open it with Wireshark. We can see the string that caused this event to trigger:
At the end of this blog, I would like to point out to another way to test our rules. It is very nice tool for testing the Snort rules and learn a lot about creating them without using the wizard. Before we wrap this blog up, here is our packet written in PackETH or loaded in PackETH from PCAP file downloaded from our “Defense Center“:
Once we prepare the packet this way, we select the interface to use and click Send:
If we choose to test our rules with the PackETH (which is far more powerful tool for such testing than UdpClientServer or TcpClientServer), we must use it from a Linux box. Although there is a version for Windows, in my testings it was creating faulty packets which were dropped by the ASA before they even made it to the SFR. We will deal with PackETH and creating Snort rules some other time.
Well, I guess that’s all for now. Stay tuned for more…
Thanks for reading!