Our last post regarding the Sniffing Module Considerations in our Project Design Considerations! Here, we will divulge some information about our discovery and experience with Queue/NFQueue-bindings.

Now, during this stage of development, we had already more or less decided that we were going to use NFQueue as our core functionality for the detection/response components of the program. However, during our research for NFQueue, we came across 2 other applications that we thought might be worthy of interest to try out. They were the Queue module for Perl and NFQueue-bindings for Python and Perl.

The Queue module for Perl is essentially a module to help develop Queue applications for Perl. Queue is a predecessor of NFQueue; it performs similarly to NFQueue whereby it uses IPTable rules to store traffic in a queue and users can utilise a user-written application to process packets from the queue.

NFQueue-bindings is a set of Python and Perl modules that was written by a third party, INL software (please refer to http://software.inl.fr/trac/wiki/nfqueue-bindings).  They were written so as to allow users to write NFQueue applications using the programming languages of Python and Perl.

Unfortunately for us, we never got around to exploring these 2 options much. We had found some sample codes online which demonstrates the use of the modules; however, we encountered problems while trying to install them.

For the Perl Queue module, there is a recursion error in the MAKE file of the Perl IPTables::IPv4 module, which is one of the required modules to develop a Perl Queue application. Furthermore, the module has not been maintained since 2003. Due to these reasons, we were unable to test out the module, but we do have some sample codes from our research that demonstrate the use of the module. The codes can be found in the appendix of the report.

As for the NFQueue-bindings module, there is a problem with the MAKE file of the module and we could not install it either. The module itself also contains some sample codes that will be included in the appendix.

Well, we have come to the end of sharing about our Project Design Considerations and we hope all the posts so far have been informative and helpful in sharing information worth learning about! It is never bad to pick up nuggets of information here and there, every now and then.

Do continue checking back for more posts! We still have more to say!

As mentioned in our earlier posts, while working on the sniffing module (Wireshark) we found a better alternative which is NFQUEUE.

Well, probably your next question is: what is NFQUEUE? Essentially it is a function that is built within Linux IPTABLES itself. It works by making use of firewall rules to ‘queue’ packets into a special queue called NFQUEUE, and what it does is that it allows a user-written application to read the packets from the queue and process accordingly.

This is a significant discovery for our group as it changes our program design. The sniffer module that we mentioned earlier need not be developed as a properly configured iptables can do the same job efficiently. In our case, all packets would be sent to a netfilter queue for further processing.

The processing, which is defined as the scanned/database module can be done using various programming languages such as C, Python, Perl. Additionally, the filtering can be done within the same set of codes.

Another major design change would be the removal of the output module and part of the packet modification module. During our research we discovered that the API for the netfilter consisted of codes that would return the processed packets back to the kernel iptables. At this point, in theory, any changes in the IP destination would be processed appropriately.

**Elaboration Needed**

Interesting, right? Don’t go away just yet! Stay tuned for our next post about Queue/NFQueue-bindings!

We mentioned earlier that our Honey-S was going to consist of a sniffing module. Here, we will discuss more about our investigations and discoveries with regards to various sniffing module technologies.

We had two sniffer programs in consideration, namely TCPdump and Wireshark. This being the first time we had to combine an existing application with our code, we were unsure of what to do. Eventually we decided on having the sniffer application create a capture file while sniffing; following that, our code would work on that file.

After experimenting and testing TCPdump was found to be unsuitable. We could not read the capture file while it was sniffing. However, further testing found that Wireshark was suitable.

One possible reason for this difference might be due to TCPdump being an older application, and it was made to be a simple sniffer. We believe that it leaves the file open for writing till sniffing is completed; if this is so another application will be unable to open the file. In the case of Wireshark, it is likely that the file is opened and written into only when packets are sniffed. This allows for other applications to open the file for reading.

Further testing found that even if the file is left open and constantly read for new packets, Wireshark can still write to the capture file without issues. This rendered our previous assumption invalid, and removes a worry that we had in regards to the efficiency of the program. Previously, we predicted that we might have to constantly reopen the file to read new packets. However, this test proved that we need not reopen the file for each new packet.

Even so, the issue regarding the capture file’s size remains. However we decided to focus on the main portions for the application and revisit this issue at a later date.

While we were working on the above, we also found an alternative solution: instead of using a sniffer we could use the built-in firewall (iptables). Iptables have a target “NFQUEUE” that holds the packets in a queue for further processing. However, we will still need to do more research on this.

Portions of our code that reads the pcap formatted file is based on the code from Joshua Robinson’s website. Please refer to http://www.joshuarobinson.net/dos/libpcap_offline.html!

While attempting to read packets, we also realized that each protocol has a slightly different format, and in some cases they are contained within each other.

Over time, as we continued to work on Wireshark, we realized that it did not provide the most optimal performance. There is delay incurred while processing and that may exponentially increase, leading to a severe impact on a live network. However while working on Wireshark we found a better alternative that handled packets at the kernel level, which greatly improves performance – into the picture comes NFQUEUE.

NFQUEUE shows much promise, and we made the decision to have our application based on it instead of Wireshark. It is much more efficient for the kernel to handle the capturing of the packets as opposed to running Wireshark. Additionally this method does not require us to come up with our own output module – the packet just needs to be returned back after processing and the kernel will send it back to the network. If you’re interested in knowing more about this method, please refer to http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023286.html!

Our next post will put the focus on NFQUEUE that we have been mentioning over and over so far. Wait for more!

We have alot to discuss about regarding the methodologies considered, so they’ll be split up into 4 separate posts, with one topic per post.

Here in this one, we will be discussing the first methodology we considered: IPTables redirection! The reason we considered making use of IPTable rules to redirect traffic is because it is simple.

Here are some rules that demonstrate redirection of traffic using IPTables:

#Redirecting port 80 traffic from 192.168.1.4 going to 192.168.1.3 to 192.168.1.2

iptables -t NAT -A PREROUTING -p tcp –dport 80 -s 192.168.1.4 -d 192.168.1.3 -j DNAT –to-destination 192.168.1.2:80

#Redirecting port 21 traffic going from 192.168.1.2 to 192.168.1.3 to 192.168.1.4

iptables -t NAT -A PREROUTING -p tcp –dport 21 -s 192.168.1.2 -d 192.168.1.3 -j DNAT –to-destination 192.168.1.4:21

#Redirecting ALL traffic going from 192.168.1.2 going to 192.168.1.3 to 192.168.1.4

iptables -t NAT -A PREROUTING -p tcp -s 192.168.1.2 -d 192.168.1.3 -j DNAT –to-destination 192.168.1.4

Although redirection of traffic is easy to conduct with IPTables, this functionality itself has very limited capabilities and it does not perform to what we expected.

First of all, it redirects traffic based on port numbers which means that it is not a very effective filter since port numbers change for all services. Secondly, it does not look into the content of the packet, which does not fulfil our requirement of reading the packets and detect interesting traffic.

However, working with IPTables does prove to us one thing: which is that IPTables itself is capable of redirecting traffic.  This information was useful to us later when we started working on NFQueue.

Naturally that’s going to be the topic of our next post! Stay tuned!

With any project it’s always best to plan ahead what approach to take. Prior to starting our project we had done some thorough thinking and came up with two approaches we could take in developing Honey-S: Programming from Scratch, or  Improving Current Technologies. In Phase 1, we decided on programming from scratch, but as time went by we realised it would really be better if we improved on current technologies instead! Below we will elaborate more on why we decided to change tactics.

Time

This is a really important factor for us because we only have an approximate of 6 weeks for Phase II; time is really against us. It would take a considerable amount of time (and effort) to build everything that we wanted from scratch. In contrast, it would considerably shorten our development time if we were to use existing technology such as Wireshark for our sniffing module instead of building one from scratch.

Programming Limitations

Programming from scratch would require socket programming which we were unfamiliar with, and it would take time to learn programming techniques from scratch. Additionally, our supervisor recommended us to use applications that are already being widely used in the industry (e.g. Wireshark). Thus, weighing our options, we came to the conclusion that if we built upon applications currently available our short schedule would be optimised.

So, this is why through the course of our project, we changed our development approach and made use of existing technologies to build our application instead!

In our next posts we will talk about various methodologies we considered implementing for our HoneyS.

Hello all, having stated earlier that one of our main functions of the honey-S includes the ARP poisoning module, many of you would be wondering what ARP poisoning, we will be sharing more about how ARP poisoning works by giving a short summary of the concept including examples.

The ARP poisoning module is the first module that runs when the system is started. Its purpose is to ARP poison the whole network so that traffic would be intercepted.

It will send out ARP reply packets with its MAC address to the entire network.  This will overwrite the ARP caches of all the other computers in the network with the host PC’s MAC address. Due to this, from then on whichever PC which has been poisoned will send packets to the host PC instead of its original destination. This allows the host PC to intercept all traffic within the network.

In the following sections, we will explain how ARP poisoning works.

In the above example, the red computer sends a request to all the computers out in the network asking who has the IP address of 192.168.1.2. The blue computer, who has precisely the IP address 192.168.1.2, upon hearing the request will send a response back to the red computer. Once the connection is established, the red computer will then store the blue computer’s IP address and MAC address in its ARP cache, and blue computer vice versa.

In the new scenario, there is a third party, a new computer in place. The new computer, the yellow computer, is the bad entity. Even without the red computer sending a proper request for the IP address, the yellow computer sends a response of its own to the red computer. The red computer will automatically think that it is the blue computer and it will store the IP address and MAC address of the yellow computer, overwriting the blue computer’s IP address and MAC address. A connection is now established between the yellow computer and the red computer. This is because the red computer thinks that it is still communicating with the blue computer and that the communication is legitimate even though it is actually with the rogue yellow computer instead.

The yellow computer will do the same to the blue computer, sending an unsolicited reply, tricking the blue computer into storing its IP address and MAC address into its ARP cache, thus overwriting the IP and MAC addresses of the red computer. The blue computer is still thinking that it is communicating with the red computer.

Right now the yellow computer is playing the role of the “man-in-the-middle”.  It is able to manipulate the messages sent between the red and the blue computer, for example seeing and controlling what the two computers send to each other. The yellow computer can eventually modify the messages and cause confusion between the two computers.

This is what the ARP poisoning module does; the highlight is that it poisons the whole network traffic instead. Hopefully it would let you better understand what ARP poisoning is all about.

This is the network layout of our Honey-S in a network. You may think that it is a complicated layout, but in actuality, it has a simple concept.

The network structure for Honey-S is simple, and the environment for the Honey-S to operate in requires the following elements:

-All network components are to be included under the company’s subnet, inclusive of the Honeynet server.

-At least 1 PC, preferably running a Linux based operating system, is required to run the Honey-S host application.

So basically, as seen in the diagram, all nodes are behind the switch. Be it the normal computer in the network or a computer in the honynet, they are all behind the switch. The pc that runs the honey-S host application would most probably be linux based and it will be able to arp poison, route and detect the traffic before deciding where the traffic would go. So if traffic is malicious, it will be sent to the honeynet server, if not, it will be sent to its intended destination.

So this is the rough idea of our layout, stay tuned for more!

Tag Cloud