A Dynamically Configurable Honeynet Framework for ...

Deployment of a Low Interaction Honeypot in an Organizational Private network Saurabh Chamotra, J.S.Bhatia , Dr. Raj Kamal, Dr. A. K. Ramani, [email protected],[email protected],[email protected], [email protected]

Abstract This paper describes a case study of Honeypot deployment in an organizational network. As per Wikipedia “honeypot is a trap that is set to detect, deflect, or in some manner counteract attempts at unauthorized use of information systems” [05]. These traps could be any digital resource ranging from a single computer to a network of such computers or a network application that appears to be a part of organizational network resources but is actually a fake resource with no production traffic. Further these resources are closely monitored and the traffic to and from these resources is well under the control of the administrator. In the experiment performed in this paper, such a trap is laid in the form of a low interaction honeypot honeyd [01] in the perimeter security of an organizational network. The results of deployment are presented and further various props and cons of such deployments are brought about.

Introduction As the organizations are becoming more and more dependent upon their network infrastructures, these network infrastructures are becoming more and more complicated for providing the necessary services. Due to this added complicacy in the network architectures to provide seamless automation to the organizational day to day routine work the conventional network security devices are failing to provide the level of comfort required by the network administrators. The main reason for this failure is the inability of the conventional security tools to understand the context of deployment scenario, as certain activities which are malicious in certain context may not be in another context. Hence there is a need of a context sensitive approach/technique for the prevention, detection and responding to the attacks performed on these complex networks. Another reason for the study of honeypot deployment in organizational network is that, most of the conventional honeypot deployments done in organizational networks are those in which honeypots are deployed facing outwards, that means it is assigned a public IP[10][12][13][11] that is lying outside the perimeter security. Such

deployments are not effective in reducing the impact of internal cyber attacks in organizations and insider threats. Where as according to the literature studies and surveys [04] 60-90% of attacks are internally oriented. Hence it is inappropriate that honeypot technology is not being used as a countermeasure to internal threats. Hence there is a need of a study to be performed to understand the effects of such a deployment on overall organizational network functionality. Here in this paper we have done such a study by deploying a low interaction honeypot in the private subnet of an organizational network. The results are presented along with benefits and issues involved in such deployments.

Honeypots and its deployment issues The honeypot technology is based upon the principle extolled by famous Chinese general Sun Tzu of “knowing ones enemy” and this concept was first introduced by Clifford Stoll in 1990 in one of his book [02].In the current times this technology has established it self as a measure for near real-time monitoring and forensic analysis of security events [04]. In literature Honeypots are defined as an “information system resource whose value lies in being attacked and probed” [01].The information gathered by a honeypot is used to learn about the targets, methods and tools used by intruders. The purpose of a Honeypot is to detect and learn from attacks and use that information to improve security [09]. A network administrator obtains first-hand information about the current threats on his network and further signature could be developed from the logged data for the zero day (New) attacks [03]. The value fetched from a Honeypot depends upon the paramenters such as: Type of honeypot deployed. Deployment scenario (location of deployment i.e. inside DMZ, behind firewall, in front of firewall etc)

Cyber Security Technology Development Lab CDAC-Mohali

Base upon these paramenters a honeypot can play following roles in an organizational security [01]. Detection of attacks by acting as bulgur alarm. Prevention of attacks by deception and deterrence. Responding to attacks by providing valuable logs regarding attack. The selection of a specific type of honeypot for deployment depends upon the value one is looking form such deployment. For example for achieving long term objectives such as prevention of attacks and responding to the attacks performed, high interaction honeypot is an appropriate selection where as for achieving the short term objective such as detection of attacks, low interaction honeypot is more appropriate choice. These information resources (honeypots) can be categorized based upon features such as 1. level of interaction a. High interaction honeypot b. Low interaction honeypot c. Medium interaction honeypot 2. Purpose of Deployment a. Production Honeypot b. Research Honeypots Further a honeypot selection could have following implication: Maintenance and operational cost Risk involved in the operation Data value collected legal issues (i.e. Entrapment, Privacy etc) Keeping in mind the above implications and based upon ones requirement and the value one is looking from the honeypot one could chose the appropriate honeypot category and deploy it accordingly in the network.

a low interaction Honeypot which emulates services and hence don’t have real services. The benefit of using such honeypot with emulated services is the low risk involved in its operation. As no real services are there hence the condition in which attacker may take over the control of the machine by exploiting these services could be negated. Other aspect of such deployment is that as no real services are exposed hence these honeypots can not be used to detect the system level vulnerabilities, but on the other hand as they are able to emulate machines on the network hence they are able detect network design and configuration vulnerabilities to some extent. Figure 1 shows the network diagram of the organization in which the experimentation was performed. The diagram shows that there exist two different networks N1 (with yellow shade) and N2 (with sky blue shade).

Network N1 (yellow shade): is a separate network that exists for the privileged access to the internet. The access to this network is limited and is separate from rest of the organizational network.

Network N2 (sky blue shade): is the regular network of the organization. All the local services (email, software and data sharing) are accessible through this network. This network is used by all the employees of the organization. These two different networks exist in organization operating separately. The low interaction honeypot honeyd is deployed in the organization’s regular network N2.Honeyd emulates all ranges of unused IP addresses on N2 network.

Network N1 Network N2

Network architecture and Honeypot configuration

Firewall `

`

`

INTERNET

`

Switch `

Till date most of the work done on honeypots and its related technologies is limited to the research and academic environment [16][17][18]. Where as for the successful adaptation of honeypot technology as a component of organizational security arsenal, proper study and experimentation is required to clearly understand all the aspects of such deployments.

Firewall

Switch

`

`

`

`

`

`

`

`

`

`

Private Network

DMZ

` `

INTERNET ` `

In the experiment performed by us we have deployed a low interaction honeypot honeyd [1] in the internal network of an organization. Honeyd is

`

`

Internal network 3/21/2011

Figure 1

Cyber Security Technology Development Lab CDAC-Mohali

The Honeyd is deployed in the 192.168.2.0/28 subnet of the organizational network and is emulating following services by using emulation scripts. 1. FTP 2. Telnet 3. SMTP 4. HTTP Apart from these services all the TCP and UDP ports are are shown open by default and system is able to generate replies for the ICMP ECHO request packets.

Data Collection & Processing Figure 2 shows the block diagram of the data collection and processing systems.

IP emulator

responsible for the capturing and logging of the data. The System incorporates two logging mechanisms Honeyd provides network flow statics TCPDUMP provides raw PCAP data To make the logging process more efficient honeyd logging mechanism does not log all packets but instead logs the start of connection and the corresponding end in a fashion similar to Netflow. The main benefit drawn of this is the reduced clutter in the logs [8].

Data Parser: The logged network flow data from

Graph Generator: The data collected in

Service emulator

relational database format is further processed by the data visualization engine for the generation of visual graphs. The data visualization engine uses Afterglow [06] and Graphviz [07] tools for the generation of the graphs.

Log collector Graph generator

Data collector: The data collection system is

the honeyd is further processed and converted in the relational database format. The database created consists of three tables TCP, UDP, ICMP.

System design Traffic Redirector

honeyd is able to emulate complex network architectures and their characteristics.

Log Parser

Graphs

Data base

During the 24 hour deployment of the honeyd in the network following data was collected.

3/20/2011

Figure 2

Network Flow Data: 19335 TCP Connections 40814 UDP Connections 93 ICMP Connections Pcap Data(Network Packets): 50MB

Following sub modules are present in the system

Traffic

Redirector: The ARP spoofing technique is used for redirection of the traffic for non existent IP addresses towards the Honeyd. Another technique for getting the traffic of non existent IP addresses towards Honeyd is blackholling. This technique (blackholing) is a static technique in which the unused IP address ranges are known in advance and based upon this knowledge router is configured to redirect the traffic for those IP ranges towards the Honeyd.

Port wise Distribution of connections Ports No Services of Con 25

48

SMTP

80

184

HTTP

IP & Service Emulator: Honeyd plays the role

110

166

POP3

of emulating IP addresses and the services running on them. Honeyd emulates the different operating system’s IP stack. With the help of NMAP OS fingerprint file the Honeyd is able to fool network fingerprinting tools to think they are dealing with a real operating system [1].Further

139

3106

NetBIOS

445

12028

SMB

1433

199

SQL SERVER

Cyber Security Technology Development Lab CDAC-Mohali

11000

65

Port used by Cisco BGP, Microsoft Visual Studio, .Net Framework.

9100

22

Jetdirect

843

21

Adobe Flash Player socket policy file server

2893

18

vseconnector

2889

16

powergemplus

5101

17

Figure 4

Talarian_TCP

Table 1 The collected data was further analysised and the results and findings are presented.

The figure 4 shows the broad cast traffic of network N1 for the port 138,137 that was been captured by honeyd deployed in network N2.Figure 5 shows the connection initiated from the infected machine of network N2 to the network N1.

Results & Findings We have categorized the findings of the above deployment in to four sections that are described below.

1. Network misconfiguration detection During the analysis of the captured data we discovered the broadcast traffic from Network N1 and some packet sent by the worm infected system in network N2 to network N1.This was strange thing because as per the network diagram both networks were not having any sort of connectivity and the Honeyd was deployed in the network N2.Hence logically honeyd should not receive any traffic from any machine of Network N1.

`

Figure 5 As there were no physical or logical connectivity exists between these two networks hence such type of traffic is not legitimate. Further when a manual verification of networks were performed it was discovered that some one from network N2 had plugged the network cable from the switch of N2 in the switch of N1 to access certain services available only in network N1.The connection is shown with a cross mark above in the figure 6.

NETWORK II `

Mail Server

3/19/2011

Figure 3 As shown in figure and figure 3 there is no connectivity between two networks. 3/20/2011

Figure 6

Cyber Security Technology Development Lab CDAC-Mohali

2. System misconfiguration detection Normally NETBIOS services are required in networks where still legacy systems (Windows 9x or Windows NT) are used. As these services are prone to various type of attacks and greatly exploited by attackers for gathering system information and also they generates unnecessary broadcast traffic which eats up the bandwidth in the network so it’s always advisable to disable these services if no legacy systems are present in the network. Further as in over case in the network under observation no such systems were present hence the NETBIOS service on most of the windows machines (Windows 2000, Windows XP, and Windows Server 2003) was disabled. But during the analysis of the data collected by honeyd it was observed that certain IPs in network N2 were generating huge amount of UDP broadcast traffic for port 137,138 as shown in figure. 7

Figure 7 This traffic was due to the fact that the NETBIOS services were not been deactivated on these machines. Normally one has to manually deactivate these services when the operating system is installed and by default these services are enabled on the machines. Hence the IP address involved in such broad casts were misconfigured machines on which the NETBIOS service was activated by default.

3. Worm infection and propagation. During the analysis process we first segregate the connections based upon the protocol type. Then the flow analysis of all the connections is done to identify the interesting connections.Futher the root cause analysis of these suspicious connections is done using techniques such as deep packet inspection. Based upon this analysis process, a set of 13 machines were identified to be infected with the varmints of Blaster and conflicker worms. The Figure 8 shows the TCP activity graph of one of such machine infected with the variant of the blaster worms.

Figure 8 Figure 9 shows the post infection activity done by a variant of conflicker worm. Post infection this infected node is trying to propagate by email by trying the connections to SMTP server. As by default all TCP ports are shown opened to the probing machine on the emulated IP.Hence we are able to identify the service or port which the infected machine is interested in.

Figure 9 Table 2 shows the list of IP addresses, the number of connections made and the ports targeted.

Infected Machines

con

ports

192.168.2.152

4562

192.168.2.159

1482

192.168.2.120

1462

192.168.2.165

1257

192.168.2.228 192.168.2.167 192.168.2.150

1187 1045 827

192.168.2.230 192.168.2.168

666 480

192.168.2.48

440

192.168.2.74 192.168.2.186

431 283

192.168.2.18

279

139,445,1433, 3143,3128 139,445, 9110,49164 80,139,445, 1433 139,445, 4189 445,1288 445 445,3790, 4518 445 139,445, 4086 139,445, 49152 25,139,445 445,1205, 1615,2888 25,110,445

Cyber Security Technology Development Lab CDAC-Mohali

Table 2 4. Other interesting facts One interesting thing observed during the data analysis was that a large amount of traffic from certain IP addresses was observed in the logs that should in theory not be there. The table 3 gives a summary of such address:

their Machines there was an IP conflict because those IP addresses were occupied by honeyd. Hence therefore one should be careful while handing such unstable machines and all the aspects should be approximated before the actual deployment is done. Conclusion: The capability of monitoring and data capturing is missing in the conventional security devices as its not their main objective hence these tools fails in providing a clear picture of a suspicious activity. On the other hand tools such as Honeypots has established them as an effective monitoring and attack data capturing devices. Hence Honeypots can play a vital role in not only detecting the non legitimate activities but also acting as foresenci tool for doing the root cause analysis of the suspicious activities [14]. Furtherer as these Honeypots are based upon the concept of deception and key to deception is the lack of knowledge about the state of target hence the effectiveness of a honeypot also depends upon the quality of deception and its robustness. The honeypot detection techniques [19] are used by the attackers hence there is a need of the dynamism in this deception which can defeat these efforts of honeypot detection [15].

Table 3 Following could be the factors responsible for producing such traffic [11]: Misconfigured enterprise routers/firewalls Missing ISP level ingress/egress filtering Defective devices.

Further its was observed that one should be careful while deploying such devices as they are repeatedly attacked and compromised hence are not deploy and forget type of solutions. If not handled properly a honeypots could itself be a source of attack for the network. As it happened in our case where the network was almost shut down by the honeyd. We were using arpd spoofing technique to redirect the traffic for unused IP addresses towards the Honeypot.By using arpd spoofing technique we were only getting the traffic of unused IP addresses but in evening when all the employees left the office switching off their machine their IP addresses were become unused and were taken over by honeyd. Now next day when they turned on

References [01] L. Spitzner, “Honeypots: Tracking Hackers”. Addison-Wesley, 2003. [02] C. Stoll, “The Cuckoo’s egg: Tracking a Spy through Espionage” The Maze of Computer, 1990. [03] Christian Kreibich, Jon “Honeycomb: Creating Intrusion Detection Signatures Using Honeypots”. [04] Craig Valli, “Honeypot technologies and their applicability as an internal countermeasure”. [05] http:en.wikipedia.org/wiki/Honeypot. [06] http://afterglow.sourceforge.net . [07] www.research.att.com/sw/tools/graphviz. [08] NielsProvos,ThorstenHolz,“Virtual Honeypots: From Botnet Tracking to Intrusion Detection”, Addison Wesley Professional [09] The Honeynet Project, “Know your enemy: Revealing the security tools, tactics, and Motives of the blackhat community” AddisonWesley, ISBN 0201746131, 2002. [10] Leurre.com “on the Advantages of Deploying a Large Scale Distributed Honeynet Platform”. [11] Jerome Francois, Radu State, Olivier Festor “Tracking global wide configuration errors”. [12] D. Moore, C. Shannon, G. M. Voelker, and S.

Cyber Security Technology Development Lab CDAC-Mohali

Savage, “Network telescopes,” CAIDA, Tech. Rep, 2003. [13] V. Yegneswaran, P. Barford, and D. Plonka, “The design and use of internet sinks for network abuse monitoring,” 2004. [14] F. Pouget and M. Dacier, “Honeypot-based Forensics,” in AusCERT2004. [15] Vinod Yegneswaran, Chris, Paul Barford, ”Camouflaging Honeynets” In Proceedings of IEEE Global Internet Symposium 2007. [16] Panos Kampanakis, Michael Kallitsis, Professor Douglas”Honeynets: Implementation and testing of a honeynet to verify a network’s security condition” Project - CSC/ECE 574. [17] Feng Zhang, Shijie Zhou. Zhiguang Qin, Jinde Liu “Honeypot: a Supplemented Active Defense System for Network Security” 0-7803-7840-7 02003 IEEE [18] Yong Tang, HuaPing Hu, XiCheng Lu, and Jie Wang “HonIDS: Enhancing Honeypot System with Intrusion Detection Models” Fourth IEEE International Workshop on Information AssuranceIWIA’06 [19] Ming shiue, Shang Juh, “Countermeasure for Detection of Honeypot Deployment” International Conference on Computer and Communication Engineering 2008

Cyber Security Technology Development Lab CDAC-Mohali