A Secure Method to Deliver Access Tokens to End Hosts

Size: px

Start display at page:

Download "A Secure Method to Deliver Access Tokens to End Hosts"

Buddy Randall Sanders
5 years ago
Views:

1 A Secure Method to Deliver Access Tokens to End Hosts Dr.V Asha 1, Ashwini M 2, Divyansh 3 1,2,3 Department of Master of Computer Applications, New Horizon College of Engineering, Abstract--IP traceback plays a pivotal part in cyber research process, where the sources and the navigated ways of packets must be identified. It is an approach for recognizing the originality of a packet on Internet. Its applications incorporate network forensics, security auditing, path validation, network fault diagnosis and performance testing. Few of the dominant dispute is that it still interfere an large-scale traceback result which is the matter of revealing ISP s internal network topologies (which means care of privacy leak), lack of additional distribution and lack of incentives for ISPs to offer traceback services. Here, it is demonstrated that cloud utilities give enhanced choices for practical deployment of an IP traceback framework. Presently, we introduce a creative cloud-based traceback architecture, which gains different strong assets urging ISPs to convey traceback utilities on their systems. While this makes the traceback utilities more accessible. Our outline objective is to keep ill-legal clients from asking for traceback data for suspicious desire, (for example, ISPs topology analysis). To this end, we propose a temporary token-based authentication system called Framework for authentication in cloud, for authenticating traceback utility queries. It implants transient access tokens in traffic flows, and after that conveys them to end-hosts in an efficient way. The proposed outcome guarantees that the entity asking for traceback benefit is an original recipient of the packets to be traced. Keywords--traceback,access control,authentication,cloud-based traceback,tokens. I.INTRODUCTION IP traceback is an efficient outcome to find the sources of packets in addition to the paths taken by the packets. It is mainly important to traceback network intruders or attackers with spoofed IP addresses, for attribution as well as attack defense and mitigation. For instance, traceback is helpful in protecting against Internet DDoS attacks. DoS assaults, for example, can be reduced when they are first revealed and then be traced back to their source and lastly prevented at their access points. The major challenge in acceptance of traceback techniques is that it has high risk of leaking network topology. ISPs(Internet Service Providers) usually does not allow any of the external party to access the internal structure because it leads to leakage of sensitive information and also makes their networks prone to attacks. So ISPs do not participate because the deployment of traceback can lose any sensitive information. Cloud Services support IP traceback over the internet and also provides a chance to form a traceback system that is deployable. In addition cloud storage increases the feasibility of logging traffic digests for forensic traceback. Cloud-based traceback makes the traceback process much simpler and more accessible. DOI: /IJRTER FKMGE 134

2 II.SYSTEM ARCHITECTURE A.Cloud-basedTraceback Architecture Figure 1. Cloud-based traceback Architecture The architecture consists of three layers, the central traceback coordinator layer, AS-level traceback server layer or overlay layer and router layer or underlying network layer. 1) Intra-AS Structure--Each traceback-deployed AS consists of a traceback server. The traceback-enabled routers collects all the traffic flow information and sends it to the internal cloud storage and the traceback server manages each AS for long-term storage and analysis. Traceback server can perform aggregation. As the local AS manages the traceback server and internal cloud storage all sensitive information are secured. Thus it guarantees stronger privacy-preserving of information. 2) Traceback Processing--Traceback process initiates with an investigator sending queries to the traceback coordinator. For example when a user sends a traceback request which consists of 5 flow ID i.e., srcid, dstid, srcport, dstport, protocol and the estimated attack time. The traceback server is first contacted by the traceback coordinator as in the same victim s domain that is responsible for the authentication of the traceback request. After verification, obtained result along with the upstream traceback-deployed AS information is returned back from the corresponding traceback server that has seen the flow of interest. Then the traceback coordinator sends a query to the traceback server of the upstream AS. The recursive query process is terminated by the traceback coordinator when the server identifies itself as the first traceback deployed AS on the attack path. An attack graph is generated for each traceback server for its local domain. This is an efficient traceback which avoids query All Rights Reserved 135

3 B.Need for New Traceback Authentication In cloud based traceback concept, an access to the cloud-based traceback service by a malicious entity which can retrieve all the recordings from the corresponding traceback server, there exists a risk in which a misbehaving user derives the ISP s network topology after collecting sufficient traceback results. Therefore, authentication has to be done by any entity that wants to perform traceback process.this paper proposes an enhanced user authentication scheme which is customized for access to traceback service in a cloud-based traceback system. III.AUTHENTICATION IN CLOUD-BASED TRACEBACK Here in this this section we describe a cloud based traceback using a novel token-based authentication. Here we present the adversary model and design goal followed by detailed descriptions of FACT authentication framework and its key components. A. Adversary Model and Design Goal It may be seen that traceback information can be acquired by an adversary for ill intentions. Potential attackers or competitors are examples of an adversary who can retrieve information for ISPs topology discovery. An adversary can trace users who visits certain websites by using traceback techniques to invade internet-user s privacy. Main design goal is to ensure that the individual requesting for the traceback procedure is an actual receipt of the packet flow to be traced which prevents users with malicious intent from retrieving the traceback information. DoS attacks to traceback services can also be prevented by user authentication. B. Cloud-based Traceback Design 1)Overview of Framework--To protect sensitive information in the environment of cloud computing we use token-based access control. This token is used for authentication instead of using username and password for protected resources. Figure 2.Temporal token-based authentication in cloud based traceback The above figure illustrates the proposed framework for authentication in cloud-based IP traceback. Here a validity period which is associated with an access token where it gives permission to access traffic flow data for a specific period. The temporal access tokens are distributed to end hosts by the traceback server. The traceback logs can be retrieved later on-demand by end users who subscribes for traceback service. As illustrated in the above figure, the last-hop router plays an important role by sending tokens to end-host.in common we assume that the failure of the router will not affect the token marking functionality because the backup router becomes active during All Rights Reserved 136

4 The main goal is to carry access tokens to end hosts using traffic flow which incurs extra message overhead.also it makes easier for the access token to know only to the actual recipients of the packet flow who want to retrieve the flow information later in a cloud-based track system. From the figure traceback client role is to extract the token from incoming marked packets and also the reconstructed access token can be used in future by storing it. It hides the actual implementation from the end host which can be considered as the black box. The traceback information can be retrieved with a valid access token from an end host through the cloud-based track system. B. Match-based Marking for Token Delivery The main goal is to maintain efficient token delivery by adapting to limited marking space in IP header. For then we need only a minimum of 1-bit flag to ensure that the packet contains the token. If the size of the token example, if there is an entire bitwise mismatch between pre-defined packet fields and the token, the bit values in specific packet fields and the token are entirely equivalent is 64bits and the bit values if the packet are random variables then there are chances of a full match that could be low. Also using only one packet to deliver a token is prone to packet drop attacks. Here we propose an idea to spread a token across a wide range of packets using an efficient token delivery scheme, which makes it difficult to capture the token and also reduce the risk of packet dropping attacks which minimizes the bit space for a packet required for marking. The primary idea is that, we partition a token into a sequence of non-overlapping fragments. In an IP packet at the last-hop router, we check whether a packet s certain field of this packet matches any fragmentof the token that has been received by an end-host. If a match is found then the packet is marked so that it notifies the end-host which carries partial information about the token. When a marked packet is received by the end-host the partial token information embedded in the received packet will be extracted. In order to find attributes in IP packets for token fragment match with largest variance in an access token which is essentially a random bit string. The check sum will not be adjusted when it arrives at the end host because the matching operation is only performed at the last hop after the check sum is recalculated. The IP header check sum for token fragment match cannot be used because the Network Address Translator (NAT) is in effect. When the packet arrive at the destination host and the check sum value is calculated because NAT changes the IP address. For example, let PA be the selected pair attribute for token fragment match. The token fragment match is first defined and then the marking procedure is defined. Token Fragment Match: The selected attribute(pa) and a given token fragment(tf) of an IP packet, if PA contain bits that are set to 1 intf and PA retains all the bits that are set to 0 in TF, this is called token fragment match between PA and TF. Above is an example of the matched token fragment where the size of a token fragment TF is 16 bits. Mismatched token fragment example shows that PA fails to retain all the cleared bits in TF as it does not match with TF. Concise Marking: Blind marking is a simple marking scheme which makes the last hop router simply mark all the packets that match any token fragment.one disadvantage of blind marking is that All Rights Reserved 137

5 portions of the token that has been relayed to an end host has not been tracked by the last hop router. Whether an access token has been fully matched or not it has to be executed throughout a specified time period.the blind marking may result in marked packets carrying redundant information to the end host when a partial token has already been formed at the end host. Figure 3.Concise Marking Scheme Example Whenever a token fragment match is found by the last-hop router it marks the packets and takes note on which bit values have been relayed to the end-host. The token delivery progress to an end-host is kept track by the last-hop router. The packet can carry new set bit values to the end-host if and only of the next packet is marked. Example, at time t1, TF0 and TF1 checks whether the token fragment matches with PA and then the last-hop router updates their remaining set bits as and accordingly.at time t3 the remaining set bits of TF3 are updated as At time t4 a redundant token is found and thus it will not perform packet marking. Algorithm 1--Token delivery using concise marking Input: Token fragments T Fi, i 2 [0; n 1] Output: Marked packets 1 remainingbitsi T Fi;i 2 [0; n 1] 2 while ConciseMarking (Packet P) do 3 MA = getpairattribute(p); 4 mark 0; 5 for i=0 to n 1 do 6 if ConciseMatch (MA, T Fi, &remainingbitsi) then 7 mark = (1 (8-i)); //8-bit marking space 8 end 9 end 10 if mark 6=0 then 11 MarkPacket(P, mark); 12 end 13 if 8 i, remainingbitsi == 0 then 14 break; 15 end 16 All Rights Reserved 138

6 For example,if there is an access token that has to be delivered to an end host,when a packet is received by the last hop router it first extracts PA (pair attribute,line 3). Likewise, a concise token fragment match is sequentially checked for all token fragments. In the packets IP header the marking filed is updated and embedded if it is true. Therefore, the number of set bits that the token has is the maximum number of packets to be marked. It also gives an end point to the token delivery. The token delivery process will be ended if the entire token has been relayed to the host so that there will be no need to mark any further packets (line 13-15). Algorithm 2: Concise token fragment match 1 Function: bool ConciseMatch(value, T F, *remainingbits) 2 if (value key) & value == 0 then 3 return false; 4 end 5 compltdbits = (T FremainingBits); 6 newbits = value& (compltdbits); 7 if newbits == 0 then 8 return false; 10 remainingbits = (remainingbits value) & (compltdbits); 11 return true; In line 2-4 it make sure there is a token fragment match. Further it checks if there is any new bits that can be conveyed by the selected attribute. Finally each token fragment is updated i.e., the remaining set bits (line 10). IV. EVALUATION A. Experiment Settings On Ubuntu Linux desktops using the libcap library we are implementing the token delivery scheme. We invoke the pcap_next_ex function which is capable of retrieving the IP header of the next captured packet by emulating a last-hop router that receives packets from an offline capture ex: MAWILab [50] traffic traces. The program checks whether or not to mark the captured packet for a token to be delivered to the end-host.pcap_dump function is called to output a marked packet which is then send to the end-host. Next we partition a single 1.6 GB MAWILab tcpdump tracefile to multiple traces and select three different files randomly to evaluate our solution. The outputs are averaged to over 500 runs and the resulted standard deviations are provided as error bars. Token extraction and management at the end-host for traceback client is implemented. Token extraction is just the opposite of token marking. An access token table is maintained by the traceback client for which it stores the token and the received time in the table when it is successfully received. For the token delivery to be initiated, the traceback client considers the marked packet as preamble with all set bits in the marking field that it has received. To end the token delivery the consecutive marked packets received is considered postamble. However it delays for short period of time to distinguish the preamble and postamble. As an experiment we compare the performance of the blind marking and concise marking schemes. Both schemes do have delay in their token delivery performance. Below is a report of the results of the number of marked All Rights Reserved 139

with respect to the number of marked packets. Concise marking provides significant marking overhead reduction when compared to blind marking for 25% set bits cases.

7 Figure 4.MAWILab dataset s impact on token pattern As depicted in the above table with test cases for 25% set bits, blind marking scheme is incurred by times higher than that of the concise marking with respect to the number of marked packets. Concise marking provides significant marking overhead reduction when compared to blind marking for 25% set bits cases. Robustness of the token delivery against packet drops increases by redundancy in packet marking. V. CONCLUSION AND FUTURE WORK In this paper, we first presented the cloud-based IP traceback architecture which has favorable properties that the previous traceback schemes failed to satisfy. We then focused on preventing illegitimate users from requesting traceback information for ill intentions. To the end, we proposed an enhanced user authentication framework which makes sure that the entity requesting for the traceback procedure is an actual recipient of the flow packets to be traced. As our future work, we would be investigating the optimal marking scheme in token delivery and also implement the framework for authentication on our cloud-based IP traceback test bed. REFERENCES I. A.Perrig and D.X. Song, Advanced and authenticated marking schemes for IP traceback. N.Ansari and A.Belenky, On Deterministic Packet Marking. R. Doss, W. Zhou, W. Jia and S. Yu, Traceback of ddos attacks using entropy variations. N.Ansari and Z.Gao, A practical and robust inter domain scheme for IP traceback. II. III. All Rights Reserved 140

DoS Attacks. Network Traceback. The Ultimate Goal. The Ultimate Goal. Overview of Traceback Ideas. Easy to launch. Hard to trace.

DoS Attacks. Network Traceback. The Ultimate Goal. The Ultimate Goal. Overview of Traceback Ideas. Easy to launch. Hard to trace. DoS Attacks Network Traceback Eric Stone Easy to launch Hard to trace Zombie machines Fake header info The Ultimate Goal Stopping attacks at the source To stop an attack at its source, you need to know