![]() Reference - This section is for referencing a security database for more information on the attack. This rule is looking for traffic that has both the SYN and FIN flags set (SF) and in addition, has the two reserved bits in the flags byte set (12). As you know, TCP flags can be SYN, FIN, PSH, URG, RST, or ACK. In our example, the rule is triggered on traffic with or without an established TCP connection.įlags - This couplet checks for TCP flags. It can have a number of values including established (TCP established), not established (no TCP connection established), stateless (either established or not established), etc. In this case, Snort reports to the sysadmin "SCAN SYN FIN".įlow - This option allows the rule to check the flow of the traffic. Msg - This is the message that's sent to the sysadmin if the rule is triggered. This part of the Snort rule is comprised of a couplet with a keyword, a colon, and the argument. Now let's take a look at the part of the rule that falls between the parentheses. It can also contain specific ports, like 80, or a variable containing a list of ports. As with the EXTERNAL_NET, it can be set as a variable in the nf.Īny - This the destination port. $HOME_NET - This the destination IP address that the traffic is moving to. In this case, we are looking for traffic moving from the EXTERNAL_NET to the internal or HOME_NET. > - This is the direction of the traffic. This can set as a single port, multiple ports, or a range of ports. It can be set as a variable in the nf.Īny - This the source port of the malicious traffic. $EXTERNAL_NET - This the source IP or network of the malicious packets. Tcp - This the protocol of the traffic the rule is looking for. It's rather easy to see that any packet with these flags set must be an attempt to do recon on the system and the sysadmin should be alerted.Īlert - This the action. This scan sends TCP packets with both the SYN and the FIN flags set to attempt to determine what ports are open on the target system ![]() One of those scans is called a SYN-FIN scan. This rule is designed to detect scans by scanning tools such as nmap and hping3. This initial part of the rule is referred to as the header, and ours looks like this: Let's start by examining the first part of that rule from the beginning to the first starting parenthesis. If you ever wondered how your sysadmin knew you downloaded porn, now you know! We can see that these rules are designed to detect a variety of pornography. This is a rather old set of rules and most system admins no longer use it. This set of rules is designed to detect pornography on the wire. I'll be using kw rite, but you can use vi, gedit, leafpad or any text editor you prefer. ![]() The Snort rules files are simple text files, so we can open and edit them with any text editor. Each of these files contains a category of rules, some with hundreds of rules. Now, let's do a listing of that directory to see all of our rule files.Īs we can see in the screenshot above, there are numerous Snort rules files. We can see the Snort rules by navigating to /etc/snort/rules on our Kali or BackTrack install. The difference with Snort is that it's open source, so we can see these "signatures." These rules are analogous to anti-virus software signatures. Snort is basically a packet sniffer that applies rules that attempt to identify malicious network traffic. The more we know about Snort and other NIDS, the better we can evade them. I already did an introduction to Snort, and now I want to delve deeper to show you how the rules in Snort are designed to detect your intrusion. One the most common ways that system admins are alerted to an intrusion on their network is with a Network Intrusion Detection System (NIDS). Some people call this anti-forensics-the ability to not leave evidence that can be tracked to you or your hack by the system administrator or law enforcement. ![]() My recent tutorials have been focused upon ways to NOT get caught.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |