The aim is to detect, if anyone in the HOME_NET is searching for "terrorism" and generate an alert. I am using Snort 2.9 installed in a virtual machine (VirtualBox) running Ubuntu 18.04.
This same qs was asked here but remains unanswered.
For testing purpose, HOME_NET is set as a single machine (192.168.30.102)
The created rule is as follows:
alert tcp $HOME_NET any -> any any (msg:"terrrorism content found"; content:"terrorism"; nocase; sid:10000002;)
This is referred from the excellent video by Dr. Philip Craiger here.
A few other variations also attempted as suggested here and here:
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"terrrorism content found"; content:"terrorism"; nocase; sid:10000002;)
alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"terrrorism content found"; content:"terrorism"; http_uri; sid:10000002;)
alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"terrrorism content found"; content:"terrorism"; http_client_body; sid:10000002;)
For testing, a simple google search was done in the web browser (firefox).
However no alerts are getting generated.
The rule to detect the word "HTTP" was executed properly:
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP found"; content:"HTTP"; sid:10000002;)
This is a fairly simple rule because 'HTTP' is the first word in the packet application data. However any variation of the previous rule as described above doesn't seem to be working. Alerts are not getting generated.
I would appreciate if anyone could point me in the right direction.
For future reference:
Google as well as most of the web search engines run via a HTTPS connection. Hence the application layer packets are encrypted and cannot be parsed by Snort.
Snort can be applied only to unencrypted packets.
Further detail regarding this can be found here.
Related
I need help with the following 2 questions to create rules for snort.
Generate an alert when network traffic that indicates Viber, is being used.
Alert for any packet of size > 100 bytes from the network 172.20.0.0 with SNM
255.240.0.0 designated to port 80.
a. Taken from https://commons.erau.edu/cgi/viewcontent.cgi?article=1477&context=jdfsl
The analysis carried out in the work covers upto latest version of Viber 6.2.2 and all re- sults were verified for both android and iOS platforms.
Viber usually communicates over UDP ports 7985, 7987, 5243 and 9785 for the voice calls
You will want to create, write rules that detect TCP and UDP traffic on these mentioned ports. for example.
So something like this then:
- alert udp any any -> $HOME_NET 7985 (msg: "Viber Traffic"; sid:10000001; rev: 1;)
b. Ensure your $HOME_NET is setup correctly in your snort.conf, ergo which subnets you want to have under "home" $HOME_NET.
- alert tcp 172.20.0.0 any -> $HOME_NET 80 (msg: "Traffic from the 172.20.0.0 addr"; dsize:>100;sid:10000001; rev: 1;)
I'm beginner in using map and I read reference guide in nmap homepage. When I read host discovery with -P* options I suddenly had question about it.
There are -PS option in nmap and it sends syn packet to server to determine server is turned on or not. If nmap gets ACK/SYN packet for three-way handshake then it means server is turned on. If nmap get RST then it means that server is shut down. If timeout occur then firewall is exist between server and user computer...
Nmap homepage guide book saids they give -PA option to give more change for bypassing firewall. I thought if we send ACK packet instead of SYN then server will send RST packet for response in both case. Server is turned on or not. If timeout occur then we can determine firewall is exist. So I think usage of -PA is check firewall instead of check server is turned on or not.
My question is that I'm not sure about above things. Because I'm not good at network yet and beginner in this area. Did I understand correctly?
For the -P* options, Nmap considers any response from the server to be an indication that the server is up. Both SYN/ACK and RST packets count, as do several types of ICMP response like Port Unreachable. The specific type of response may indicate the state of the port, and would be analyzed by the port scan (-s* options), but for host discovery, any response is as good as another.
Hi Im writing some custom rules for a university project and I wondered if anyone could check my rule for this vulnerability;
http://www.exploit-db.com/exploits/34517/
here is my rule;
alert tcp any any -> any 5466 \
(msg: "FTP command execution"; content: " / admin lua script html"; content: "POST"; http_method; content: "os execute";)
Revised rule; alert tcp any any -> any 5466\
(msg: "FTP command execution"; content:"/admin_lua_script.html"; content:"POST"; http_method; content: "os execute";)
I would recommend something like the following:
alert tcp any any -> any 5466 /
(msg:"FTP command execution"; flow:to_server,established; /
content: "POST"; http_method; nocase; /
content:"/admin_lua_script.html"; fast_pattern; http_uri;/
content:"command=os.execute"; http_client_body; nocase; /
metadata: service http;)
Explanation:
dest port 5466:
You should always specify a port when possible. When you have rules that are "any/any" for source/destination snort treats them differently than rules with ports defined.
Important: Since this exploit module runs over port 5466 and is http you NEED to make sure that this port is in your http preprocessor configuration for ports. Specifically, your snort.conf should have a configuration line similar to the following:
preprocessor http_inspect_server: server default profile all ports { 80 ... 5466 ...}
(obviously don't put the dots, just representing other ports you should have in there). If you do not have this port in your preprocessor config for http, all of your http content modifiers will NOT match because snort will not treat traffic on this port as http, which is likely the main issue you're having.
flow:to_server,established;
You only want to check established sessions where the flow is going to the server. This will be more efficient as snort won't have to check random traffic for unestablished sessions and it won't have to check traffic going to the client, since you know the direction for this exploit will always be going to the server. The only way the request would be successful would be if the connection was already established between client and server, if it's not the exploit won't succeed and it's pointless to alert on this.
content: "POST"; http_method; nocase;
You want nocase for the post match because it is not required by http for the method to be all capital letters.
content:"/admin_lua_script.html"; fast_pattern; http_uri;
Adding the fast_pattern option will make the rule more efficient as it will put it into the fast pattern matcher in snort. You know this content is static and never changing (case included) so this is eligible for the fast pattern matcher. Since this is the only content match in the rule that is case sensitive snort would put this into the fast pattern matcher on it's own, but if you modify the rule later on with another content match you would want this to be the content match to use for the fast_pattern matcher.
content:"command=os.execute"; http_client_body; nocase;
This is going to be in the client body, so add the http_client_body option.
metadata: service http;
If you are using target based (which now a days you should be), you need to add the service http keyword. Having this in the rule will no prevent the rule from triggering if you aren't using target based, so it's also a good practice to put this in if you know the service this traffic is.
Additional Note:Your custom rule sids should be 1000000 or above, anything below this is reserved for the snort distribution rules. See more on that here
i try to run snort as an IPS. so i install snort on ubuntu server via apt-get and config daq_type as afpacket and daq_mode as inline. and 2 interface like eth1:eth2
then i write a rule for test
reject tcp any any -> any any (sid: 1000005;)
it work but when i change it to
drop tcp any any -> any any (sid: 1000005;)
it does not work. and when i change action to sdrop the result is same.
and i install snort from source but the result was same.
can you help to to write true rule?
Snort can operate in three different modes namely tap (passive), inline, and inline-test.
If you want to use drop rules to drop packets you need to make sure that you are running in inline mode. From the looks of it you are probably not in inline mode. The reason "reject" is working is because it will send a reset for TCP, which will stop the rest of that stream, or it will send an ICMP port unreachable message back for UDP. See the following explanations from the snort manual (http://manual.snort.org/node29.html) on rule headers:
drop - block and log the packet
reject - block the packet, log it, and then send a TCP reset if the protocol is TCP or an ICMP port unreachable message if the protocol is UDP.
sdrop - block the packet but do not log it.
If snort is not running in inline mode it is not going to actually drop the packet(s), it will just generate an alert (for drop) and pass the packet(s).
See the following from the snort manual on the three modes: http://manual.snort.org/node11.html#SECTION00295100000000000000
Specifically, inline mode is described as follows:
When Snort is in Inline mode, it acts as an IPS allowing drop rules to trigger. Snort can be configured to run in inline mode using the command line argument -Q and snort config option policy_mode as follows:
snort -Q
config policy_mode:inline
You need to make sure the line "config policy_mode:inline" in is you snort.conf and when you are running snort you pass the "-Q" option. If both of these are not done it will not drop. Hope this helps!
i wanted to send a mensgem from my computer to the Port 2000 through my computer on my command line !?!
Someone help me ?
Thanks a lot !
In order to send a message you first must understand in what language is the port 2000 speaking and who you want to send a message.
First you should know with who you wanna speak (The IP address of the machine)
Second you should know if this machine will able to hear you (Is the port 2000 open?)
Third you should know what "language" is the port 2000 hearing (The protocol of the open port)
First scan it with nmap to check if the port is open (-p 2000) and what software it's running (-sV), then send a packet with netcat ("nc IP 2000" and then send the content).
That's all i can help you with the information you provided.
Regards
If by "command-line" you mean a unix-like system, then nc (short for netcat, sometimes also present under its full name netcat) is your friend. If you specifically meant the Windows command-line then there's the option of installing netcat as part of http://cygwin.com , or there's a port of nc to Windows as part of this project: http://www.brutman.com/mTCP/
You could also consider downloading PuTTY (or some other telnet client) since that's also a potentially good way of connecting to a port and typing arbitrary text at it.