-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can mOS API run on a Raspberry Pi B+? #23
Comments
Hi @VuXuanPhong,
Once you have verified DPDK's compatibility, we can discuss how you can compile mOS in your setup. Also, we are in the process of revamping (#20) |
Thank you so much. I will build DPDK and run an application base on DPDK. |
Hi, I just want to ask you questions about mOS API Library to make a plan. I read mOS guide and mOS paper many time, and I think that I understand how mOS API work. My Teacher want to make an intrusion detection system base on mOS. I also read about mSnort in mOS paper, my goal is to combine Snort with mOS such as mSnort. As far as I understand, mSnort transforms the signatures-rule of Snort into event-action pairs in mOS, so this becomes event chains. Each function in an event chain is both the filter function and the handler function. Two important functions are pattern matching function and PCRE matching function. Is these function borrowed from Snort? And pattern matching function is a multi-event filter function, this mean that when a string matches a pattern, a event will be triggered. How can I make it while a filter-function can only return true or false? As I read in the mOS paper, mSnort use a parse function to transforms Snort rule to event-handle pair. What does this function do? Does this function read a file containing a set of rule line by line and parse each rule to an event chain? Is the thing I said above wrong? Wish you have a nice day. Thank you. |
We modified Snort3 to integrate with mOS stack. We reused Snort's own pattern matching and PCRE routines for this purpose. Both functions were used as filters. We used a combination of Your last few questions are quite broad. Very briefly, we used an initialization routine that read all rules from a rule file and created filter-event-handler functions. I suggest that you go through a tutorial on how a signature-based IDS usually works for further clarification. A good starting point can be section 2 of our kargus paper. |
Thank for your reply message. I will study according to your instructions. |
Hello @ajamshed.
I can't figure it out when you say that "read all rules from a rule file and created filter-event-handler functions". When I read mOS paper, I understand that: mSnort express each rule option type as a UDE filter and in mSnort, your team implemented 17 rule options of Snort rule. In my point, your team write 17 filter function correspond to 17 rule options. And then read rule file line by line, process each line, when a rule option is related, call the corresponding function as filter-handle function. Please tell me more detail about the initialization routine in mSnort. |
Hi @VuXuanPhong. You asked a lot of questions in this message. I will try to answer all of them here. [Correction] FT-AC1 & FT-AC2 are both Aho-Corasick-based (AC) multi-pattern matching filter functions that scan for suspect malicious strings in payloads. Snort's pattern matching module has evolved over time. Different AC DFAs are now, in fact, initialized based on various types (tcp-payload, http-payload, smtp-payload, etc.) In the example figure above, we show two AC filters above that correspond to tcp-payload and http-payload. This means that Snort's detection engine runs the packet/stream instance across both (in sequence) if the flow is http. i hope this makes sense. [Correction] FTDIR is a uni-event filter (default version) and it evaluates the following Snort sub-rule-option We carefully typecasted mOS-based packet data-structure to Snort's. We could not keep one common packet data structure, otherwise we would have ended up modifying the Snort source code a lot. I understand that the Snort source code is a bit complicated. I suggest that you spend a few days understanding how the IDS is designed. I can't pinpoint the exact file that you should be focusing on since there is a huge leap in code structure from Snort 2.9.x (C-based, single-threaded) to Snort 3.x (C++-based, multi-threaded). Which version are you analyzing? You pretty much captured everything related to mSnort initialization. We had to modify the Snort init and rule_parser modules to integrate our mOS-specific changes. I suggest that you do an in-depth study of the 2 modules. Making changes to Snort took a few days. But we had past experience with Snort source code development. For a newbie, I am afraid it may take more than a few weeks to get familiarized with the source code. I suggest that you first pick a version (2.9.x or 3.x). Snort-.2.9.x is simpler to study than Snort-3.x. You can probably start with that. |
Wow. You posted the full source code. @VuXuanPhong, it will be difficult to analyze and test the entire source code as I am a bit busy. I can give you a few pointers where exactly the problems may lie. 1- Did you go through the documentation (http://mos.kaist.edu/guide/)? This page indicates that you can't run PCAP mode on multi-cores since our pcap plugin does not split traffic across multi-cores. Also, did you put the 2- Please check whether the program works with the following changes:
|
Hello @ajamshed I hope you are doing well :D. Thank you so much for your reply, I learned a lot. Sorry about my late reply. I read your reply many times to understand. At the first time read mOS paper, since the flow keyword has many values, I thought FT_DIR is also a multi-event filter function. Now, I understand that mSnort evaluates the sub-rule-options such as flow: to_server or flow:to_client. I will study on Snort 2.9.x version since having a few documents research on this version. As you suggested, I will do an in-depth study of the two modules: Snort init and rule_parser modules. I will test the above program according to your instructions. Thank you so much 👍 |
Hi,
I am a student from Viet Nam. I have a project that build a IDS/IPS with mOS API on Raspberry Pi B+.
I try to build mOS API on Raspbian Lite aarch 64, and then got an error: "unrecognized command line option -m64".
In my point, mOS API can't build on Raspberry Pi machine, but i want to confirm that.
Please tell me can mOS API build on Raspberry Pi?
Sorry about my bad English.
Thanks.
The text was updated successfully, but these errors were encountered: