I'm stuck on an Immersive Labs question (4 days now) and I'm banging my head off the keyboard. The question is 'Create a Snort rule that looks for an HTTP method ‘GET’ and contains ‘gif’ in the URL'.
This is what I have written but it's wrong and I can't see why?!:
alert tcp any any > any 80 (content: “GET”; http_method; content:”gif”; http_uri; sid:1000001; rev:01;)
Am I a million miles away? Am I close? Is it the syntax? Please help!
I was also stuck on this one. The solution requires a signature that looks for bi-directional traffic I found so yes you were very close 🙂
alert tcp any any <> any 80 (msg:"test";sid:1000001;content:"GET";http_method;content:"gif";http_uri;)
Related
I am trying to create a simple rule to alert when "MZ" are the first two characters in the HTTP body.
My current rule is:
alert tcp any any -> any any (msg:"Test"; content:"MZ"; depth: 2; http_client_body; sid:51; rev:1;)
But this finds no results despite "MZ" definitely being present in the HTTP body.
Assistance much appreciated.
After seeking assistance from a few other sources, it turns out I was asking snort to look in the wrong place:
The correct rule is below:
alert tcp any any -> any any (msg:"Test"; file_data; content:"MZ"; depth: 2; sid:51; rev:1;)
Instead of http_client_body after the content string, the rule needed file_data before the content string.
http_client_body = the request body
file_data = the response body*
(*It's more complicated than that, but this is sufficient to explain this case. Please see the Snort documentation for further reference)
I asked alot of questions about "how i get HTML code with sendind Get packet" and no one knows the answer:
I dont get HTTP answer with sr function. Just an ACK
Why when i send Get Requewst, i got the Ack and not the html code? scapy
Then i found somehow the function "sndrcv()" and i think its what i need.
(I think this function intended to layer 5..)
it gets 2 arguments. what are they?
I am trying to verify the contents of the http response to find a content "abbb" in it.So my rule was
alert tcp MY_SERVER HTTP_PORTS -> any any(msg:"The page accessed has content abbb";to_client; established; content:"abb";sid:XXXXX; rev:x;)
unfortunately this rule seems not to work. Can anyone please tell if there is some issue with my rule.
For starters you need to fix the to_client part of the rule as this is not valid syntax. You will need to change this to be:
flow:to_client,established;
You can find more on flow here.
If you are just looking for the content "abbb" sent from your server to the client then you just need a simple content match like you have. I recommend using the fast pattern matcher here to improve the efficiency of the rule. So your content match would look something like:
content:"abbb"; fast_pattern:only;
Putting this together, your rule might look something like:
alert tcp MY_SERVER HTTP_PORTS -> any any(msg:"The page accessed has content abbb";
flow:to_client,established; content:"abbb"; fast_pattern:only; sid:XXXXX; rev:x;)
If this still isn't triggering then there is probably something else going on. Since you are just looking for this in the content you need to check your inspection depth in the http preprocessor. There is a server_flow_depth and a client_flow_depth. Try setting these to 0 (unlimited) and see if your rule is triggering after. For example if you had a client_flow_depth of 300 and the content "abbb" didn't come until after 500 bytes then the rule is never going to trigger because snort isn't configured to inspect that far into the payload.
If you have adaptive profiling enabled then you need to add the metadata service for http otherwise the rule won't match http traffic. This would look something like:
metadata:service http;
If you don't use adaptive profiling then it will use the ports in the rule header.
I wrote a TCP socket program,and define a text protocol format like: "length|content",
to make it simple, the "length" is always 1-byte-long and it define the number of bytes of "content"
My problem is:
when attackers send packets like "1|a51",it will stay in tcp's receive buffer
the program will parse it wrong and the next packet would start like "5|1XXXX"，
then the rest of the packets remain in the buffer would all parsed wrong，
how to solve this problem?
If you get garbage, just close the connection. It's not your problem to figure out what they meant, if anything.
instead of length|content only, you also need to provide a checksum, if the checksum is not correct, you should drop the connection to avoid partial receive.
this is a typical problem in tcp protocol, since the tcp is stream based. but just as http, which is an application of tcp protocol, it has a structure of request / response to make sure each end of the connection knows when the data has been fully transferred.
but your scenario is a little bit tricky, since the hacker can only affect the connection of his own. while it cannot change the data from other connections, only if he can control the route / switcher between your application and the users.
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"COMMUNITY BOT IRC Traffic Detected By Nick Change"; flow: to_server,established; content:"NICK "; nocase; offset: 0; depth: 5; flowbits:set,community_is_proto_irc; flowbits: noalert; classtype:misc-activity; sid:100000240; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"COMMUNITY BOT Internal IRC server detected"; flow: to_server,established; flowbits:isset,community_is_proto_irc; classtype: policy-violation; sid:100000241; rev:2;)
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CHAT IRC message from internal bot"; flow: established; flowbits:isset,community_is_proto_irc; content:"PRIVMSG "; nocase; classtype:policy-violation; sid:1463;)
The above rules have been written by David Bianco to track IRC bot/server activity on any IRC port. However, the above rules works fine but I have a problem with them. My problem is happening when multiple IRC servers (some of them work on 7000 and the other work on 6667) run on the network some of them will achieve the conditions of the rules and Snort will generate the alerts and some of them (or even one of them) will not achieve these condition and as a result Snort wont generate any alert related to the defined set. I think there's a kind of inconsistency. Any suggestions on that issue? I am working on Snort 2.8.
These IRC rules are quite old and won't (as you've seen) capture all IRC traffic. It's almost impossible to say why they're not matching with a network capture or trace.
The first rule is set a flowbit based on the rule matching the traffic (based on an insenstitive match of the word 'NICK' from offset 0 for a depth of 5), if the first rule doesn't match the traffic then it won't set the flowbit to "community_is_proto_irc". Here's an old explanation on flowbits - http://forums.snort.org/forums/rules/topics/flowbits.
The second rule simply alerts on the presence of the flowbit (for traffic from external to home) whilst the third rule is more granular with a content match (and the traffic flow reversed).
I'd recommend getting a pcap for the non-matching IRC traffic and firing it through Snort locally to see what's being missed and then tailoring your rules accordingly (snort -r test.pcap -c /etc/snort_test.conf) - http://manual.snort.org/node8.html.
HTH!
Thanks God, the issue is resolved now.... The reason of the problem was a conflict between many rules which trying to trig at the same time for the same activity (PRIVMSG), so when I removed these rules, every think was just fine for the above rules.