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!
Related
I am setting up some iptables to help protect against DDos attacks for a university assignment. Im using the OWASP broken wep application and i have found some rules that work and ive figured out majority of the rules i just cant find out what the -t means. for example:
Iptables -t mangle -A PREROUTING -m conntack –ctstate INVALID -j DROP
This option specifies the packet matching table which the command should operate on. If the kernel is configured with automatic module loading, an attempt will be made to load the appropriate module for that table if it is not already there.
The tables are as follows:
filter:
This is the default table (if no -t option is passed). It contains the built-in chains INPUT (for packets destined to local sockets), FORWARD (for packets being routed through the box), and OUTPUT (for locally-generated packets).
nat:
This table is consulted when a packet that creates a new connection is encountered. It consists of four built-ins: PREROUTING (for altering packets as soon as they come in), INPUT (for altering packets destined for local sockets), OUTPUT (for altering locally-generated packets before routing), and POSTROUTING (for altering packets as they are about to go out). IPv6 NAT support is available since kernel 3.7.
mangle:
This table is used for specialized packet alteration. Until kernel 2.4.17 it had two built-in chains: PREROUTING (for altering incoming packets before routing) and OUTPUT (for altering locally-generated packets before routing). Since kernel 2.4.18, three other built-in chains are also supported: INPUT (for packets coming into the box itself), FORWARD (for altering packets being routed through the box), and POSTROUTING (for altering packets as they are about to go out).
raw:
This table is used mainly for configuring exemptions from connection tracking in combination with the NOTRACK target. It registers at the netfilter hooks with higher priority and is thus called before ip_conntrack, or any other IP tables. It provides the following built-in chains: PREROUTING (for packets arriving via any network interface) OUTPUT (for packets generated by local processes)
security:
This table is used for Mandatory Access Control (MAC) networking rules, such as those enabled by the SECMARK and CONNSECMARK targets. Mandatory Access Control is implemented by Linux Security Modules such as SELinux. The security table is called after the filter table, allowing any Discretionary Access Control (DAC) rules in the filter table to take effect before MAC rules. This table provides the following built-in chains: INPUT (for packets coming into the box itself), OUTPUT (for altering locally-generated packets before routing), and FORWARD (for altering packets being routed through the box).
I have setup a simple HTTP java server running locally on port 8000. It simply prints a message "Hello world" when a request comes. When I try to ping it from the browser by running http://localhost:8000/test I get my message printed.
I want to get the same results from another computer that is not local. When I try to use my public IP lets say http:/43.xxx.xxx.xxx:8000/test (even from the same machine) I get an ERR_CONNECTION_REFUSED .
I probably suspect that has something to do with the firewall. Can anyone guide me a little more because I lack the experience?
Thanks in advance
You don't specify what host OS your server/firewall is running so I'll keep this generic...
Without knowing your application, it seems like the server is sending a reset (RST packet) when the first SYN packet shows up indicating that the port (on that interface [your external]) is closed. You can do a quick port scan from here (https://mxtoolbox.com/PortScan.aspx) if you don't have access to a remote machine to test with. Odds are, TCP/8000 will not be open.
If it is, in fact, closed, you'll have to look at the firewall that your host OS is running and find out how to allow TCP/8000 to your host. In a major firewall vendor, your rule would look similar to this:
Source: Any
Destination: Your Public IP Address
Service: TCP/8000
Action: Allow
Logging: Full
That being said, you mentioned this was a PC so look into "iptables" (if you're running *nix) or the Windows Firewall (if you're running Windows) on adding firewall rules (Unfortunately I just joined and can't ask questions/comments, yet).
If you really want to find out what packet is being sent, run a tcpdump on your external interface (let's say eth1) (assuming your remote IP is 1.2.3.4 and your home public IP is 4.5.6.7):
tcpdump -nn -vvv -e -s 0 -X -c 100 -i eth1 host 1.2.3.4 and host
4.5.6.7 and port 8000
Here you're looking for the SYN/SYN-ACK/ACK for a successful TCP negotiation or SYN/RST if there is a firewall rejecting (not dropping) the TCP stream to the port.
Once the port is open on the host OS firewall, take a look at the application to make sure it's configured properly. If this were a standard webserver, you could take a look at the configuration files for the "Allow from" directives to make sure that everyone can access the site. If this is a custom application that you've created, you'll have to check this yourself.
I finally solved my problem. I needed to open a forwarding port in my router that maps my local ip address to the public. My router is TP Link so this what I did:
http://www.tp-link.com/us/faq-72.html
Also in order for this to work every time and not to have to reconfigure this every time I reconected to the router (because I get a new local IP), I have created a static local ip for my server following this guide:
http://www.tp-link.com/us/faq-182.html
Thanks for all the replies.
I am using OpenWRT router. I need to block a URL or multiple URLs (Not IP) for specific time. for example, I want to block facebook.com so that clients of this router cant access the website. firewall rules should have the option to do that but I dont know how to do that.
Here is one way to block by domain name rather than by IP address.
The main reason of why you need such a complicated method is that each domain name (e.g. facebook.com) may be resolved as different IP address at any given time. So, we need to keep a list of resolved IP addresses and add iptables rules based on this list.
First, you should enable logging in dnsmasq config:
uci set dhcp.#dnsmasq[0].logqueries=1
uci commit dhcp
/etc/init.d/dnsmasq restart
This will give you log entries like:
daemon.info dnsmasq[2066]: reply facebook.com is 31.13.72.36
Now, you just have to constantly parse syslog and add corresponding iptables rules like this (note that you most likely need a more versatile script and ipset for better performance):
logread -f | awk '/facebook.com is .*/{print $11}' | while read IP; do iptables -I OUTPUT -d $IP -j DROP; done
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/
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