I am new to snort so hope you can help me out. I am trying to create my own rules in snort via the local.rules file. I have snort installed on Windows 7 via Virtual box. My configuration seems to be working fine as I can test it with the string -T and it works fine. Also when I run the first three simple rules in the attached screenshot entitled snort rules they work fine, my problem is when I try to right a specific rule which in this case is to log when bit torrent is download the rule is triggered but I am getting all these http_inspect errors. Not sure what they are and if I am missing something in the snort.conf file. I have not touched the preprocessor settings in snort.conf. The errors I get are also attached in the screenshot Snort Output. The rule syntax I am running is snort -i 1 -c c:\snort\etc\snort.conf -A console. The rule is getting logged in the log folder and also I attach the wireshark output. Any help on this would be much appreciated.
Thanks
Garreth
The messages from http_inspect are not errors with your config or errors at all, they are messages from preprocessor rules that are triggering from the traffic. Specifically rule 120:3:1 (GID = 120, SID = 3, REV = 1). The GID 120 rules are specific to the http server inspection from the http preprocessor. This rule generates an event when the http_inspect preprocessor detects anomalous network traffic. The message for this rule is "NO CONTENT-LENGTH or TRANSFER-ENCODING". What this rule is looking at is the server response headers. It's likely alerting because there was no "Content-Length" header or there was no "Transfer-Encoding" header in the response header.
Here is an example of http server response headers:
accept-ranges:bytes
content-length:67023552
content-type:application/x-apple-diskimage
date:Thu, 10 Mar 2016 05:32:31 GMT
server:downloads
status:200
There should always be a content-length header in the server response because it tells the client how much data there is for this request. When the actual length of the data is different than what is presented in the content-length header the client should discard it and throw an error. If there is no content-length header the client has no idea how much data is about to be sent and there is no way to validate that it got all of the data for this request. If this header is missing from the server response snort will generate the rule you are seeing because this is anomalous traffic. It could also be missing the transfer-encoding header. In the example above you'll notice there is not transfer-encoding, so snort would generate this rule if the server response headers looked like the above. The transfer-encoding header is not in a lot of http responses, and this is normal. I believe that these rules are generated when you have the "extended_response_inspection" and the text rules are set to alert (do you have a preprocessor.rules file snort is picking up, or is this rule in any of your rule files?). This option is explain in the snort manual for the http server configuration options. If you don't care about these alerts you can remove the gid rules from your rules files. If you do not have these rules in your rules files then you can add the "no_alerts" option to the http server config. From the snort manual for this option:
"This option turns off all alerts that are generated by the HTTP Inspect preprocessor module. This has no effect on HTTP rules in the rule set. No argument is specified."
You can also remove the extended_response_inspection options from the http config if the rule is being generated by that option.
looks like your tcp config is missing the client/server/both
keyword between ports and 80. Consequently, 80 is being lost and
reassembly is set to both for 8080 only. Change to this in config file:
preprocessor stream5_tcp: policy first, ports 80 8080
This means that every HTTP port needs to be listed in the stream5_tcp preprocessor and that this is not
enforced.
For more info on setting up snort, please go through the following links:
https://www.talentcookie.com/2015/05/snort-how-does-it-work/
https://www.talentcookie.com/2015/05/snort-an-open-source-ids-in-freebsd-10-or-above/
https://www.talentcookie.com/2015/10/snort-performance-is-your-snort-working-fast-enough/
Related
I know this is somewhat specific of a question, but I'm having a problem I can't seem to track down. I have a single pod deployed to EKS - the pod contains a python app, and a varnish reverse caching proxy. I'm serving chunked json (that is, streaming lines of json, a la http://jsonlines.org/), and it can be multiple GB of data.
The first time I make a request, and it hits the python server, everything acts correctly. It takes (much) longer than the cached version, but the entire set of json lines is downloaded. However, now that it's cached in varnish, if I use curl, I get:
curl: (56) GnuTLS recv error (-110): The TLS connection was non-properly terminated.
or
curl: (56) GnuTLS recv error (-9): A TLS packet with unexpected length was received.
The SSL is terminated at the ELB, and when I use curl from the proxy container itself (using curl http://localhost?....), there is no problem.
The hard part of this is that the problem is somewhat intermittent.
If there is any advice in terms of clever varnishlog usage, or anything of the same ilk on AWS, I'd be much obliged.
Thanks!
Because TLS is terminated on your ELB loadbalancers, the connection between should be in plain HTTP.
The error is probably not coming from Varnish, because Varnish currently doesn't handle TLS natively. I'm not sure if varnishlog can give you better insights in what is actually happening.
Checklist
The only checklist I can give you is the following:
Make sure the certificate you're using is valid
Make sure you're connecting to your target group over HTTP, not HTTPS
If you enable the PROXY protocol on your ELB, make sure Varnish has a -a listener that listens for PROXY protocol requests, on top of regular HTTP requests.
Debugging
Perform top-down debugging:
Increase the verbosity of your cURL calls and try to get more information about the error
Try accessing the logs of your ELB and get more details there
Get more information from your EKS logs
And finally, perform a varnislog -g request -q "ReqUrl eq '/your-url'" to get a full Varnishlog for a specific URL
Breif Description of what I am trying to accomplish. So I am working with Crestrons Simpl+ software. My job is to create a module for a sound masking system called QT Pro. Now, QT Pro has an API where you can control it via HTTP. I need a way to establish a connection with the QT Pro via HTTP( I have everything I need, IP, Username, Password).
Whats the problem? I have just started working with this language. Unfortunately there isn't as much documentation as I would like, otherwise I wouldn't be here. I know I need to create a socket connection via TCP on port 80. I just don't know what I'm supposed to send through it.
Here is an example:
http://username:password#address/cmd.htm?cmd=setOneZoneData&ZN=Value&mD=Value
&mN=Value&auxA=Value&auxB=Value&autoR=Value
If I were to put this into the URL box, and fill it in correctly. then it would change the values that I specify. Am I supposed to send the entire thing? Or just after cmd.htm? Or is there some other way I'm supposed to send data? I'd like to stay away from the TCP/IP Module so I can keep this all within the same module.
Thanks.
You send
GET /cmd.htm?cmd=setOneZoneData&ZN=Value&mD=Value&mN=Value&auxA=Value&auxB=Value&autoR=Value HTTP/1.1
Host: address
Connection: close
(End with a couple of newlines.)
If you need to use HTTP basic authentication, then also include a header like
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
where the gibberish is the base64-encoded version of username:password.
But surely there is some mechanism for opening HTTP connections already there for you? Just blindly throwing out headers like this and hoping the response is what you expect is not robust, to say the least.
To see what is going on with your requests and responses, a great tool is netcat (or telnet, for that matter.)
Do nc address 80 to connect to server address on port 80, then paste your HTTP request:
GET /cmd.htm HTTP/1.1
Host: address
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Connection: close
and see what comes back. SOMETHING should come back. (Remember to terminate with two newlines.)
To see what requests your browser is sending when you do something that works, you can listen like this: nc -l -p 8080.
Then direct your browser to localhost:8080 with the rest of the URL as before, and you'll see the request that was sent. (Then you can type back to see how the browser handles the response.)
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!
For example http://www.utorrent.com/testport?port=12345
How does this work? Can the server side script attempt to open a socket?
There are many ways of accomplishing this through server-side scripting. As #Oded mentioned, most server-side handlers are capable of initiating socket connections on arbitrary ports, and most of those even have dedicated port-scanning packages/libraries (PHP has one in the PEAR repository, Python's 'socket' module makes this type of tasks a breeze, etc...)
Keep in mind that on shared host platforms, socket connections are typically disabled for security purposes.
Another way that is also very easy to accomplish is to use a command-line port-scanner such as nmap from your server-side script. i.e in PHP, you would do echo ``nmap -p $port $ip\
The server side script will try to open a connection on the specified port to the originating IP.
If there is no response (the attempt will timeout), this would be an indication that the port is not open.
The server can try, as #Oded said. But that doesn't ensure the receiver will respond.
Typically, something like this happens:
The URL request contains instructions about which port to access. The headers that your browser sends include information about where the request is originating from.
Before responding to the request, the server tries to open a port and checks if this is successful. It waits a while before timing out.
The webpage is rendered dynamically based on the results of this test.
The response is returned to you containing the results.
Sometimes steps (2) and (3) will be replaced with an AJAX callback, which allows the response to return sooner.