guidelines for collecting and centralizing network digital evidences

8/12/2019 GUIDELINES FOR COLLECTING AND CENTRALIZING NETWORK DIGITAL EVIDENCES

1/22

International Journal on New Computer Architectures and Their Applications (IJNCAA) 1(2): 437-458

The Society of Digital Information and Wireless Communications, 2011 (ISSN: 2220-9085)

437

Guidelines for Collecting and Centralizing

Network Digital Evidences

Mohammed Abbas1, Azizah Abdul Manaf2, Elfadil Sabeil3

1,3Faculty of Computer & Information Systems, Universiti Teknologi Malaysia(UTM), Johor Baru, Malaysia

[email protected],[email protected] Informatics School (AIS), Universiti Teknologi Malaysia (UTM),

Kuala Lumpur, Malaysia [email protected]

KEYWORDS

Forensic guidelines, network forensicguidelines, digital crime investigation,computer forensic, malware, botnets.

1 INTRODUCTION

Network forensic investigators havestated the significance of network digitalevidences due to digital crimes scienceand depicted its ability to come up withrare solutions that limited to networkforensic and meanwhile system(computer) forensic cannot. Normally,

researchers and experts suggest andpropose many different solutions such asFirewall's Logs, IDS/IPD Logs,Switches and Router's Logs andeventually incorporate more advancedsystems like Honeywall Architecture toeffectively help to investigate networkdigital evidences. Actually, HoneynetArchitecture basically is built to simplifynetwork forensic investigationoperations through key features that help

to collect and capture network inboundand outbound packets [1][2]. HoneynetArchitecture is unique in terms of built-in and well configured tools and utilitieswhich help to achieve the mission. AHoneynet is an architecture which itspurpose is basically to build a highlycontrolled network that control and

ABSTRACT

The digital evidences emphatically arecommonly considered as a backbone for theforensic body in order to deliver a reliableinvestigation when a breach occurred since aforensic basically based on them. However,there are challenges harming the integrityand reliability of these digital evidencessuch as removing or tampering with themsince most of equipments of productionenvironment are accessible to intrudersbecause they normally assign an InternetProtocol (IP). Therefore, a hidden

mechanism namely Honeynet Architecturewhich located in the middle between theequipments and intruders is proposed for thesake of overcoming these weaknesses. Inthis paper, firstly the proposed mechanismfor collecting and centralizing networkdigital evidences is studied and investigatedas well, and then a comparison among theproposed solutions is conducted in order tostate their characteristics that lead tochoosing the most suitable choices.Secondly, a methodology to collect and

centralize network digital evidences in orderto come up with the reliable investigation isintroduced. Finally, the guidelines to collectand centralize network digital evidences in asuccessful manner are produced.
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/22



438

capture all inbound and outboundnetwork activities. Usually, within thisarchitecture our Honeynets are placed. AHoneypot is a real system with validservices, open ports, applications and

data files. One of the key Honeynetarchitecture components is the Honeynetgateway which called Honeywalloperating system. The Honeywalloperating system is a very significantelement in the Honeynet architecturesince it captures and controls all of theinbound and outbound activities [3].In reality, traditional informationtechnology environment consists of maincritical digital components such as

Routers, Firewalls, Intrusion Prevention

Systems and operating systems used asservers in order to deliver its mission.Fig. 1 depicts an overview of thesecommon parts of an environment that isavailable nowadays. Normally, these

equipments being configured andassigned an Internet Protocol (IP) whichexplore and probes them all over theworld means they could be accessiblefrom outside to everyone. Actually, thementioned feature presents risk towardan IT environment since it allows anattacker to bypass and circumvent thebuilt security solutions in case there is azero-day attack because everything isdetectable and known form outside.

Fig. 1.Traditional IT Infrastructure.

Recently, attackers have grown to bemore intelligent against investigations

since they keep developing newtechniques used to hide or overwrite thedigital traces which might lead to graspthem. One of these expected crimes,overwriting all of operating systemdigital traces, firewall logs files, orintrusion/Prevention Systems (IDS/IPS)logs files and so on [4]. Furthermore,

sometimes even worse, they useencrypted channels during conducting

attacks which make digital tracesanalysis impossible without thedecryption [5].In the occurrence of attacks, it isenormously difficult to come up with adetailed analysis of how the attackhappened and then depicting what thesteps were especially against skilled

Web Server

Firewall

Internet

Router

Log ServerIDS/IPS

Data Base

Server


3/22



439

attackers who are clever enough atcovering their tracks. The operatingsystems digital traces, Router logs files,Firewall logs files and intrusiondetection alerts are unlikely to be

sufficient for a serious investigation [4].Therefore, the efficient solution is in thearea of Network Forensics; a dedicatedinvestigation technology that allows forthe capture, recording and analysis ofnetwork packets and events in order toconduct proper investigation [6]. Ingeneral, network forensics defined as isthe capturing, recording, and analyzingof network packets and events for thesake of investigative purposes.

From results in this research,concentrating on network forensic ismore accurate and much reliable since itallows setting up incorporated hiddennodes or hidden points in networkenvironment that are not detectable byattackers to be used for capturing thedesired suspected packets ininvestigation processes and then thesepackets should be centralized as well forthe sake of simplifying investigations.Honeynet architecture is mainly usedhere to achieve research aim.Despite various proposed and developedsolutions in field of network forensicdigital evidences are shown but they lackhandy tested obvious guidelines thatdemonstrate their usages step by stepaccording to relevant laws or otherwisewill not be admissible in the court andalso are useless [7].Zaid Hamzah noted and explained thathaving the evidence submitted is onething but its value is another. Lawyershave to persuade the courts that theevidence presented strengthen their caseor weaken the case of the other side, andalso he linked to relevant legal aspectssuch as Chain of Custody andAdmissibility of Evidences as follow:

(1) Chain of Custody: A chain ofcustody is a sequence of events thatshows how evidence was collected,analyzed, and preserved in order to bepresented as evidence in court. Any

forensics analyst should be careful to donot break the chain of custody;otherwise, the digital evidence may notbe admissible in the court. (2)Admissibility of Evidence: Admissibilitymeans whether the evidence could bepresented in the court or not. Not alldigital evidence gathered is admissiblein the court; in addition, some digitalevidence may be admissible in onecountry and not admissible in others. For

example, log files are admissible insome countries, but it is consideredhearsay in other countries. Therefore,this paper eventually came out mainly tocontribute to establish such guidelinesthat govern a smooth applying [8].

2 HONEYNET ARCHITECTURE

As stated in the previous section,Honeynet Architecture will be mainly

used here to collect and centralizenetwork digital evidences [9]. In fact,Honeynet Architecture logicallyencompasses of three differentsubsections Gen III, Virtual Honeynetsand Distributed Honeynets. In thissection, the comparison among threemain types of Honeynet is conducted interms of security, time, and cost ofnetwork evidences collection andcentralization [10]. The necessity of a

comparison is to assists to present keycharacteristics of Honeynet types whichhelp to generate guidelines. Table 1summarizes their advantages anddisadvantages.

2.1 Gen III Honeynets


4/22



440

Gen III is the third and latest generationof Honeynets which based on the Roo-1.4 Honeywall operating system. GenIII, is designed mainly to be a productionsolution to be used by individuals and

organizations around the world in orderto collect and centralize network datathat might used as evidences. Manyimprovements have added to previousversion Gen II which is called Eeyore[5]. Regarding to the applied security ofGen III, is basically considered enoughsecure which all integrated systems are

real and a gateway that Honeywall OSthat is separated from other integratedsystems. Honeywall OS installed andconfigured on bridge mode that hardensit hides its existence. Also since all

other systems are separated a part ofHoneywall OS, this technique helps toprevent single point of failure to beoccurred. It is also flexible enough sinceallows all systems to be added easilyinto the laboratory as depicted in Fig 2.

Fig. 2.Gen III Honeynets Architecture.

However, with the regard to Gen IIIHoneynets' time that needed forcollecting and centralizing networkdigital evidences is often optimal since

solely need time of delivering andlogging of the wanted chosen inboundand outbound packets. In Contrast,deploying Gen III might be costly sinceeach system must be separated andstandalone. Conceptually, Gen IIIHoneynets costs more than Virtual

Honeynets which it uses virtual machinefor the deployment.

2.2 Virtual Honeynets

Virtual Honeynet architecture basicallyuses virtualization technology tocombine all the various components of aHoneynets onto a single computerthroughout of using virtualizationsoftware [10][11]. However, instead ofrunning four Honeynets installed on four

Internet

Honeywall OS

Web Server Data Base Server Mail Server


5/22



441

physical computers (a Honeywall andthree Honeypots) it easily possible to runsuch a deployment on a single computerby using virtualization software such asVMWare software.

In particular, virtual honeynet consists oftwo subsections: Self-ContainedHoneynets and Hybrid Honeynets. Thedeference between them is that Self-Contained combined all componentseven a gateway (Honeywall OS) besidehoneypots within single physicalcomputer , whereas Hybrid Honeynet isthat the network gateway (HoneywallOS) only installed within virtualmachine, but others servers are real

systems. Regarding to virtual honeynet'sapplied security is considered the leastoffered feature and very weak becauseusing of virtual machines which inheritmany risks. The first risk of VirtualHoneynet is still suffering from singlepoint of failure that in case a system thatholds others systems failed, all othersystem will fail too. The second risk isthat limited only to special types ofoperating systems to be served within it.The third risk which consideredextremely dangerous is that can bedetected and probed remotely byattackers through check of itsfingerprint. This because of assigningspecial numbers on their MACaddresses. The following MACaddresses are significantly stated forVMWare: 00-50-56 , 00-05-69 , 00-0C-29, 00-1C-14. In addition, another wayused to detect existence of Vmware isusing Back door I/O port since VMWareuses the I/O port 0x5658 tocommunicate with the virtual machine.It is obvious this port is not real. Theverification is simple as following:

i. The magic number 0x564D5868 isloaded in the EAX register.

ii. The proper parameter of thecommand that is to be sent is loadedin EBX register.

iii. The command to be used is loaded inthe ECX register. For example, the

command 0x0A which prints out theVMWare version.iv. It is read from VX port. If we have

VMXh in the EBX register, thismeans that we are under Vmware.

However, the cost deploying Self-Contained Virtual Honeynets apparentlyis counted the least since that needs onlyvirtual machine software and thereforeall the servers and Honeywall OS will besetup within single machine by helping

of a virtual machine. In contrast, HybridHoneynets is more little bit differentthan Self-Contained Virtual Honeynets.In a Hybrid Honeynets only a gatewayHoneywall OS will be installed in avirtual machine but others Honeypotssystems are real and separated systems.Finally, regarding to time used to delivernetwork evidences collection andcentralization mission depend on VirtualHoneynet types, in self-ContainedVirtual Honeynet it considered thefastest offered solution because all of thesystems installed on a single machine sothat the time counted only for sniffingand logging. In opposition, Hybridhoneywall is slower than Self-ContainedVirtual Honeynet that needs extra timeto contact with the gateway HoneywallOS in order to login the networkevidences. In general, delivery time tosniff and log network evidences onVirtual Honeynets is the fastest amongother proposed solutions.Moreover, Self Contained VirtualHoneynets has extra several advantagessuch as they are portable which meanscan be moved or changed to anywhereunder anytime because all on onesystem, they play and catch which


6/22



442

means running one system as running allof systems and cheap and take littlespace as demonstrated in Fig 3. Despiteof that, Self-Contained VirtualHoneynets suffers from many

shortcomings like still there is singlepoint of failure because in case thesystem that carries out all goes down theother systems will go down too. Also,

they need high quality computer whichtake responsibilities of all installedsystems to improve the performance.Additionally, it limited to special typesof Intel architecture that do not give

much options to other types such asSPARC OS and so on.

Fig. 3.Self-Contained Virtual Honeynets Architecture.

In comparing to Self-Contained, HybridHoneynets is considered more muchsecure than Self-Contained Honeynetsbecause its gateway Honeywall OS isseparated from honeypots' systems.Also, it considered flexible since allows

others systems to be integrated with. Butis not portable, cost more and take morespace for deployments as explained inFig 4.

Internet

Operating System (Host)

Database Server (Guest)Honeywall OS (Guest)

Web Server (Guest)


7/22



443

Fig. 4.Hybrid Virtual Honeynets Architecture.

2.3 Distributed Honeynets

The principal feature of DistributedHoneynets is to monitor activities occuracross multiple networks concurrentlyfrom an analysis center. It basically

comes into two kinds; first kind is calledPhysically DistributedHoneynet and thesecond kind is calledHoneynet Farms.Physically Distributed Honeynet is alogical extension of the Gen IIIHoneynet design. It provides an ability

to perform centralized analysis of thecollected network digital evidences bythe multiple Honeynets across multiplenetworks. Physically distributedHoneynets independently audit andmonitor their local network and send

their captured data to a central system.But in contrast, the primary disadvantagethat requires hardwares to be presentedat the site as depicted in Fig 5.

Operating System (Host)

Internet

Honeywall OS

Mail Server (Guest)Web Server (Guest)

Database Server (Guest)


8/22



444

Fig. 5.Physical Honeynets Architecture.

Honeynet Farm is a more radicalextension of Gen III design. HoneynetFarms combine Honeynets with VirtualPrivate Network (VPN) technology tovirtually distribute Honeynets tosignificantly reduce the cost and time ofdeployment as explained in Fig 6. Infact, the security that relevant toDistributed Honeynets is consideredoften high. Physically DistributedHoneynets security counted as highest

level since all used systems are separated

and does not present a gateway(Honeywall OS) to the risk. Using ofvirtual distributed technology inHoneynets Farms causes positive andnegative effects in the same time. Itcould be positive when it uses VPN toencrypt the traffic and negatively when itcauses network latency problem thatmight lead or guide to existence ofHoneywall OS.

Net A- New Work

Net BSan Francisco

Honeywall OS

Honeywall OS

Data Base /Seattle

Honeypot B2

Honeypot B1

Event

Event

Honeypot A1

Honeypot A2 Router

Router

Internet


9/22



445

Fig. 6.Farm Honeynets Architecture.

Network latency has a substantial effect

on the performance of any request-driven file transfer protocol, since itcauses a delay between the time theclient issues a request for a file and thetime when the data for that file starts toarrive. This is one of the principaldisadvantages of purely on-demandtransfer strategies, such as downloadingindividual files. The request latencyproblem is compounded when theavailable bandwidth is high, since the

penalty associated with each request isthe product of the latency and thebandwidth (David Hovemeyer, 2001). Incontrast, the provided security is veryhigh and regarding to the cost because itneeds separated systems and would bedistributed anywhere as required. Here istotally opposite to Virtual Honeynets.

Also, time to deliver the mission will

take the longest time because in additionto time of logging, it adds time ofconnecting the central data base and alsospend more time to encrypt the traffic.Generally, cost of Honeynets farm isconsidered less than PhysicallyDistributed Honeynets.

Honeypot A1

Honeypot A2

Honeypot B1

Honeypot B2

Honeywall OS

VPN

VPN

Network ANew York

Network BSan Francisco

Router

Router

Internet


10/22



446

Table 1: A Comparison among Honeynets Subsections.

Honeynet Type Security Time Cost

Gen III very high high medium

Self-Contained Virtual Honeynet very low very high very low

Hybrid Virtual Honeynet low high low

Physically Distributed Honeynet very high very low very high

Farms Distributed Honeynet medium very low medium

3 RESEARCHS METHODOLOGY

As Fig. 7 demonstrates, our centralizingnetwork digital evidences methodologyencompasses two logically dissimilarphases. (1) Digital evidences collection

(capturing). (2) Digital evidencescentralization. Firstly, the goal ofnetwork digital evidences collectionphase is simply to capture attackersactivities as many as possible. However,developing a robust scalableinfrastructure to achieve this goal ischallenging and is a target of numerousresearchers. In particular, any designedand developed infrastructure shouldscalable enough to support wide range of

digital evidences collection. In addition,

special actions must be implemented toprevent any part of system to behavingmalfeasance. However, various differentmechanisms are used in order toovercome the mentioned problems andtherefore one solution (utility) is a

candidate to represent each mechanism.In special, IPTable firewall utilityrepresents firewall mechanism, Snortutility represents an intrusion preventionsystem [12], Logsys utility representslogging system and lastly Sebek utilityrepresents key logger for an encryptednetwork packets [5][13][14]. However,these utilities are explained in moredetails in next sections.


11/22



447

Fig. 7.Centralizing Network Digital Evidences.

An IPTables firewall installed onHoneywall OS which basically to beused for capturing attackers activities

and actions that against a victim since

Honeywall is configured as a hiddenmedia in bridge mode [15][16] asdepicted in Fig. 8.

Web Server

Router

Switch

Hardened Honeynet Zone

Log Server

Basic Honeynet Zone

Admin Honeynet Zone

172.16.54.110

172.16.54.146

Public Honeynet Zone

172.16.54.130

Honeywall OSSSH Server

Data Base server Mail server

172.16.54.120 172.16.54.121 172.16.54.122

Internet


12/22



448

Fig. 8.IPTables and Bridging Mode.

Therefore, IPTables firewall is immuneto be detected by attackers [17] [18][19]

[20]. By default, IPTables log itsmessage to a /var/log/ directory. Thenext sample depicts an interestedpotential an attackers activity he

attempted as against a target:

Sep 7 08:56:25 mohd kernel: INBOUNDTCP: In=br0 PHYSIN=eth0 OUT= br0

PHYSOUT= eth1 SRC=192.168.0.5DST=10.0.0.7 LEN=64 TOS=0x00

PREC=0x00 TTL=48 ID=42222 DFPROTO=TCP SPT=1667 DPT=21

WINDOw=65535 RES=0x00 URGP=0

The previous firewall log outputexplains very significant informationabout an attackers activity which to be

used by investigators to reveal andanalyze attacks and could be analyzed asfollowing:

The Date and time: Sep 7 08:56:25

The Source IP address of an attacker:192.168.0.5

The destination IP address of anattacker: 10.0.0.7

The protocol being used by an attacker:TCP

The source port of an attacker: 1667

The destination port of an attacker: 21

Snort with Active Mode orSnort_InLine, an intrusion preventionversion of Snort; installed along with anIPTables firewall on Honewall in orderto deliver the mission of the intrusionprevention system since highly requiredand could be used as another layer ofprotection and also digital evidencescollection method as well [21][22].Fig. 9 shows the logical integration ofSnort with IPTables on Honeywal OS.

User Space Process

Layer IPTable

Layer

eth 0 Layer Laye

eth1


13/22



449

Fig. 9.Snort integrated with Honeywall OS.

Snort primarily uses a rule drivenlanguage which combines benefits ofsignature, protocol, and anomaly basedinspection methods. The next sampleshows the collected digital evidencesusing this rule:

alert tcp any any -> any 80 (msg:"Sample alert"; classtype:misc-attack;sid: 2002973; rev:1;)

[**] [1:2002973:1] Sample alert [**]

[Classification: Misc Attack] [Priority:2]

12/12-15:35:22.130162test_client:35524 -> test_server:80

TCP TTL:64 TOS:0x0 ID:35734IpLen:20 DgmLen:52 DF

***A**** Seq: 0x5F3B46F0 Ack:0x85067266 Win: 0xB7 TcpLen: 32

TCP Options (3) => NOP NOP TS:49925498 1529581Log messages provide worth detailsabout the events of devices and theapplications running on these devices as

well. Log messages could be used todiscover and analyze security incidents,operational problems and policyviolations which useful in auditing andforensics situations. The next sampleshows the collected digital evidence:

mohd@ubuntu:~$ tail -f/var/log/messages

Mar 27 11:34:35 ubuntu kernel: [165.459827] Bridge firewallingregistered 44

Mar 27 11:34:35 ubuntu kernel: [165.563138] Bluetooth: SCO socketlayer initialized

Mar 27 11:34:39 ubuntu kernel: [170.004085] eth4: link up, 100Mbps,

full-duplex

However, the outputs has generated bytyping tail command. The analysis of thefirst output file analyzed as following:

Time: Mar 27 11:34:35

Host: ubuntu

Layer 2

User Space Process

IPTable Layer 2

eth 0 Layer 1 Layer

eth1

Linux kernel

Snort

UEUE

libi


14/22



450

Facility: kernel

Message: [ 165.459827] Bridgefirewalling registered

In fact, however, the current iteration ofSebek tool is mainly designed not onlyto record keystrokes, but to record allsys_read calls too. For an instance, if afile is has uploaded into Honeypot,Sebek immediately records the filewhich producing an identical copy. Ingeneral, Sebek consists of twocomponents; a client and server asappeared in Fig. 10. The client partcaptures off Honeypots data of a

Honeypot and exports it to the serverthrough the network. The server collectsthe data from one of two possiblesources: the first is a live packet capture

from the network, the second is a packetcapture archive stored as a tcpdumpformatted file. Once the data is collectedthen either will be uploaded into arelational database or the keystroke logs

are immediately extracted. However, theclient part resides entirely on kernelspace within the Honeypot andimplemented as a Loadable kernelModule (LKM). The client can record alldata that a user accessed via the read()system call. This data is then exported tothe server over the network in a mannerthat is difficult to detect from theHoneypot running Sebek. The serverthen received the data from all of the

Honeypots sending data.

Fig. 10.Sebek Sever/Client Architecture.

Moreover, Sebek generates its ownpackets and sends them directly to thedevice driver thus no ability for anattacker to block the packets or sniffthem by using a network sniffer sinceSebek uses its own implementation of

the raw socket interface whichprogrammed to silently ignore Sebekpackets. This technique demonstratedclearly in Fig. 11. Sebek packets aredefined as those that have both apredetermined destination UDP port and

Honeypot A

Honeypot B

Co of intruder activit covertl ex orted onto LAN

Intruder uses SSH to rotect communications

Intruder

Honeywall OS

Honeypot C

Sebek Server

Internet


15/22



451

the proper magic number set in theSebek header. If these two values matchwhat is expected means this a packet tobe ignored. The implementation simplydoes nothing with Sebek packets; it

drops them on the floor and moves on tothe next packet in the queue. The endresult is that an intruder is unable tocapture the Sebek packets.

Fig. 11.Sebek Module Conceptual Logic.

Secondly, the main goal of networkdigital evidences centralization phase ismerely to centralize the capturedinbound and outbound network packetsin arranged ways for simplifyinginvestigation purposes since all

evidences will be stored in one place.Nevertheless, developing a robustsolution to achieve this goal ischallenging and should be scalableenough to support all sorts of collectedevidences. Therefore, all the previousevidence collection mechanisms areprimarily used here and the next sectiondemonstrates how they handled toachieve this aim.The sequential logic of experiment's

flow initially started by configuring andadapting main utilities that used in thisresearch. The first step is to configureLog Server to accept and log the remote

logs transferring that could be allowedby adopting the option to SYSLOGD=-r [23]. Moreover, this configurationalso involved for centralizing IPTableslogs, since IPTables logs to system'slogs. On the client side (Honeypots),

their configuration option should bechanged too to transfer their logs to theremote log server which achieved byadding *.* @172.16.54.146 into/etc/syslog.conf file. Then, Snort utilityhas been adopted perfectly for capturingand recording unencrypted channelsproperly. The captured network packetsare recoded twice; into database and intoflat files. Finally, Sebek server/clientarchitecture has configured as well to

deal with encrypted channels. TheInternet Protocol (IP=172.16.54.1) hasassigned to Sebek Server which will beused to receive captured Sebek Clientspackets. Also, UDP port number 1101,accept and log, and magic value optionshas chosen. After that, Sebek Client hasinstalled into all honeypots and

User Space Kernel Space

Sebek Kernel Module

Linux Kernel 2.6

Standard Librar

ssize_t read(int fd, void *buf,

size_t count)

Data LoggerNew Read

Read Write

Original Read Original Write

S scall Table

1

23


16/22



452

configured too. Sebek Client has adaptedit's variables like UDP Port Number andInternet Protocol according to SebekServer.

4 RESULTS AND ANALYSIS

In this section, two major contributionsare discussed and explained intensively.Firstly, the outlines of obtained results ofthe experiment which prepared based onthe designed methodology in theprevious section are discussed. Then,handy guidelines to collect andcentralize network digital evidences areproduced.

4.1 Discussing obtained results of the

experiment:

In fact, a case study has been used hereto evaluate the designed methodologyand test the proposed solution whichmainly based on network digitalevidences rather than computer digitalevidences. A scenario constructed asfollowing:The production environment consistsphysically of four zones which eachzone has its own components, tools andrequirements. The first zone is a BasicHoneypots Zone acts as a local networkthat holds company's servers. Theseservers are Web Server and Secure Shell(IP=172.16.54.120), Data Base server,and Mail Server [18]. Ubuntu Serveroperating system is basically installedand configured on all of these serversaccording to their requirements. Then,Sebek client utility also installed on WebServer in order to capture Web Server'sactivities that sent through a securechannel and then immediately transferthem to Sebek Server. After that,Honeywall OS is installed on a local

network and acts as entry point of thelab's network. The Honeywall OSconsists of various tools that used tocollect and centralize the network'sevidences. These tools are SNORT 2.8.4

application that used as main sniffer andalso as Intrusion Detection or PreventionSystems (IDS/IPS). SNORT applicationis installed on Honeywall operatingsystem and then customized in order into log to a data base and dump network'spackets [21]. Lastly, Sebek Server isinstalled on Honeywall OS andconfigured to collect and log theencrypted connections to a data base.The second zone is a Hardened

Honeypot Zone that configured just toallow connection from specifiedproduction environment's servers[17][18][19][20][24]. This zone has logServer (IP=172.16.54.130) that mainlyused to record all of productionenvironment's servers activities [23].Indeed, Log Server accessing restrictionshave hardened by using of an IPTablesfirewall. The third zone that is aAdministrator Honeypot Zone thatbasically is used just by theadministrator in order to configure andadapt Honeywall OS. The accessibilityto a Honeywall OS only allowed throughan encrypted channel by using of SecureShell Server (IP=172.16.54.110). Thefourth zone is a Public Internet Zonewhich is generally offers the productionenvironment services to be accessible forthe world. This zone is often untrustedand has users they might be legal orillegal.However, an attacker compromised theproduction environment remotely whenhe obtained the root password throughbrute forcing SSH server. He then firstlyuploaded two scripts files used forobfuscating crimes traces. These filesmainly launched to remove chosen files


17/22



453

and folders such as log's files and folderswithin web server. After that, heconnected through encrypted channels(SSH) to avoid intrusion detectionsystems [25]. After that, he uploaded

another public key file to encrypt thecontents of web application and database and overwrite the original files aswell.

Now, analyzing results collected by theproposed solution helps us to discoverdigital crime's clues. Firstly, the attackerintentionally tried to login SSH serverthrough brute force attack and he

succeeds for logging as Fig. 7 depictsthat.

Fig. 12.Log Server received HoneypotsLogs.

Then, he uploaded two scripts namely BH-FE.rb [26] and BH-LSC.pl [27] throughSecure Shell server (SSH) in order tobypasses the intrusion detection system(IDS). After that, he encrypted the webapplication files and the data base files tooby using an uploaded public key. Finally, he

intentionally launched BH-FE.rb [26] andBH-LSC.pl [27] scripts in order to destroythe log files that normally used for forensicinvestigation. All of an attacker'scommands, and encrypted or unencryptedoperations captured by Snort and Sebekserver and then logged into data base. Thefollowing figures show these results:

Fig. 13.Launching Snort Utility.

Fig. 14.Network Evidences Logged by Snort.


18/22



454

Fig. 15. Network Evidences Logged by Sebek Architecture.

Fig. 16.Network Evidences Logged by SebekArchitecture (Cont.).

4.2 Guidelines to collect and centralize

network digital evidences:

Table 2 summarizes the guidelines forcollecting and centralizing network

digital

evidences. The first column of table isspecial for the mandatory requirednetwork components, then followed byexplaining their functions in the secondcolumn and ended with the best practices

which depict the best adopted ways ofdeployment in the third column.

Table 2: Network Evidences Collection and Centralization Guidelines.

Network Component Function Best Practices

Bridge Mode Hide theexistence of theOperatingSystem Networkstack since is

working underData Link Layerof OSI that usesMAC addressesfor connectionspurposes anddoes not assign

- Study the network topology properlyand then make a network designaccordingly as well.- Do not adopt network gateway that is aHoneywall OS in routing mode which

allow an attacker to probe it and checkand verify its existence.- Only configure the gateway underbridging modeon network layer of OSI.Applying that ensure this OperatingSystem that is a Honeywall OS will bedetectable by an attacker.


19/22



455

any InternetProtocol (IP).

- Do not assign any Internet Protocol (IP)on any others network interfaces. Exceptfor Internet Protocol (IP) formanagement purposes just accessible andallowable for Administrator.

Honeywall OperatingSystem (OS)

Hidden andundetectableform the outsideworld. It acts asa networkgateway and itsfunction is to bethe best place tocollect andcentralizenetwork

evidences. Itmediatesbetween outsideworld andservers insidethe lab network.

- Make sure network gateway isconfigured to work under bridging modeand then install and customize theHoneywall as mentioned previously.- Test the system by trying to access theweb server to make sure they areaccessible from outside the lab andeverything should work as wanted anddesigned.- Make sure that the only theadministrator is allowable to access the

Honeywall for the sake of configurationand management through encryptedconnections channels such as SocketSecure Layer (SSL) which is integratedwith Apache web server and also throughSecure Shell Server (SSH).- Make sure that Honeywall OSautomatic log out has configured as wellwhich helps to harden it.- Sensitive data such as a database, logfiles, and managing and controlling the

system; make sure that each system'susers has assigned the least privileges.- Ensure that all unused and unwantedservices are removed or stopped andports are closed too.- Ensure that Honeywall OS is installedon the network lab is updated versionsand patched as well.- Customize Honeywall OS according toyour requirements if needed.- Use alerting systems such as sending an

e_mail or SMS to alert you if an errorhas occurred.

Network Sniffing (Snort) Sniff, log, andrecord networkdata asevidences in runtime of network

- Data Sniffing and recording should beapplied and implemented through morethan one mechanism which preventssingle point of failure.- Data base and log files are the main


20/22



456

activities. methods of logging and storing the data.- Logging into binary and log servershould be applied too.- Only network data of interest should belogged and recorded.

- Tools used for logging processes shouldbe implemented and configured properly.- make sure the tools that sniff and lognetwork data keep original values out ofchanges.- Implement network data integrity andchain of custody.- Storage medias should be set up andconfigured based on network data ofinterest.- If necessary, sniffing and logging tools

should be customized in order to applynew feature and requirements.- Only authorized persons or usersallowed to access and manipulate thesenetwork data.- Sniffing and logging tools should beinstalled and set up on the gatewaywhich is Honeywall OS.- Snort application with variousconfigured methods and Sebekapplication are main tools to conduct this

mission.- make a test to ensure they are workingas designed and wanted.

Sebek Utility Sniff and logoperations andprocesses thathas executedthroughencryptedchannels.

- Sebek client application should beinstalled and configured properly on allnetwork lab servers.- Sebek server application also should beinstalled and configured properly too toreceive from Sebek clients application.- Ensure Sebek Client/Server should notchange the original values and take cares

with integrity.- Sniffing and logging processes shouldbe occurred in run time of networkactivities.- Sebek data should be Logged into both;data base and terminal.- Make a test to ensure is working isdesigned and required.


21/22



457

Log Server Record or logprocesses thathas happened oroccurred onlocal or remote

server

- Log Server should be configured toreceive remote loggings.- All network lab servers shouldconfigured and adapted to log remotelyto Log Server too.

- Accessing to Log Server should behardened and allowed just for networklab servers by setting up powerful andstrong Firewall rules.- All others unwanted services should beremoved and stopped and ports closedtoo.- Log Server physically should besecured and only authorized persons canaccess it.- Ensure all network lab is up to date.

- Make a test to ensure everything asdesigned.

5 CONCLUSION

In this research, the guidelines forcollecting and centralizing networkdigital evidences which the mainobjective of the research are eventuallystated and produced. Firstly, an intensive

investigation and analysis of networkforensic are fundamentally conducted inorder to overcome the inheritedshortcoming of computer forensic(operating system) which its traces couldbe removed or tampered with by anattacker as a final activity after theattacking has finished. Secondly, themethodology of the proposed solutionthat uses Honeynet Architecture tocollect and centralize network digital

evidences is designed, then resultsoutline of the experiment isdemonstrated in granular details andsubsequently the comparison among itssubsections is achieved in order toaddress their main key features that leadto come up with suitable guidelinesaccordingly. Finally, handy tested

guidelines to collect and centralizenetwork digital evidences are produced.

6 ACKNOWLEDGMENTS

This work of research has been done inUniversiti Teknologi Malaysia (UTM)under support of Ministry of HigherEducation, vote number 78567.

7 REFERENCES

1. Talabis, R. Honeynets: A HoneynetDefinition. The Philippine HoneynetProject. 1-4.

2. Justin Mitchell (2006). FundamentalHoneypotting. SANS Institute. 1-8.

3. Honeynet group. (2004). Know yourEnemy (2nd ed.). Addison-Wesley.

4. Almulhem, A., and Issa Traore I.Experience with Engineering aNetwork.


22/22

guidelines for collecting and centralizing network digital evidences

Documents