I am wondering how to write snort rule which triggers an alert based on the detection method:
"Source-to-destination packets per second" lets say srate is = 1
Here is an attempt:
alert tcp any any -> $HOME_NET 80 (flags: S; msg:"detected by srate"; sid:3; rev:3; detection_filter:track by_dst, count 1 , seconds 1;)
And which rule options do I use for defining the following?
Number of inbound connections per destination IP.
Thank you so much
Best regards
Related
I'm building a port scanner to check if some TCP port at remote machine is open.
To improve performance, I just build and send a TCP SYN packet to remote port instead of doing full 3-way handshake.And if I receive SYN-ACK packet successfully,then that port will be considered as open.
Here is a part of my code:
conn, _:= net.Dial("ip4:tcp", target)
tcpSynPacket := BuildTcpSynPacket() // here I build a tcp syn packet
conn.Write(tcpSynPacket.Marshal())
deadlineTime := time.NewTicker(time.Second * 2)
defer deadlineTime.Stop()
for {
select {
case <-deadlineTime.C:
return nil
default:
bytes := make([]byte, 128)
conn.SetReadDeadline(time.Now().Add(time.Millisecond * 200))
readnum, err := conn.Read(bytes)
responsePacket := parstTCPHeader(bytes[:readnum])
matched := CHECK_IF_RESPONSE_MATCH_REQUEST(tcpSynPacket,responsePacket) // here I'll check if ack-no,src-port,dest-port in tcpSynPacket match seq-no,dest-port,src-port in response packet
if !matched {
// unmatched packets,may response for another routine
continue
}
if responsePacket.rst_flg == 1 {
// the port would be consider as close
// build func return struct,and return
....
}else {
// the port would be consider as open
// build func return struct,and return
....
}
}
There are not for loop and CHECK_IF_RESPONSE_MATCH_REQUEST statement at old code.But when I do stress test, I found it's necessary.
Let's say we'll test if port 80 is open at 66.220.146.94.I open 1000 goroutines to call above code.
goroutine1: ack-no=11111
goroutine2: ack-no=22222
goroutine2: ack-no=33333
...
Then I found that in every goroutine,the following statement
readnum, err := conn.Read(bytes)
responsePacket := parstTCPHeader(bytes[:readnum])
will read all response packet even the read packet do not match the syn packet sent at current goroutine.
For example, at goroutine1, I sent syn packet(ack-no=11111),and read from conn. Then I found the seq-no in read packet could be 11112,22223,33334...
So I add a loop and some check logic at CHECK_IF_RESPONSE_MATCH_REQUEST.
But the loop read and check logic make cpu so high.
Here is a test result(I run it every 60 seconds)
Top 10 cpu cost using 3-way shakehand when open 1000 goroutine(Duration: 60s, Total samples = 780ms ( 1.30%)):
Top 10 cpu cost using tcp syn port scan when open 1000 goroutine(Duration: 60s, Total samples = 30.51s (50.85%)):
What I want to know is that:
1.Why conn.Read(bytes) read all response packets in every goroutine?Is net.Dial("ip4:tcp", targetip) correct?
2.Is there a lower-cost way to do periodic port scan(every 60 seconds) without doing 3-way shakehand
Quick answer:
close conn at the end of the routine. net.Dial("ip4:tcp", targetip) is correct
reuse local ephemeral port in the socket pairs local:port remote:port when you craft the syn packet
Notes on 1:
Closing conn might not be the best idea, should do 2 above for these benefits:
not wasting cpu time for closing local ports
when you make multiple conns to the same addr too quickly and let kernel assign local port, the kernel ip stack might actually plays up - for more details, digging in this keyword TCP simultaneous connect
I modified the ovs2.6.0 and want to handle some packets.
I printk the prev_port(prev_port = nla_get_u32(a)) in do_execute_actions function. However, the prev_port sometimes is not the correct port number which the packet is forwarded to. But the TCP transmission is normal. I guess that the port number in ovs is numbered in a random way?
Could any one give me some rules to test Snort (ARP,ICMP,TCP,UDP) and ensure that my system work properly against attacks like DOS or MITM.
alert tcp any any -> any any (flags: S; msg:" Possible TCP dos detection"; flow: stateless; detection_filter: track by_dst, count 1000, seconds 1; sid: 10004;rev:1;)
I`m writing packet generator right now. Testing it with wireshark and VM. I have an exercise on my checklist to sent 3 packets in a row:
1. TCP on 80 port, with SYN=1 and MF=1 flags.
2. TCP on 135 port, with SYN=1 and MF=1 flags.
3. TCP on 80 port, with MF = 0 and offset = 24.
I`m sending all the packets with the same ID field on IP layer.So as I understand Wireshark should try to reassemble these packets.
But will it reassemble packets from different ports?And what should we get as final result?
All I get is 3 IPv4 packets.
http://cs625124.vk.me/v625124860/10bf5/BQFUbKT7zVs.jpg
Addition: I mentioned, that if I change offset of last TCP-packet to 16, than we got a bit different kind of traffic.:
We got one HTTP or continuos packet. And here is wrong checksum. I tried to copy correct checksum to the first TCP packet and then I got RST, so i think that WireShark interpreted SYN from 1-st packet:
http://s28.postimg.org/z3w7ibhjx/image.png
So could you please explain me, was the last result correct? I would appreciate any help. Sorry if it is something basic. It`s my first expirience of writing WinForm application and using Pcap.Net library too. Thanks in advance!Sorry for links, have no reputation(
First, a TCP session is defined by the tuple:
Side A's IP address.
Side A's Port.
Side B's IP address.
Side B's Port.
If you have packets with different tuples, they will not be part of the same TCP session.
You get a RST when the server closes the session.
It is likely the server doesn't like getting SYN packets from port 21 (FTP) to its port 80 (HTTP).
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.