Types of Honeypots

In general, ‘Honeypot’ is one of the information systems. To get the information of attackers in network, it is used. The Honeypot is located in front of firewall, and so it saves the system in prior. If any attacker passes through this firewall to attack the system, honeypot will catch the attacker’s information and prevents using IDS (Intrusion Detection System). The main goal of the IDS is to determine the unauthorized users who are misusing the information system in real time with the help of both external and internal resolver. It is also serves as a shield around the entire network system. But sometimes, it will be lacking in protecting the system from attackers.

There are two general classifications of honeypots accessible today, high level interaction and low level interaction. These types are characterized in view of the administrations, or level of communication, given by the honeypot to possible attackers. High-communication honeypots let the programmer cooperate with the framework as they would any normal working framework, with the objective of catching the most extreme measure of data on the attacker’s strategies. Any order or application an end-client would hope to be introduced is accessible and for the most part, there is almost no limitation put on what the programmer can do once he/she includes the framework. Despite what might be expected, low-collaboration honeypots exhibit the programmer imitated administrations with a restricted subset of the usefulness they would anticipate from a server, with the expectation of recognizing wellsprings of unapproved movement. For instance, the HTTP helps on a low-connection honeypot would just help the charges expected to indentify that a known person is trying to attack the system. A few authors categorize a third classification, medium-communication honeypots, as giving extended collaboration from low-association honeypots however not as much as high-connection frameworks. A medium-collaboration honeypot may all the more completely actualize the HTTP convention to copy an outstanding merchant’s execution, for example, Apache. In any case, there are no executions of a medium-communication honeypots and for the reasons for this project, the meaning of low-level interaction honeypots catches the usefulness of medium-cooperation honeypots in that they just give fractional usage of administrations and don’t permit regular, full connection with the framework as high-collaboration honeypots.

In this report, the following things will be carried out.

• Analysis – In this section the concept of honeypot strategy implementation in existing network information system will be discussed. The study on Software Defined Network (SDN), architecture of HoneyNet architecture, HoneyMix Architecture and Honeyproxy architecture will be discussed.
• Design- In the design part, the overall design process of this system is provided.
• Implementation – In Implementation part, how the coding part is developed will be discussed in detail.
• Discussion – In this section, the obtained results will be discussed.

A honeypot is a framework which intended to purposefully give attackers a chance to test, examine and at last explores the framework by finding an arrangement of unprotected managements. The main role of honeypot is to nearly screen the copied framework to learn practices of attackers and gather harmful information after the mistreatment of honeypot. To accomplish this objective, the honeypots are designated to get attacked by the dynamic attackers from the genuine foes and the genuine working framework frequently isolates it from the administrations or system. The movements of opponents gathered from the honeypots could give prior signs of new attacks, empowering supervisors for securing genuine frameworks and systems. Honeypots are largely sorted into the following kinds- Low interaction honeypot (LIH) and high interaction honeypot (HIH). The principle distinctions among these categories relies on their multifaceted nature as well as the association level contributed to the attackers. Honeynet refers to a system of honeypots made for upgrading cooperation with the attackers. Not with standing, the honeynet represents an impossible to differentiate shortcoming from that of honeypots. Because of the honeynet architecture that are outdated, the existing honeynet experiences inadequate information control systems and information catch ability. For instance, inbound and outbound activity control systems and its design couldn’t anticipate inside spread of malware inside a honeynet on the grounds that entrance control rules are for the most part upheld by a custom passage called Honey divider. In this project, we are going to build a honeynet architecture that is innovative for defeating the impediments of the currently active honeypots and honeynet design with the help of SDN innovation. The HONEYPROXY includes an intermediary module and a relating SDN application. It appears as a turnaround intermediary to give enhanced control over approaching and active movement while getting system setup by means of SDN controller. Hateful activities from the attackers are redistributed to each of the related honeypots and HONEYPROXY chooses a reaction from the reaction line which doesn’t contain any fingerprinting indicators. For preventing the interior malware produce, HONEYPROXY participates with SDN controller so as to recognize any kind of irregularity inside a system. Supporting powerful progress between the LIH and HIH is acknowledged by the empowering three working modes.

The Role of Honeypots

SDN stands for Software Defined Networking, which gives a worldwide view and incorporated control instruments to SDN applications. Furthermore, SDN can help to give adaptability in checking and controlling untrusted activity inside the honeynet. We use SDN worldview in our outline and uses midway screen and course bundles to honeypots, accordingly supporting inside activity observing and relieves the danger of inner malware engendering. SDN is a rising system worldview that isolates the control plane from the information plane. Tradition organizes gadgets implant complex control rationales to process the arrange movement while SDN switches just perform straightforward “match-activity” based handling. By disentangling the information plane, SDN abstracts the control plane and merges those control rationale into a concentrated controller. Since SDN empowers intelligently brought together system condition, SDN underpins noteworthy programmability and adaptability that could help enhance the security of honeynet (Hong and Hua, 2018).

Pros of SDN

• It empowers brought together administration of systems administration gadgets (Galán-Jiménez, 2018).
• It helps in mechanization of systems administration gadgets.
• It gives upgrades to end clients.
• It offers adaptability, versatility and proficiency contrast with conventional systems administration.
• It is generally utilized by person to person communication sites (facebook, twitter, google in addition to and so forth.) and substantial database web crawlers (Google, Yahoo, Ask and so forth.)

Cons of SDN

• It requires change in whole system foundation to actualize SDN convention and SDN controller. Thus it requires finish reconfiguration of the system. This expands cost because of reconfiguration (Application Aware Routing in SDN, 2015).
• Staff should be prepared.
• New administration apparatuses should be acquired and everybody ought to be prepared to utilize it.
• Security is a major test in SDN.
• Single purpose of disappointment.

Nowadays, Enterprises have been looking for SDN as it brings out a value to their business. SDN is not just a data center or like other service providers. It brings true value to the Enterprise. It extends its feature from data centers to mobile as well as wireless edge too. So enterprises mainly focus on the implementation with OpenFlow protocol.  CapEx Savings are working with this SDN implementation for utilizing various technological benefits. They are listed below (Nispel, 2018).

• Improvisation of Network Efficiency
• Improvisation of IT agility
• Customized network Option. It provides reliable and fastest services for all enterprise application.
• Newly developed applications can be supported easily
• It provides advanced analytics on various types of resources. SO that multiple sections in business process can be monitored and controlled based on the strategic business decisions made.

The major threat factors of the SDN are discussed below.

• The forged traffic flows could be utilized for attacking the switches and the controllers. This type of threat could be triggered by the faulty devices which are non-malicious, or a malicious user can do this activity.
• The attacks on the vulnerabilities in the switches, could be easily wreak havoc by using a network. A single switch can be utilized for slowing down the packets, in the network, clone or for deviating the network traffic (For instance: for the purpose of data theft), or even inject traffic or forged requests for overloading the controller or its neighboring switches.
• The attacks on control plane communications could be utilized for generating the DoS attacks or to perform data theft. As a fact in security community, the use of TLS/SSL don’t guarantee any secure communication, and that it would compromise with the controller–device link.
• The attacks and vulnerabilities in controllers are the serious threats to SDNs. The whole network can be compromised by a faulty or a malicious controller. It is not enough just to utilize the common intrusion detection system, because it could be difficult to identify the exact combination of events which triggers a specific behavior and labels it as malicious.
• Among the controllers and the management applications, the lack of procedures for ensuring trust exactly like the threat number 3, the controllers and the applications lack the capacity of establishing a trustworthy relationship.
• In traditional networks, the attacks and vulnerabilities in administrative stations are common, as they are utilized in SDNs for accessing the network controller.
• For forensics and remediation, the lack of trusted resources could let to understand the reason of the identified issue and can start with instant and safe mode recovery.

In Mininet topology, tree built-in types presented. They are given below (Team, 2018).

• Single
• Tree
• Linear

To select the topology type amongst three, ‘–topo’ parameter is used.

 $ sudo  mn –topo single, 4

• In the above command a single switch is linked with 4 hosts.

$ sudo mn –topo tree, depth=3, fanout=2

• In the above command, a tree of depth 3, is connected along with two children per node

            $ sudo mn –topo linear, 3

• In the above command, 3 switches connected in a row and each switch has one host.

The CLI of Mininet helps us to access control and manage the whole virtual network through a single window console. The CLI command is shown below.

In the above command, host h2 pings to the IP address of the host h3.

The above screenshot shows that the Linux command which can be executed on any virtual host. We can begin the web server on the host and can generate HTTP request from other host.

The Mininet dispersion incorporates a few content based and graphical (see above) applications which we expectation will be informational and motivate you to make cool and helpful applications for your own system outlines.

Figure 1 Network Sharing in Mininet 

Mininet topology is spread as a virtual machine (VM) picture with all conditions pre-introduced, runnable on normal virtual machine screens. For instance, Xen, VMware and VirtualBox (Kumar and Sood, 2016). This gives an advantageous holder to circulation; once a model has been produced, the VM picture might be disseminated to others to run, analyze and alter. An entire, packed Mininet VM is around 1GB. (Mininet can likewise be introduced locally – able get introduce mininet on Ubuntu.)

Figure 2 Setup of Mininet

Once an outline takes a shot at Mininet, it could be sent on the equipment for a certifiable utilization, estimation and testing (Bholebawa and Dalal, 2016). To effectively port to the equipment on the primary attempt, each Mininet-imitated part should act similarly as its relating physical one. There must be virtual topology coordination with the physical one; then the virtual Ethernet sets should be replaced with the interface level Ethernet availability (N. Shivayogimath, 2015). Hosts copied as procedures must be displaced by having their own particular OS picture.

Honeynets

Moreover, each copied OpenFlow switch ought to be supplanted by a physical one designed to point to the controller. Be that as it may, the controller does not have to change. At the point when Mininet is running, the controller “sees” a physical system of switches, made conceivable by an interface with very much characterized state semantics.

The original (Gen-I) of honeynet, which was formulated in 1999, utilizes a firewall that for the most part performs information control at OSI layer-3. Despite the fact that Gen-I architecture effectively demonstrated its capacity in gathering attacks; it can be effortlessly distinguished by attackers. It couldn’t appropriately deal with active movement either. The foundation of the second period (Gen-II) and the third period (Gen-III) Honey nets is a layer-2 based firewall called honeywall. Honeywall has been conceived to empower straightforward system checking by provisioning layer-2 connecting, which is troublesome for attackers to identify. Gen-II and Gen-III have a similar design aside from a few extra functionalities. Having Gen-II segments as the premise, Gen-III uses honeypot observing devices to check variations from the norm and executes less demanding arrangement of the honeywall. As cloud foundation is broadly received in the present systems, sending Gen-III honeynet in a virtual situation turns out to be more famous since it brings numerous advantages that organization in a physical machine can’t give. It is an approach which includes sending of numerous virtual honeypots in a system. Any malicious activity coordinated to the genuine system will be sent to the committed gathering of honeypots in the system without acknowledge of the attacker. Nonetheless, this approach just diverts the malicious activity to the honeypot develop and does not give any information control systems. Likewise, it is additionally powerless against inward propagation of malware (Kyung et al., 2018).

Honey Mix depends on conventional Gen-III architecture that incorporates a honeywall for controlling system movement and catching malicious information. Behind the honeywall, we built a SDN-empowered system to achieve fine-grained information control. By doing this, we exploit Gen-III design as well as upgrade security of honeynet with the assistance of SDN.

We are going to discuss the essential components of the Honey Mix in a brief. In general, the Honey Mix has better data controlling functionality rather than the existing version which is based on SDN.

Figure 3 Architecture of HoneyMix

1. Overall concept of Honey Mix

The working of Honey Mix depends upon the Gen-III architecture. It controls the traffic occurred in the network as well as it captures the infected and malicious information. The core components of Honey Mix are given below:

1. Response Scrubber – It reduces the possibility of exposure while taking known fingerprinting methods by undertaking the scrubbing response (Masoud, Jaradat and Jannoud, 2017).
2. FDE (Forwarding Decision Engine) -It establishes the service map that provides the services given by the honeynet and by overlapping the services over the honeypots.
3. CSE (Connection Selection Engine)- It helps to develop, an end-to-end connection among the honeypot and the attacking person.
4. Behavior Learner – It calculates the allocated weights for each connection among the honey pots and the SDN switches.
5. SDN Switch– It makes connection along with the controller that Honey Mix-enabled. So that it can get the instruction message to steer the data flow and changes the network traffic in flight.

Figure 4  Heterogeneous and Redundant Service Distribution in Honeynet.

If the attacker establishes the connection, then the Honey Mix investigates the IP addresses and port numbers for making decisions on service selection. If the connection reaches SSH, then valid honeypots will be identified by FDE in the network with the help of service map. Then the forwarding rules will be installed. The CSE will connect to the attacker on behalf of honeypots. According to the successful handshake, various connections will be established with relevant honeypots by CSE. Then Honey Mix will choose traffic distribution with the help of group communication. Multiple responses will be generated based on the requests triggered by honeypots. Then the weights of each established connection will be returned by the behavior learner. Among these connections, CSE will select one and pipeline it to the connection established by FDE. Then the attempt of fingerprinting will be identified by Response scrubber, and then it will be sanities the responses to make sure that there was no proofs for the system are emulated (Multi Security System Based On Honeypot Using Kerberos Algorithm, 2018).

SDN Architecture

Network Rule Computation

In honeynet, there is a hosting honeypots. It needs a significant manual configuration process. In some co-existing honeypots, a set of redundant services are offered by the same host. Because of heterogeneity and the services redundancy, the network rules should be generated with the consideration of host, honeypot and service. Based on the problem using aforementioned elements, the following will be generated.

To utilize the centralized architecture of Honey Mix as the best, we need to identify, the abnormalities on the honeypots that are related with the incidents. It utilizes the advantages of Gen-III architecture and it overcomes the issues involved in the traffic.  To avoid this limitation, the Honey Mix can adapt to the technique of NFV (Network Function Virtualization). So that it is easy to detect malicious data and infected honeypot. Thus, it will provide an efficient running service for the network (Shin et al., 2018).

It is necessary to know about the SDN switches of the honeypots area. Because, in this connection selection process, there are various types of obstacles presented. Among two honeypots, the end-to end connection will be made dynamically if the attacker and some specific service is involved. Then, choosing the appropriate connection is also an issue. Next, the other one is selecting the right connection and at the right time is challenging. To overcome these issues, Honey Mix provides QoS with appropriate priorities.

HONEYPROXY is incredibly affected by Honey Mix, which shows a local SDN-based honeynet design. Honey Mix includes organization of different custom modules in the SDN controller for dynamic association choice and counteractive action of fingerprinting attack. However, Honey Mix needs moderation device for interior malware producing and all the more vitally, does not strengthen the progress between honeypots, which is one of the center functionalities of cutting edge honeynet for empowering more collaboration amongst the attackers and the honeypots (Lina, 2012).

We propose HONEYPROXY as a cutting edge honeynet design, which use SDN to conquer the constraint of existing honeypots. In this area, we portray the key outline objectives of our approach, and we represent the design of HONEYPROXY alongside the itemized fabricating squares (Thompson, 2018).

We characterize the accompanying plan objectives that any next generation honey net engineering should bolster:

The honeynet engineering must help a consistent change from a LIH to a HIH and the other way around. This exchange should likewise be adaptable and configurable.

The approach must be incognito — it needs to conceal the presence of itself and limit the introduction of living honeypots however much as could be expected. Thus, the approach should not bring about discernible deferral in leading the given tasks, as the postponement can bring about the location of the honeynet.

 The approach should have the capacity to screen all the inside activities to keep off honeypots from proliferating malware inside the system. Comprehensiveness additionally implies incorporated system observing and arrange wide (i.e., all inclusive) approach implementation, which is accomplished by utilizing SDN (Umamaheswari and Kalaavathi, 2018).

Pros of SDN

 The approach should be appropriate, paying little respect to the kind of dwelling honeypots or running administrations. The key inquiry here is identified with how the approach can address and arrange the repetitive administrations offered by various honeypots.

At abnormal state, HONEYPROXY comprises of an intermediary module and a SDN controller with relating application (HoneyProxy controller) that implements security principles and essential system rules. Numerous honeypots are associated with various switches, and they are midway overseen by the HONEYPROXY controller. The solicitations sent by the attackers go through a progression of modules in the intermediary and are transmitted to an arrangement of applicable honeypots (ZHUGE et al., 2014).

Figure 5 Overview of HoneyProxy

As appeared above diagram, the intermediary pushes a particular sort of labeling data inside the parcel headers. HONEYPROXY controller at that point makes SDN decides that check the labeling data in SDN changes to uphold organize strategies effectively. The intermediary module has three operational modes. In view of the choice made by the HONEYPROXY controller, the working method of the intermediary would be reconfigured when essential. To avert fingerprinting attack, the intermediary module examines the payloads of reaction to check whether it incorporates any fingerprinting pointers that may uncover the nearness of honeypots or potentially honeynet. After finding such a marker, the intermediary module flags the HONEYPROXY controller to make suitable move, for example, changing the intermediary mode or refreshing system designs. The intermediary module is additionally in charge of dealing with encoded correspondence. Segment III-C gives nitty gritty engineering and building squares of HONEYPROXY.

Figure 6 Honeypots are grouped by vulnerable services using HONEYPROXY.

Figure 2 delineates how HONEYPROXY changes the landscape of honeynet engineering. Customary honeynet engineering runs various honeypots behind the custom firewall (honeywall). Notwithstanding, the conventional engineering may rise excess of the same imitated administrations in view of the absence of collaboration between honeypots, as appeared in Figure 2a. This is the primary driver of wasteful information control, and therefore, just a single honeypot is available to an attacker at any given time. In addition, every honeypot requires a great deal of manual arrangements to mimic every conceivable administration because of absence of progress between honeypots, which is the fundamental driver of excess administrations in the honeynet.

The HONEYPROXY engineering is delineated in Figure 3. HONEYPROXY comprises of an invert intermediary module and a SDN application (Honey Proxy controller). This outline partitions organize programming and bundle handling into two unmistakable sensible layers. The switch intermediary module forms approaching and active movement utilizing three sub-parts: Request Handler, Connection Management Engine, and Response Scrubber. The SDN application oversees organize setups and authorizes SDN rules, while observing suspicious bundles inside the system.

Details of HONEYPROXY modules are as per the following:

Request Handler is in charge of taking care of the approaching movement. At the point when a bundle is receive by Request Handler, the payload is checked to choose if the activity contains any known fingerprinting attacks, which can uncover presence of the honeypot. On the off chance that, the payload contains filtering attacks, which requires to utilize L3 or underneath layer conventions, Request Handler adds the checking tag to the parcels and straightforwardly advances to honeypots that are running interruption identification frameworks (IDS). At that point, in view of the aftereffect of checking payload, the Request Handler flags the Connection Management Engine to perform NAT and DPI to deal with the sessions. In this manner, the fundamental capacity of Request Handler is to screen approaching activity for suspicious parcels and sends the outcome to the Connection Management Engine.

Cons of SDN

Connection Management Engine is the center of turnaround intermediary module that organizes Request and Response Handler. The fundamental objective of the motor is to choose a reaction among different reactions received from honeypots and keep up the sessions to help three working methods of HONEYPROXY. Connection Management Engine additionally adds labeling data to parcel headers of approaching activity, permitting SDN changes to forward them to coordinating goal. Reaction Handler is in charge of identifying fingerprinting pointers that might exist in the reactions got from the honeypots. Reactions including such pointers trigger this module to advice HONEYPROXY controller. In the first place, reactions from related honeypots are recorded in the R Queue, sitting tight for the landing of outstanding reactions until the point when the extent of the line is equivalent to the quantity of related honeypots. When,  the line size and number of honeypots coordinates (or timeout occasion is activated), at that point Connection Management Engine chooses the most proper reaction from the R Queue (LIAN et al., 2017).

Flow Programming Module keeps running as a piece of the SDN uses of HONEYPROXY controller. This module is in charge of telling the controller to include SDN rules (i.e., a stream passage) that relates to specific movement handled by the turn around intermediary. Bundles set apart as filtering will be sent to suitable honeypots. i.e., the ones that are running IDS which is particularly intended to recognize examining attacks.

Mode Decision Module decides activity method of the intermediary. In view of a few criteria, this module sends demand to the intermediary to change the working mode. To accomplish the main outline objective (all-inclusiveness), HONEYPROXY uses SDN to settle on a choice on working methods of HONEYPROXY and authorizes system and security rules by means of SDN controller. HONEYPROXY screens all streams in the system through the SDN controller so any association endeavors created by (possibly) bargained honeypots can be logged, observed, and anticipated. To help dynamic changes flawlessly between honeypots (the second plan objective), Connection Management Engine in the intermediary, the most fitting reaction from the getting line is selected and tracks the state changes of every single dynamic association. Along these lines, HONEYPROXY can likewise move the association starting with one honeypot then onto the next. To accomplish the third plan objective (Stealthiness), HONEYPROXY endeavors to limit the execution holes between various working methods of HONEYPROXY utilizing multi-handling strategies (Marroni et al., 2011). The inactivity holes between various models are not as much as a millisecond (< 1 ms), which is not really discernable when attackers interface over the web.

To meet the last outline objective, speculation, HONEYPROXY builds up various attachments with the related honeypots to help L4 or higher in OSI layer. Since helpless administrations are for the most part using application layer convention (L7) with the exception of filtering attacks, HONEYPROXY can suit to the majority of conventions. For examining attacks using L3 or underneath, SDN use of HONEYPROXY diverts those bundles to one of honeypots that runs interruption identification frameworks, which are particularly intended to distinguish checking attacks.

SDN Implementation in Enterprises

In this project, the application Honey RJ will be developed. HoneyRJ, is a usage of a low-collaboration honeypot. As characterized over, a low-collaboration honeypot serves various restricted usefulness conventions with the plan of catching the wellspring of movement going to the honeypot. A honeypot is situated on an IP address that is utilized exclusively with the end goal of the honeypot and not for any authentic administrations; any associations with the product are ventured to be malignant and are logged for later survey.

HoneyRJ was intended to be a simple application and it can be an effectively extendable one. Our plan choices shows that it aims to make a straightforward application that exhibits the idea of a low-collaboration honeypot and enables anybody with negligible specialized learning to stretch out the application to incorporate their coveted conventions.

Hardware Requirements

• IBM-compatible 486 system
• Hard Disk with 8 MB Memory space
• CD-ROM drive
• Keyboard
• Mouse

Software Requirements

• OS Platform: Windows 7/8/10
• Java SDK/JRE 1.6 or updated version
• Eclipse IDE 4.2

In the design part, the overall design process of this system is provided. It consists of earlier design decisions, related decisions on the design and technical documentation based on the application working internals. In this section we will discuss on the chosen development environment and then we should concentrate on logging format, multithreaded design and the security implications.

1. Selection of Programming Language

To implement the honeypot network security, we chose ‘Java’ language (Stamatakis et al., 2013). There are many reasons to choose java and they are listed below (Fang and Yu, 2014).

• Very convenient to use for application development
• It is very easy to implement sockets
• It has an excellent thread library.

1. IDE selection

To implement the application, we chose Eclipse IDE and the main reasons to use, are listed below (HemaLata Rao, 2012).

• It has built with the support of JavaDoc so we can code easily.
• It is a modern IDE to learn the coursework.

1. Decisions on Application Design

HoneyRJ can monitor in on various conventions and can converse with numerous customers on every convention without a moment’s delay. We chose to plan HoneyRJ to help different associations on the grounds that generally the application would be extremely restricted as far as its value as a honeypot: the application would just have the capacity to log one programmer’s association at once ( Urbanek, 2011). With just a single accessible association, we would not have the capacity to run various conventions or see different associations from one programmer. This would be an extreme impediment on the helpfulness of the information gathered by HoneyRJ and along these lines we chose to execute HoneyRJ as a multi-thread application.

HoneyRJ saves the log records as content reports in a nearby index, refreshes them as the association advances. We chose to store logs as plain content reports to enable a client to effortlessly read them and to permit parsing by outsider utilities. On the other hand, we could have put away the log records as serialized Java objects; anyway this would require a watcher application and would anticipate simple parsing later on. We decided to ceaselessly refresh the log record as an association advances to enable a client to screen dynamic associations by review the log document. This gives the client more adaptability than composing log records toward the finish of associations and shields from log information disappearing upon an application crash. At last, if the client just wishes to see the finished log records, they can decide to just open the content documents that speak to shut the associations.

HoneyRJ just backs string-based conventions and does not bolster the transmission of paired information. We actualized HoneyRJ essentially for straightforwardness; so that there are security suggestions identified with enabling clients to transfer parallel records. For instance, a programmer could transfer a double record with an infection and after that executes it through a support flood attack show in the working framework running HoneyRJ. Numerous conventions are content based and along these lines HoneyRJ can bolster most conventions a client would need to actualize.

HoneyRJ was planned with an association timeout and holding up period between associations with a convention. This plan keeps dissent of administration attacks from a pernicious client. We incorporated these shields in light of the fact that the intended interest group that will interface HoneyRJ isn’t trusted and indeed, are exclusively making noxious associations. Without these shields set up, a programmer may be capable dispatch a DoS attack against the machine running HoneyRJ. Any association left open to HoneyRJ will consequently be separated after the arranged timeout (as a matter of course, 2 minutes). This keeps a programmer from leaving a huge number of associations in an open state and in this manner forestalling different clients or the executive from interfacing with the machine running HoneyRJ. Moreover, once a convention acknowledges an association, it will hold up an arranged timeframe (of course, 5 seconds) before tolerating another association on that convention. This keeps a client from opening an extensive number of associations in a brief timeframe.

In this section, how the developed application is implemented and launched and when the new module is created and started the attack prevention process are provided. It is essential to read JavaDoc before starting the project work. In this project, there are two main classes included. They are HoneyRJ and LIModule. Another important helper classes are LIModuleThread and LIProtocol. The main class HoneyRJ has the control of various LIModule classes. It provides the connection support for implementing the protocols. Every LIModule has LIProtocol interface to establishing the communication logic along with the clients who are connected to the server information system. LIModuke launches LIModulethread based on the client connection for establishing communication with the client.

The main class HoneyRJ has more than a module and it manages various modules. Based on the application launch, the class HoneyRJ constructor is initiated. A HashMap structure is created by this constructure to save the LIModules. The LIModule can be mapped to the appropriate port number by using HashMap. It allows this application to make sure that not more than one module is loaded for each port. If the HashMap is initiated, then the logging directory is generated. To pass the newly added LIModules, the reference is added to this module. In this time, the new modules are added by HoneyRJ. Then the object is created for LIModule by initializing its instance. Then the object is passed into the method named RegisterService() which is a data member of HoneyRJ class. This method adds the new instances into HashMap to make sure that the modules are defined for its their appropriate port. After adding into the HashMap, the method registerParent() will be called. Then the access for logging directory will be given to this module. If this process is doing repeatedly, then additional modules are created. In this time, the HoneyRJ needs to be waited for the user so that it can start the newly added modules. Once if the user begins the added modules, the entire application needs to be waited for connection.

Figure 9 Launch Flow of the HoneyRJ Application

The above shows diagram displays the overall view of what the developed code does. The programming structure is developed based on the above concept.

In this part, we are going to discuss that how to initialize the LIModule and the steps involved in the starting process of LIModule. It handles both communication and logging that related to this one protocol. After finishing the implementation of the LIProtocol Interface, the LIModule constructor is initialized. Inside the constructor, the LIProtocol class can be stored like a data member. So it is considered as a variable. In such cases, the reference to the parent to access the logging directory is provided for parent. Now this module is in the ready state that began by user.

After the module is started, then it is launched by itself into a thread. Then the ServerSocket will be created. Then it listen the port mentioned in the LIProtocol. If the client needs to communicate to the port, and then the LIModuleThread will be launched by the LIModule along with the socket connected to the worker.  Both LIModules and attacker communicate each other through LIProtocol when the new connection is established by LIModule.

The LIProtocol characterizes five strategies that must be executed by the convention’s class. Of these five techniques, the processInput() strategy does most of the work, while the other four strategies give data about the convention. In such cases, when a LIModuleThread is thrown to deal with a customer association, it makes an example of the class executing the LIProtocol interface. The way toward getting and sending messages is laid out in figure 8, utilizing the FTP convention for instance. Every bundle got from the customer on the attachment is changed over into a String object and go as a parameter to the processInput() technique. The processInput() strategy is then anticipated that would procedure that String and restore its reaction to the customer as a Vector of String objects. Each String in the returned Vector is sent to the customer as a different line. In the event that wer convention just returns one String, a partner technique, LIHelper.vectorFromString(), is given to make a Vector protest from one String.

Alternate techniques for the LIProtocol interface are characterized as takes after:

• whoTalksFirst() – The arrival estimation of this technique fills the LIModuleThread in regarding whether the customer or server sends the main message once an association is set up. In HoneyRJ wording, this is alluded to as who “talks first.” It is characterized by the TALK_FIRST enum and has two qualities: SVR_FIRST (if the server sends the primary message) and CLIENT_FIRST (if the customer sends the principal message).
• A convention that is characterized as having the server talk first will have its first message asked for by a call to processInput() with an invalid protest as the parameter. The execution ought to perceive this and restore the main message.
• getPort() – The number return estimation of this technique tells the LIModule what port the convention tunes in on.
• toString() – The String returns the estimation of this technique which is utilized to name the log documents and distinguish the convention in the GUI. It should restore a String indicating the name of the convention, for instance, “FTP.”
• isConnectionOver() – The Boolean return estimation of this technique demonstrates to the LIModuleThread if the convention trusts the association is finished, that is, no more messages ought to be sent or got. The arrival estimation of this strategy is checked after the String objects returned by processInput() are sent to the customer. The strategy should restore a Boolean genuine if the association is finished or a Boolean false if the convention is as yet hoping to send or get messages

HoneyRJ enables a client to compose extra conventions and “attachment” those conventions into HoneyRJ. This area diagrams the means required to execute a convention. All through the segment, all cases are given with regards to the FTP convention that we created. The procedure for making another convention starts with a few key plan choices. We will then make a class actualizing the 5 strategies in the LIProtocol interface. We at that point add a reference to the made class in the fundamental application strategy through straightforward adjustment to the HoneyRJMain.java record.

The way toward composing a convention requires learning of Java programming: at least, a comprehension of regular Java information structures and protest situated programming. In this area, we expect the client is utilizing the Eclipse IDE. What’s more, we expect we have suggest learning of the convention we will execute.

Attackers have their own particular countermeasures against honeypots. Know that attackers swap data about known honeypots. Fortunately, as we specified, there are numerous frameworks being used. This makes it more troublesome for attackers to search for a solitary mark deceiving the presence of a honeypot. A few specialists trust that every honeypot ought to have a “trickery port”, an open port that enables attackers to recognize the honeypot. Apparently this persuades aggressors that they are managing a complex foe, and would hinder them from seeking after their attacks.

In any case, aggressors utilize the accompanying to decide whether they have bumbled into a honeypot. We can utilize this rundown to enhance our framework:

• There is practically no action in the framework.
• A framework is too simple to hack.
• Uncommon administrations as well as ports are open.
• Working frameworks and programming have been introduced utilizing the defaults.
• Document and organizer names are too clearly appealing, for instance, a record called “standardized savings numbers”.
• There is almost no product introduced.
• Log all bundles going to and from the honeypot framework. Think about that there is no authentic explanation behind any such movement.

Utilize a convention analyzer, for example, Wireshark to break down the attacks. We will need to center around the bundles traveling between the firewall and the honeypot. Be cautioned this requires a lot of circle space. Utilize the sifting abilities of the convention analyzer to limit catch estimate. Keep the gatecrasher parcels’ request, succession, time stamps, and bundle write since these are imperative signs to the interloper’s expectations.

For a Linux framework, ensure that we incorporate the system with the goal that we can sign onto a remote server. Use the firewall’s warning capacities to send us cautions when activity jumps out at or from our honeypot.

Outfitted with the responses to the outline choices, we can start programming our convention. Initially, we imported the Eclipse venture gave as a major aspect of the source code into Eclipse following the guidelines accessible in the Eclipse documentation [Eclipse08]. The following stage is to make an open class that actualizes the LIModule interface. We suggest naming the class as [Name] Protocol, supplanting [Name] with the name we chose in the key choices segment, and putting away the class in the src/convention bundle inside the Eclipse venture.

After we have made the class implementation, we can enable Eclipse to create skeleton strategies that execute the interface. We should make a toString() technique utilizing the “Abrogate/Implement strategies” work in Eclipse. The toString(), getPort() and whoTalksFirst() techniques are easy to execute and speaks to the responses to the key choice inquiries(Wang, Cao and Wei, 2013).

The next twofunctions, isConnectionOver() and processInput(), are all more difficult, as an appropriate execution requires recalling the condition of the associated customer. The FTP convention execution utilizes a part factor connectionState to store the condition of the association and actualizes a switch() explanation on this variable in the processInput() strategy to decide whether the correct information was received and the best possible reaction to send. isConnectionOver() is executed by checking if the connectionState variable is equivalent to the consistent speaking to the shut state(Gazit, Malandrino and Hay, 2017).

The processInput() technique restores a Vector of String objects in light of a String. On the off chance that we require just a single String in light of a message, the static aide strategy LIHelper.vectorFromString() is given to spare we the season of embodying every reaction String as a Vector. The static technique restores a Vector with the given String as the main part(Design and Implementation of Conflict Detection System for Time-Based Firewall Policies, 2011).

• publicVector<String> processInput(String msg)

{ /* source code */ }

• public booleanisConnectionOver()

{return connectionState == KILLED; }

The implemented application has the following features:

• Support for different conventions – The application bolsters the expansion of any convention a client will program by actualizing the Java Interface. Any class executing the interface can be added to the HoneyRJ application and HoneyRJ will collaborate with customers as indicated by the rationale characterized in that class. No restriction to number of customer associations – HoneyRJ has a multi-strung outline so it can tune in for associations and converse with any number of customers at the same time.
• Logging – HoneyRJ makes a log petition for every association and logs all sent and got parcels.
• Graphical Interface – HoneyRJ gives a straightforward GUI to enable the client to control the application.
• Configurable – The application can be designed at accumulate time to change a few alternatives.

The accompanying Denial of Service attack defendant highlights are represented in HoneyRJ:

A programmer could endeavor to dispatch a DOS attack on the honeypot by opening a substantial number of associations and abandoning them in a sit without moving state. This could keep an executive or another programmer from opening an association with the machine running HoneyRJ on the grounds that the working framework will have depleted its system assets (Cho and Chung, 2018).

Every association with HoneyRJ will be shut after designed timeout period (as a matter of course, 2 minutes). On the off chance that the association is sit out of gear for the timeout period, HoneyRJ will commandingly close that association. In the event that an association never ends up sit still, HoneyRJ will compellingly close the association after it is associated for the timeout period.

A programmer could endeavor to dispatch a DOS attack on the honeypot by quickly opening associations, possibly using a lot of framework assets. This could keep the honeypot from catching movement from different programmers or beginning new associations (Zhou, Zhang and Qin, 2011).

HoneyRJ powers a designed timeframe (of course, 5 seconds) between synchronous associations on a convention. Amid this period, the programmer can’t make new associations with the convention (Bolla et al., 2017).

Merits and demerits of the honeypot are discussed in brief.

Advantages:

• It provides, various security solutions, like network IDS.
• The unauthorized user could not be uses honeypots. So that here lesser false positives.
• Honeypot can work in encrypted environment.
• Unlike IDS, it does not need any known attack signatures
• It easily captures the attacks and provides the information about the types of attacks and possible information about the attack.
• It easily creates new security solutions for new attacks by looking at them.
• It can obtain more examination by looking at the type of malicious behaviors.
• It helps to understand more attacks that might happen.
• It’s not bulky in terms of data capturing, because it only deals with the incoming malicious traffic.
• It focuses only on the malicious traffic to easily investigate on the traffic, to provide an effective solution easily and see to it that there is no need of large data storage, to investigate the malicious traffic.
• If it uses new technology, it doesn’t require maintaining the technology.
• The honey pot computer system does not require additional cost budget, to create such a system.
• It is simple to install, configure and understand.
• It does not have complex algorithms.
• There is no need for changing and updating certain things.
• It also captures any malicious attacks and also captures new tools for detecting the attacks.
• The honey pot gives more deepness and ideas of the subject to prove to discover different point of views and apply them for our security solutions (honeypot system based on software containers, 2016).

Honeypots are not great, however:

• Can be utilized by aggressor to attack different frameworks
• It can only capture the data when the hackers are attacking the active computer system.
• If the hackers attack another system, the honeypot cannot identify it. So, it causes big problems.
• It has finger printing disadvantages of honey pot, because it is very easy for an experienced hacker to understand if he is attacking a computer system or the honeypot system.
• The honey pot uses the zombie to reach the other system and compromises with them. This process creates very dangerous issues.
• Just monitor communications made specifically with the honeypot – the honeypot can’t determine the physical attack against different frameworks
• Can possibly be distinguished by the attacker

Custom security arrangements, for example, interruption recognition frameworks, may not be sufficient in light of more confused attacks. Honeypots give a component to recognizing novel attack vectors, even in encoded conditions. Advances, for example, virtualization has made honeypots much more forceful. Honeypots have disadvantages, however, so it is critical to see how honeypots work so as to augment their adequacy.

Conclusion

The main aim of this project is to implement the Honeypot in Software Define Network (SDN). The entire project is carried out by through various phases, in analysis phase, the general concept is discussed. The general idea of honeypot in SDN is figured out. In existing system, what the technology is used and working of those technologies were discussed. Architecture and design of Honeynet, Honey Mix and Honey proxy are discussed. In the design part, the overall design process of this system is provided. In Implementation part, how the coding part is developed was discussed in detail. The coding part is done in java language and Eclipse environment. Thus, the design and implementation part of this project is explained in detail. In Discussion section, the obtained result was discussed.

CD-ROM: Compact Disc, Read-Only-Memory

CSE: Computer Science Engineering

DoS: Denial of Service 

DPI: Dots Per Inch

FDE: Full-Disk Encryption

GUI: Graphical User Interface

HIH: High Interaction Honeypot

HTTP: Hyper Text Transfer Protocol

IDE: Integrated Development Environment

IDS: Intrusion Detection System

IP: Internet Protocol

JRE: Java Runtime Environment

LIH: Low interaction honeypot

NAT: Network Address Translation

NFV: Network Function Virtualization

OS: Operating System

QoS: Quality of Service

SDK: Software Development Kit

SDN: Software-Defined Networking

SSL: Secure Sockets Layer

TLS: Transport Layer Security

References

Application Aware Routing in SDN. (2015). International Journal of Science and Research (IJSR), 4(12), pp.1977-1978.

BAI, Q. and SU, Y. (2013). Design of distributed honeypot system based on clustering and data shunting algorithm. Journal of Computer Applications, 33(4), pp.1077-1080.

Bholebawa, I. and Dalal, U. (2016). Design and Performance Analysis of OpenFlow-Enabled Network Topologies Using Mininet. International Journal of Computer and Communication Engineering, 5(6), pp.419-429.

Bolla, R., Giribaldi, M., Khan, R. and Repetto, M. (2017). Network Connectivity Proxy: Architecture, Implementation, and Performance Analysis. IEEE Systems Journal, 11(2), pp.588-599.

CABAJ, K. (2015). HoneyPot systems in practice. PRZEGLD ELEKTROTECHNICZNY, 1(2), pp.65-69.

Cho, C. and Chung, T. (2018). A novel architecture of Proxy-LMA mobility management scheme for software-based smart factory networking. International Journal of Communication Systems, 31(12), p.e3584.

Coughlin, M., Michel, O., Keller, E. and J. Aviv, A. (2018). Making the Live Network the Honeypot. [ebook] Available at: https://nsr.colorado.edu/coughlin/doc/nsdi2014-proposal.pdf [Accessed 3 Aug. 2018].

Design and Implementation of Conflict Detection System for Time-Based Firewall Policies. (2011). Journal of Next Generation Information Technology, 2(4), pp.24-39.

Fang, F. and Yu, X. (2014). Design and Implementation of Next-Generation Data Center Infrastructure. Applied Mechanics and Materials, 513-517, pp.1316-1319.

Galán-Jiménez, J. (2018). Exploiting the control power of SDN during the transition from IP to SDN networks. International Journal of Communication Systems, 31(5), p.e3504.

Gazit, N., Malandrino, F. and Hay, D. (2017). Mobile operators and content providers in next-generation SDN/NFV core networks: Between cooperation and competition. Computer Networks, 121, pp.112-123.

Ghourabi, A., Abbes, T. and Bouhoula, A. (2013). Characterization of attacks collected from the deployment of Web service honeypot. Security and Communication Networks, 7(2), pp.338-351.

Han, W., Zhao, Z., Doupé, A. and Ahn, G. (2018). HoneyMix: Toward SDN-based Intelligent Honeynet. [online] Available at: https://adamdoupe.com/publications/honeymix-toward-honeynet-sdnnfvsec2016.pdf [Accessed 3 Aug. 2018].

HemaLata Rao, M. (2012). FPGA Implementation of Reconfigurable Switch Architecture for Next Generation Communication Networks. International Journal of Engineering and Technology, 4(6), pp.770-773.

HONEYPOT SYSTEM BASED ON SOFTWARE CONTAINERS. (2016). Scientific Bulletin of Naval Academy, 19(2).

Hong, J. and Hua, Y. (2018). Research on Network Defense Strategy Based on Honey Pot Technology. IOP Conference Series: Materials Science and Engineering, 322, p.052033.

Kumar, D. and Sood, M. (2016). Software Defined Networks (S.D.N): Experimentation with Mininet Topologies. Indian Journal of Science and Technology, 9(32).

Kyung, S., Han, W., Tiwari, N., Hemant Dixit, V., Srinivas, L., Zhao, Z., Doupe, A. and Ahn, G. (2018). HONEYPROXY: Design and Implementation of Next-Generation Honeynet via SDN. [online] Available at: https://sefcom.asu.edu/publications/honeyproxy-design-and-implementation-of-next-generation-honeynet-cns2017.pdf [Accessed 3 Aug. 2018].

LIAN, Z., YIN, X., TAN, R. and CHEN, Y. (2017). SDN Virtual Honeynet for Network Attack Information Acquisition. DEStech Transactions on Computer Science and Engineering, (smce).

Lina, Z. (2012). Design and Implementation of KSP on the Next Generation Cryptography API. Physics Procedia, 33, pp.1640-1646.

Marroni, F., Pinosio, S., Di Centa, E., Jurman, I., Boerjan, W., Felice, N., Cattonaro, F. and Morgante, M. (2011). Large-scale detection of rare variants via pooled multiplexed next-generation sequencing: towards next-generation Ecotilling. The Plant Journal, 67(4), pp.736-745.

Masoud, M., Jaradat, Y. and Jannoud, I. (2017). On Detecting Wi-Fi Unauthorized Access Utilizing Software Define Network (SDN) and Machine Learning Algorithms. International Review on Computers and Software (IRECOS), 12(1), p.21.

Multi Security System Based On Honeypot Using Kerberos Algorithm. (2018). International Journal of Modern Trends in Engineering & Research, 5(2), pp.169-172.

Shivayogimath, C. (2015). Modification of L3 Learning Switch Code for Firewall functionality in POX Controller (Working on SDN with Mininet). International Journal of Research in Engineering and Technology, 04(06), pp.513-518.

Nispel, M. (2018). SDN – What Can You Do With It In The Enterprise?. [online] SDxCentral. Available at: https://www.sdxcentral.com/articles/contributed/sdn-markus-nispel/2013/04/ [Accessed 7 Aug. 2018].

Shin, S., Xu, L., Hong, S. and Gu, G. (2018). Enhancing Network Security through Software Defined Networking (SDN). [online] Available at: https://faculty.cs.tamu.edu/guofei/paper/SDNSok-ICCCN16.pdf [Accessed 3 Aug. 2018].

Stamatakis, K., Norton, W., Stirman, S., Melvin, C. and Brownson, R. (2013). Developing the next generation of dissemination and implementation researchers: insights from initial trainees. Implementation Science, 8(1).

Team, M. (2018). Mininet Sample Workflow – Mininet. [online] Mininet.org. Available at: https://mininet.org/sample-workflow/ [Accessed 7 Aug. 2018].

Thompson, M. (2018). Effects of a Honeypot on the Cyber Grand Challenge Final Event. IEEE Security & Privacy, 16(2), pp.37-41.

Umamaheswari, A. and Kalaavathi, B. (2018). Honeypot TB-IDS: trace back model based intrusion detection system using knowledge based honeypot construction model. Cluster Computing.

Urbanek, S. (2011). iPlotseXtreme: next-generation interactive graphics design and implementation of modern interactive graphics. Computational Statistics, 26(3), pp.381-393.

Wang, H., Cao, Z. and Wei, L. (2013). A scalable certificateless architecture for multicast wireless mesh network using proxy re-encryption. Security and Communication Networks, 7(1), pp.14-32.

Zhou, H., Zhang, H. and Qin, Y. (2011). A Proxy Mobile IPv6 Based Global Mobility Management Architecture and Protocol. Journal of Electronics & Information Technology, 30(12), pp.2999-3004.

ZHUGE, J., TANG, Y., HAN, X. and DUAN, H. (2014). Honeypot Technology Research and Application. Journal of Software, 24(4), pp.825-842.