\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={Modeling and Counter Measures of Flooding Attacks to Internet Threat Monitors (ITM): Using Botnet and Group-Testing approach},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2011-12 2011-12-07 (revised: 2011 December 07 December 2011)}
\def\TheID{\makeatother }
\def\TheDate{2011-12 2011-12-07}
\title{Modeling and Counter Measures of Flooding Attacks to Internet Threat Monitors (ITM): Using Botnet and Group-Testing approach}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{K Munivara  Prasad}

             \author[2]{Dr.A Rama Mohan  Reddy}

             \affil[1]{  Rayalaseema University,Kurnool}

\renewcommand\Authands{ and }

\date{\small \em Received: 1 November 2011 Accepted: 22 November 2011 Published: 7 December 2011}

\maketitle


\begin{abstract}
        


The Internet Threat Monitoring (ITM),is a globally scoped Internet monitoring system whose  goal is to measure, detect, characterize, and track threats such as distribute denial of service(DDoS)  attacks and worms. To  block the monitoring system in the internet the attackers are targeted the ITM  system. In this paper we address flooding attack against ITM system in which the attacker attempt to  exhaust the network and ITM?s resources, such as network bandwidth, computing power, or operating  system data structures by sending the malicious traffic. We propose an information-theoretic frame work  that models the flooding attacks using Botnet on ITM.we propose a novel group testing (GT)-based  approach deployed on back-end servers, which not only offers a theoretical method to obtain short  detection delay and low false positive/negative rate, but also provides an underlying framework against  general network attacks.

\end{abstract}


\keywords{Internet Threat Monitors (ITM), DDoS, Flooding attack, Botnet and Honeypot, Group testing.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{I. INTRODUCTION}]{I. INTRODUCTION}\par
nternet security is increasing in importance. Yet, despite decades of research, we are still unable to make secure computer networks. Further, more sophisticated and new attacks are expected to continue posing a greater degree of threat to Internet services. As a result, a more fundamental model, in terms of theoretical and system perspectives, regardless of attack types must be investigated. An essential problem to overcome for any defense mechanism is the fact that malicious traffic/packets can be similar to legitimate ones.\par
Denial-of-Service (DoS) is a major security problem in computer systems and networks. In a DoS attack, a group of attackers try to make a service unavailable to legitimate clients for unacceptably long periods of time. Service-level DoS attacks target server resources by issuing legitimate-like service requests at a high rate to overwhelm the victim servers. These attacks, attempt to exhaust the victim's resources, such as network bandwidth, computing power, or operating system data structures. Flood attack, Ping of Death attack, SYN attack, Teardrop attack, DDoS , and Smurf attack are the most common types of DoS attacks. The hackers who launch DDoS attacks typically target sites or services provided by high-profile organizations, such as government agencies, banks, credit-card payment gateways, and even root name servers.\par
A flooding-based Distributed Denial of Service (DDoS) attack is a very common way to attack a victim machine by sending a large amount of unwanted traffic. Network level congestion control can throttle peak traffic to protect the network. Network monitors are used to monitor the traffic in the networks to classify them as genuine or attack traffic and also these monitors gives the traffic as an input to several DDoS detection algorithms for detection of DDoS attacks. However, it cannot stop the quality of service (QoS) for legitimate traffic from going down because of attacks. Two features of DDoS attacks hinder the advancement of defense techniques. First, it is hard to distinguish between DDoS attack traffic and normal traffic. There is a lack of an effective differentiation mechanism that results in minimal collateral damage for legitimate traffic. Second, the sources of DDoS attacks are also difficult to find in a distributed environment. Therefore, it is difficult to stop a DDoS attack effectively.\par
The Internet Threat Monitoring (ITM) System basically has two main components one is centralized data center and another is the number of monitors which are distributed across the Internet. Each monitor covers the range of IP addresses and monitors the traffic to send the traffic logs to data center. The data center now collects the traffic logs from monitors and analyzes the collected traffic logs to publish reports to ITM system users.\par
The collected logs, as a random sample of the Internet traffic, can still provide critical insights for the public to measure, characterize, and track/detect Internet security threats. The idea of ITM systems dates back to DShield and CAIDA network telescope \hyperref[b3]{[4]}, \hyperref[b4]{[5]}, which have been successfully used to analyze the activities of worms and DDoS attacks \hyperref[b2]{[3]}, \hyperref[b5]{[6]}.The reason is that if an attacker discovers the monitor locations, it can easily avoid detection (by ITM systems) by bypassing the monitored IP addresses and directing the attack to the much larger space of unmonitored IP addresses. Furthermore, such an attacker may even mislead the reports published by an ITM system by manipulating traffic to the identified monitors, generating highly skewed samples. Since ITM reports are trusted by the public as a random (unbiased) sample of Internet traffic, the confidentiality of monitor locations is vital for the usability of ITM systems.\par
The monitor locations of an ITM system can be compromised by introducing several attacks by the attackers which includes Localization attacks \hyperref[b0]{[1]} and DDoS Attacks which exploits some vulnerability or implementation bug in the software implementation of a service to bring that down or that use up all the available resources at the target machine or that consume all the bandwidth available to the victim machine, this is called as Bandwidth attacks.\par
The main goal of our work is to perform the identification of attackers much faster by testing them in group instead of one by one. This will help to detect the flooding attacks, So that if any ITM is found under attack, we can immediately identify and filter the attackers out of its client set. Apparently, this problem resembles the group testing (GT) theory \hyperref[b13]{[14]} which aims to discover defective items in a large population with the minimum number of tests where each test is applied to a subset of items, called pools, instead of testing them one by one. Therefore, we apply GT theory to this network security issue and propose specific algorithms and protocols to achieve high detection performance in terms of short detection latency and low false positive/negative rate.\par
In this paper we introduce an information theoretic frame work model to existing flooding attacks on ITM system monitors. In the flooding attack the attacker sends the large volume of unwanted traffic to the targeted monitor by using the botnet or huge number of compromised systems. Based on the Information-theoretic model we propose a Group Testing based approach to detect flooding attacks. 
\section[{II. RELATED WORK}]{II. RELATED WORK}\par
Probing traffic based Localization attack \hyperref[b6]{[7]} \hyperref[b7]{[8]} in which an attacker sends high rate short length port scan messages to the targeted network to compromise the monitor locations in ITM system. Then, attacker queries the data center to determine whether a short spike of high-rate traffic appears in the queried timeseries data, for confirmation of the attack.\par
A steganographic localization attack \hyperref[b8]{[9]} an attacker launches a stream of low-rate port-scan probing traffic which is marginally modulated by a secret Pseudonoise (PN) code. While the low-rate property prevents the exhibition of obvious regularity of the published traffic data at the data center, based on the carefully synchronized PN code, the attacker can still accurately identify the PN-code-modulated traffic in the retrieved published traffic data from the data center. Thereby, the existence of monitors in the targeted network can be compromised. To this end, the PN -code-based steganographic attack presented in our paper can be understood as a covert channel problem \hyperref[b9]{[10]}, because the attack traffic encoded by a signal blends into the background traffic and is only recognizable by the attacker which knows the secret pattern of the PN code.\par
In \hyperref[b0]{[1]} introduced the information theoretic framework to evaluate the effectiveness of the localization attacks by using the minimum time length required by an attacker to achieve a predefined detection rate as the metric. But this frame work is defined in specific to the localization attacks only; they are not given any solution for other DDoS attacks. The frame work allows the ITMs which are registered within the data center given, and the access is restricted to that private region only. But public access of the ITMs and data center allows more scope to provide security against different attacks.\par
Group Testing (GT) based approach \hyperref[b16]{[17]} is used to detect the application denial of service attacks, there the efficiency of the attack detection is improved by testing the traffic by group instead of one by one. The GT approach also minimizes the false positives and false negatives comparatively to the input traffic. But the GT approach can be applied to the DDoS detection whenever the number of attackers known in advance. This assumption will not be suitable for all DDoS attacks. 
\section[{III. PROPOSED WORK}]{III. PROPOSED WORK}\par
In \hyperref[b0]{[1]} the authors define a model in which the ITMs in the networks sends the traffic logs periodically to the data center and the data center collects the traffic logs and publishes the reports to ITM system users which are registered, that means it creates the private environment or region .In the private region the scope for DDoS attacks are very less, and they are restricted this model only for Localization attacks. In this section we have defined a model which will provide the following extensions.\par
Public accessing : Public accessing of the data center increases the network usage and provides better communication with the outside world rather than private environment. In this any user from outside the private region can get the communication with the private network, if the user is genuine he can get the status of the monitor before sending the data to internal monitors, to avoid the attacks. If the user is an attacker, then this status information can be misused to perform the attacks on the monitor. The data center sends the status information to any users (public or private) based on the request query, but the private (internal) users can get the highest priority.\par
Usage of Botnets for Flooding Attack : A denialof-service (DoS) attack is an explicit attempt by attackers to prevent an information service's legitimate users from using that service. In a DDoS attack, these attempts come from a large number of distributed hosts that coordinate to flood the victim with an abundance of attack packets simultaneously. The attacker may use the botnets \hyperref[b10]{[11]}, \hyperref[b11]{[12]} and other alternatives to launch the attack. 
\section[{a) Flooding}]{a) Flooding}\par
Launching a flooding attack : Once the DDoS network has been set up and the infrastructure for communication between the agents and the handlers established, all that an attacker needs to do is to issue commands to the agents to start sending packets to the victim host. The agents try to send unusual data packets (all TCP flags set, repeated TCP SYN packets, Large ICMP packets) to maximize the possibility of causing disruption at the victim and the intermediate nodes.\par
There are certain basic packet attack types which are favorites of the attack tool designers. All the attack tools use a combination of these packet attack types to launch a DDoS attack. The basic attack types are i. TCP floods : A stream of packets with various flags (SYN,RST, ACK) are sent to the victim machine.\par
The TCP SYN flood works by exhausting the TCP connection queue of the host and thus denying legitimate connection requests. TCP ACK floods can cause disruption at the nodes corresponding to the host addresses of the floods as well. Also the one known tool that uses TCP ACK flooding (mstream \hyperref[b12]{[13]}) has been known to cause disruptions in a router even with a moderate packet rate. Both TCP SYN flooding and the mstream attack constitute a group of attacks known as asymmetric attacks (Attacks where a less powerful system can render a much more powerful system useless). ii. ICMP floods (e.g ping floods) : A stream of ICMP packets is sent to the victim host. A variant of the ICMP floods is the Smurf attack in which a spoofed IP packet consisting of an ICMP ECHO\textunderscore REQUEST is sent to a directed broadcast address. The RFC for ICMP specifies that no ECHO\textunderscore REPLY packets should be generated for broadcast addresses, but unfortunately many operating systems and router vendors have failed to incorporate this into their implementations. As a result, the victim host (in this case the machine whose IP address was spoofed by the attacker) receives ICMP ECHO\textunderscore REPLY packets from all the hosts on the network and can easily crash under such loads. Such networks are known as amplifier networks and thousands of such networks have been documented. iii. UDP floods : A huge amount of UDP packets are sent to the victim host. Trinoo is a popular DDoS tool that uses UDP floods as one of its attack payloads. 
\section[{b) Bots}]{b) Bots}\par
Studying the evolution of bots and botnets provides insight into their current capabilities. One of the original uses of computer bots was to assist in Internet Relay Chat (IRC) channel management \hyperref[b13]{[14]}. IRC is a chat system that provides one-to-one and one-to-many instant messaging over the Internet. Users can join a named channel on an IRC network and communicate with groups of other users. Administering busy chat channels can be time consuming, and so channel operators created bots to help manage the operation of popular channels. One of the first bots was Eggdrop, which was written in 1993 to assist channel operators \hyperref[b0]{[1]}.\par
In time, IRC bots with more nefarious purposes emerged. The goal of these bots was to attack other IRC users and IRC servers. These attacks often involved flooding the target with packets (i.e., DoS attacks). The use of bots helped to hide the attacker because the attack packets were sent from the bot rather than directly from the attacker (assuming a non-spoofed attack). This new level of indirection also allowed multiple computers to be grouped together to perform distributed attacks (DDoS) and bring down bigger targets. Larger targets required more bots, and so attackers looked for methods to recruit new members. Since very few users would agree to have their computers utilized for conducting packet floods, attackers used trojaned files and other surreptitious methods to infect other computers. 
\section[{c) IRC-based Command and Control}]{c) IRC-based Command and Control}\par
A bot must communicate with a controller to receive commands or send back information. One method for establishing a communication channel is to connect directly to the controller. The problem is that this connection could compromise the controller's location. Instead, the bot controller can use a proxy such as public message drop point (e.g., a well-known message board). However, because websites and other drop points can introduce significant communication latency, a more active approach is desirable. A wellknown public exchange point that enables virtually instant communication is IRC.\par
IRC provides a common protocol that is widely deployed across the Internet and has simple text-based command syntax. There is also a large number of existing IRC networks that can be used as public exchange points. In addition, most IRC networks lack any strong authentication, and a number of tools to provide anonymity on IRC networks are available. Thus, IRC provides a simple, low-latency, widely available, and anonymous command and control channel for botnet communication. An IRC network is composed of one or more IRC servers as depicted in Figure  {\ref 1}.\par
In a typical botnet, each bot connects to a public IRC network or a hidden IRC server on another compromised system. The bot then enters a named channel and can receive commands directly from a controller or even from sequences encoded into the title of the channel. 
\section[{d) Group Testing}]{d) Group Testing}\par
The first application of group testing was during WWII; instead of testing every blood sample individually, groups of samples were pooled together and tested collectively. If the outcome of the group test is negative, all samples in the group are good (diseasefree). Although group testing has been used since then in many security and networking applications, such as data forensics, cryptography, multiple-access channels, and broadcast security against jamming, our work is the first to apply this powerful theory to the DoS attack problem.\par
Group testing aims mainly at identifying the defective (special) members of a population with few tests. There are two classes of group-testing mechanisms. "Non-adaptive", or single-stage, specifies all tests simultaneously without the benefit of using the outcomes of previous tests to determine the present test. Adaptive (multi-stage) group testing uses feedback from previous test results to determine subsequent tests.\par
ii. Detection of defective members\par
The detection algorithm discovers the defective members using the result vector and Members Test (defectives underlined) Results. An example of a grouptesting matrix. the matrix. The algorithm we use in this paper works by excluding a negative (non-defective) member if it participates in a "large enough" number of tests with a negative result. For instance, if we assume that a member has to participate in only one negative test to be excluded, then in the above example; members 1, 3, 4, 5, 7, 9, and 10 will be excluded. This leaves us with the defective members 2, 6, and 8 as suspects. In this specific example, all defective elements are detected, and all non-defective members are cleared.\par
iii. Apply to Attack Detection A detection model based on GT can be assumed that there are T virtual servers and N clients, among which d clients are attackers shown in fig.\par
Consider the matrix M ,the clients can be mapped into the columns and virtual servers into rows in M, where M [i,j]=1 if and only if the requests from client j are distributed to virtual server i. With regard to the test outcome column V, we have V [i]=1 if and only if virtual server i has received malicious requests from at least one attacker, but we cannot identify the attackers at once unless this virtual server is handling only one client. Otherwise, if V [i]=0, all the clients assigned to server i are legitimate. The d attackers can then be captured by decoding the test outcome vector V and the matrix M. 
\section[{iv. False Positive and False Negative Probabilities}]{iv. False Positive and False Negative Probabilities}\par
A false positive is when a non-defective member gets falsely identified as defective, while a false negative is when a defective member ends up being not detected. In the example above, both the false positive probability and the false negative probability are 0. In general, simple detection algorithm discussed above detects all defective members with the false positive probabilityFP = [1?p(1?p)d]T ,\par
Where d is the number of defective members in the group and T is the number of tests used to detect defective members. By differentiating the above equation with respect to p, the optimal value of p, the value that yields the minimum false positive probability, is 1/d+1. Thus, the minimum false positive probability for a given number of tests T is: Finally, from Eqn. 1 we derive the number of tests, Tfp, required to achieve a target false positive probability fp:i. Basic Idea\par
The basic group testing is modeled as a T × N matrix, where N is the total number of members, and T is the number of tests. Matrix rows represent tests and columns represent group members. When a matrix element (i, j) is set to 1, this means that member j participates in test i. An example of a group testing matrix for a population of 10 members with 4 tests is shown in Figure  {\ref 1}. Test results are represented as a vector with an element for each test. For simplicity we assume that the test results are binary. So, a test result is set to 1 if the corresponding test returns a positive result, that is, if the test was applied to a group with at least one defective member. In the example shown in Figure  {\ref 1} the 2nd, 6th, and 8th members are defective. Where ?attack refers the the probability of attack and d is the expected number of attackers.\par
IV. 
\section[{PROPOSED MODEL}]{PROPOSED MODEL}\par
In this paper we divided the entire model into two regions namely private region and public region. The Internet Threat Monitors (ITM) are distributed across the Internet and each monitor records the traffic addressed to range of IP addresses and send the traffic logs periodically to the data center. The data center then analyzes the traffic logs collected from the monitors and publishes the reports to ITM system users. The collection of monitors under the data center forms the private region because the ITMs are registered before sending the logs to the data center. Any user can get the reports of the requested ITM by sending the query request to the data center and the data center is answerable to all the ITMs which are registered.\par
The public region of our model specifies the unregistered users of the data center who does not have any permission to access the data center, but they can get the traffic reports related to any ITM by sending the query request to the data center. The data center scope is extended to the public domain but it can only give the traffic reports to the public users. Allowing the public users or network accessing to the data center and monitors, causes decrease in the performance because of the overload of the data center. These can be balanced by introducing the priorities to the users; the internal or private region users have the highest priority than the public users .This priorities does not disturb the existing scenario but this can enhance the service to the public domain ,this will not be a over burden to the data center.\par
In This section we are constructing the botnet as the public user network without having any registration with data center and performing the flooding attack on the ITM which is local to the data center. 
\section[{i. Generation of flooding attack with Botnet}]{i. Generation of flooding attack with Botnet}\par
A DDoS (Flooding) attack mechanism typically includes a network of several compromised computers \hyperref[b14]{[15]}. These compromised computers serve three major role -master controller, command and control (C\&C) server, and bot. An attacker prepares a DDoS attack by exploiting vulnerabilities in one computer system and making it the DDoS "master controller." From here, the attacker identifies and communicates with other compromised systems. A C\&C server is a compromised host with a special program running on it, this server distributes instructions from the attacker to the rest of the bots, which form a botnet \hyperref[b10]{[11]}. (A bot is a compromised host that runs a special program.) Each C\&C server is capable of controlling multiple bots, each of which is responsible for generating a stream of packets to the intended victim. Often, the bots employed to send the flood of requests are infected with a virus that lets attackers use them anonymously.\par
A Flooding attack happens in several phases : ? Launch an attack. In the next phase, attackers send commands to C\&C servers for their bots to attack by sending hundreds of thousands of requests to the target simultaneously. ? Flood a target. In the final phase, monitor receives a flood of requests to the point where they can't operate effectively.\par
ii. Conformation of attack\par
The attacker queries the data center for the traffic reports. Such traffic reflects both flooding requests traffic and other traffic collected from all monitors. Then the attacker confirms the attack by checking the status of the ITM in the traffic reports published by the data center. 
\section[{V. PREVENTION}]{V. PREVENTION}\par
Preventive mechanisms attempt either to reduce the possibility of DDoS attacks or enable potential victims to endure the attack without denying services to legitimate users. Resource multiplication essentially raises the bar on how many bots must participate in an attack to be effective. While not providing perfect protection, this last approach has often proved sufficient for smallto mid-range DDoS attacks. 
\section[{Preventing Flooding Attacks}]{Preventing Flooding Attacks}\par
In this section we introduce a general methodology to prevent flooding attacks. It is based on the following line of reasoning:\par
1) To mount a successful Flooding attack, a large number of compromised machines are necessary. 2) To coordinate a large number of machines, the attacker needs a remote control mechanism. 3) If the remote control mechanism is disabled, the Flooding attack is prevented.\par
Our methodology to mitigate flooding attacks aims at manipulating the root-cause of the attacks, i.e., influencing the remote control network. Our approach is based on three steps:\par
1. Infiltrating the remote control network. 2. Analyzing the network in detail. 
\section[{Shutting down the remote control network.}]{Shutting down the remote control network.}\par
In the first step, we have to find a way to smuggle an agent into the control network. In this context, the term agent describes a general procedure to mask as a valid member of the control network. This agent must thus be customized to the type of network we want to plant it in. The level of adaptation to a real member of the network depends on the target we want to infiltrate. For instance, to infiltrate a botnet we would try to simulate a valid bot, maybe even emulating some bot commands.\par
Once we are able to sneak an agent into the remote control network, it enables us to perform the second step, i.e., to observe the network in detail. So we can start to monitor all activity and analyze all information we have collected.\par
In the last step, we use the collected information to shut down the remote control network. Once this is done, we have deprived the attacker's control over the other machines and thus efficiently stopped the threat of a flooding attack with this network. Again, the particular way in which the network is shut down depends on the type of network. 
\section[{VI. DETECTION OF FLOODING ATTACKS}]{VI. DETECTION OF FLOODING ATTACKS}\par
In this section we present efficient way of detecting the attacks on the ITMs in the given information theoretic frame work. We divide the attack detection process into two phases, Firstly the primary detection of DDoS attacks on the ITMs and the later is the detection of flooding attacks on the ITMs.\par
In the primary detection phases the system detects the attacks based on traffic information aggregated from all monitors in the ITM system. If the overall traffic rate (e.g., volume in a given time interval) exceeds a predetermined threshold, the defender issues an alarm. The threshold value can be maintained either at data center or the individual ITMs based on the type of schemes used \hyperref[b0]{[1]} in the network.In the primary detection phase the system detects some attack was happened in the network. If the detection scheme is centralized, then whenever the aggregate traffic exceeds the threshold maintained at the data center then the data center finds the attack and that attacked monitor can be identified by verifying the individual traffic logs of each ITM from the report. Otherwise if the detection strategy is distributed then each monitor maintained an individual threshold and checked the aggregate traffic regularly. If the traffic exceeds the threshold then it find the attack was happened and sends the status as attacked to the data center. After getting the attacked status from the ITM the data center blocks the corresponding ITM and displays the status of the ITM as blocked in the status reports, which will avoids the further traffic to or from the attacked ITM with the rest of the networks.\par
The second stage of detection specifies the detection of the flooding attacks. Once the attack is conformed then the data center identifies the attacked monitor and the traffic logs will be handover to the flooding detection phase. The flooding detection phase then performs the group testing (GT) on the traffic, then identifies the attackers from the client traffic set.\par
In this section we define group testing (GT) based DDoS detection methods for flooding detection on ITMs in information frame work defined, and also detection of false positives and false negatives in the network for large flow size. 
\section[{a) BOTNET Detection}]{a) BOTNET Detection}\par
Botnets are a very real and quickly evolving problem that is still not well understood. In this paper, we outline the problem and investigate methods of stopping bots. We identify three approaches for handling botnets:\par
1) Prevent systems from being infected, 2) Directly detect command and control communication among bots and between bots and controllers, and, 3) Detect the secondary features of a bot infection such as propagation or attacks.\par
The first approach is to prevent systems from being infected. There are a range of existing techniques, including anti-virus software, firewalls, and automatic patching.\par
The second approach is to directly detect botnet command and control traffic. Botnets today are often controlled using Internet Relay Chat (IRC) and one possible method of detecting IRC-based botnets is to monitor TCP port 6667 which is the standard port used for IRC traffic. One could also look for non-human behavioral characteristics in traffic, or even build IRC server scanners to identify potential botnets.\par
We argue there is also a third approach that detects botnets by identifying secondary features of a bot infection such as propagation or attack behavior. Rather than directly attempting to find command and control traffic, the key to this approach is the correlation of data from different sources to locate bots and discover command and control connections.\par
In this paper we investigate the second approach for stopping botnets. The problem with the first approach is that preventing all systems on the Internet from being infected is nearly an impossible challenge. As a result, there will be large pools of vulnerable systems connected to the Internet for many years to come. 
\section[{b) Detecting Command and Control}]{b) Detecting Command and Control}\par
To combat the growing problem of bots, we identified two approaches for detecting botnets: detect the command and control communication, or detect the secondary features of a bot infection. In this section we study methods of detecting botnets by directly locating command and control traffic. 
\section[{i. IRC-based Botnet Detection}]{i. IRC-based Botnet Detection}\par
Today, most known bots use IRC as a communication protocol, and there are several characteristics of IRC that can be leveraged to detect bots. One of the simplest methods of detecting IRCbased botnets is to offramp traffic from a live network on known IRC ports (e.g., TCP port 6667) and then inspects the payloads for strings that match known botnet commands. Unfortunately, botnets can run on non-standard ports. Another method is to look for behavioral characteristics of bots. One study found that bots on IRC were idle most of the time and would respond faster than a human upon receiving a command. The system they designed looked for these characteristics in Netflow traffic and attempted to tag certain connections as potential bots \hyperref[b14]{[15]}.\par
The approach was successful in detecting idle IRC activity but suffered from a high false positive rate. Given problems such as false positives on live networks, another approach is to use a non-productive resource or honeypot.\par
One group set up a vulnerable system and waited for it to be infected with a bot. They then located outgoing connections to IRC networks and used their own bot to connect back and profile the IRC server \hyperref[b15]{[16]}. However, they did not take the next step and develop a detection system based on the technique.\par
Rather than connecting to the IRC server directly, another approach is to use a honeypot to catch the bot and then look for characteristics of command and control traffic in the outgoing connections. We located all successful outgoing TCP connections and verified that they were all directly related to command and control activity by inspecting the payloads. There were a wide range of interesting behaviors, including connections from the bot to search engines to locate and use bandwidth testers, downloading posts from popular message boards to get server addresses, and the transmission of comprehensive host profiles to other servers.\par
These profiles included detailed information on the operating system, host bandwidth, users, passwords, file shares, filenames and permissions for all files, and a number of other minute details about the infected host.\par
We then analyzed all successful outgoing connections and looked for specific characteristics that could be used to identify botnet command and control traffic. The results suggested that there are no simple characteristics of the communication channels themselves that can be used for detection. For example, the length of the outgoing connections varied widely, with certain connections lasting more then 9 hours and others less than a second.\par
The number of bytes transferred per connection also varied widely even when we separated out IRC communication from other command and control activity. The results from our analysis nor the results from previous bot detection efforts has revealed any simple connection-based invariants useful for network detection. One might inspect every payload of every packet however this is currently very costly on high throughput networks. More importantly, attackers can make small modifications that make detection nearly impossible.\par
ii.\par
Efficiency : The efficiency of the detection system is depends on the number of honeypots placed in the network. If one honeypot is used to perform the detection in centralized approach, then more than one ITM is attacked automatically the honeypot will be overloaded and it takes more time to detect the attackers. Otherwise if the detection system is distributed, then the efficiency of the detection system is improved, but it is very much cost effective, practically not possible for the large networks.\par
In GT approach the detection process can be carried out only at data center by collecting the traffic logs from the attacked ITM through data center same as the centralized detection of the honeypot approach. Unlike honeypot detection, the efficiency of the detection process does not depend on the traffic because huge amount of traffic also processed in terms of pools in the GT approach and handled successfully. The pools or groups can be as inputs for multiple rounds of different tests in GT approach to check for different anomalies in the input malicious traffic.\par
Reliability : One honeypot for each ITM approach is reliable but it is practically very difficult to manage and maintained. If the centralized honeypot compromises then total detection process will be vanished.\par
The reliability of the GT approach depends on the groups or pools of the malicious traffic considered as the input for the GT approach. The number of tests performed on the traffic improves the detection efficiency and covers wide range of possible attacks of DDoS attacks on ITM.\par
Scalability : If the detection approach is centralized then no need to use additional honeypots to the network except the honeypot placed at the data center when ever new ITM entered into the private region. In the distributed detection approach new honeypot is attached whenever the new ITM entered into the network.\par
When the network increases or new ITMs entered into the private region of the network, it does not create additional load on the existing data center. The GT approach handles the input traffic without depends on the number of ITMs or the data centers in the network.\par
Load Sharing : Every honeypot has its own capacity of handling the load or traffic in the network. In the centralized detection approach if the traffic exceeds its capacity, then the total detection system is vanished. The same problem occurs in case of distributed detection approach also.\par
If the load in the network increases then the GT approach forms more number of input pools and the tests are applied on the pools repeatedly to perform the attack detection.\par
False positives and false negatives: In the honeypot based flooding detection false positives and false negatives are not explicitly considered. The detection process finds the root of the attack, by blocking the IRC server.\par
In GT approach the false positives and false negatives calculated explicitly by conducting specific tests on the input pools of the traffic. False positives and false negatives improve the detection process in terms of considering the attack traffic as genuine and viceversa. 
\section[{c) Attack detection using Group testing approach}]{c) Attack detection using Group testing approach}\par
In the detection model \hyperref[b16]{[17]}, each testing pool is mapped to a virtual server within a back-end server machine. Although the maximum number of virtual servers can be extremely huge, since each virtual server requires enough service resources to manage client requests, it is practical to have the virtual server quantity Each back-end server works as an independent testing domain, where all virtual servers within it serve as testing pools. In the following sections, we only discuss the operations within one backend server, and it is similar in any other servers. The detection consists of multiple testing rounds, and each round can be sketched in four stages.\par
First, generate and update matrix M for testing.\par
Second, "assign" clients to virtual servers based on M. The back-end server maps each client into one distinct column in M and distributes an encrypted token queue to it. Each token in the token queue corresponds to a 1-entry in the mapped column, i.e., client j receives a token with destination virtual server i iff M[i,j]= 1. Being piggybacked with one token, each request is forwarded to a virtual server by the virtual switch. In addition, requests are validated on arriving at the physical servers for faked tokens or identified malice ID. This procedure ensures that all the client requests are distributed exactly as how the matrix M regulates and prevents any attackers from accessing the virtual servers other than the ones assigned to them.\par
Third, all the servers are monitored for their service resource usage periodically, specifically, the arriving request aggregate (the total number of incoming requests) and average response time of each virtual server are recorded and compared with some dynamic thresholds to be shown later. All virtual servers are associated with positive or negative outcomes accordingly.\par
Fourth, decode these outcomes and identify legitimate or malicious IDs. By following the detection algorithms all the attackers can be identified within several testing rounds. To lower the overhead and delay introduced by the mapping and piggybacking for each request, the system is exempted from this procedure in normal service state. As shown in Fig. \hyperref[fig_2]{3}, the back-end server cycles between two states, which we refer as NORMAL mode and DANGER mode. Once the estimated response time (ERT) of any virtual server exceeds some profile-based threshold, the whole backend server will transfer to the DANGER mode and execute the detection scheme. Whenever the average response time (ART) of each virtual server falls below the threshold, the physical server returns to NORMAL mode. Based on the system framework above, we propose three detection algorithms SDP, SDoP, and PND in this section. Note that the length of each testing round is a predefined constant P; hence, we analyze the algorithm complexity in terms of the number of testing rounds for simplicity. 
\section[{i. Sequential Detection with Packing}]{i. Sequential Detection with Packing}\par
This algorithm investigates the benefit of classic sequential group testing, i.e., optimizing the grouping of the subsequent tests by analyzing existing outcomes. Similar to traditional sequential testing, each client (column) only appears in one testing pool (server) at a time. However, to make full use of the available K servers, we have all servers conduct test in parallel.\par
ii. Sequential Detection without Packing Considering the potential overload problem arises from the "packing" scheme adopted in SDP, we propose another ralgorithm where legitimate clients do not shift to other servers after they are identified. This emerges from the observation that legitimate clients cannot affect the test outcomes since they are negative.\par
The basic idea of the SDoP algorithm can be sketched below. Given a suspect IDs set S with initial size n, evenly assign them to the K server machines, similar to SDP in the first round. For the following rounds, assign suspect IDs to the K servers instead of |A| available ones. For the identified legitimate IDs, never move them until their servers are to be overloaded. In this case, reassign all legitimate IDs over the K machines to balance the load. For server with positive outcome, the IDs active on this server but not included by the set of identified legitimate ones, i.e., suspect IDs, will still be identified as suspect. However, if there is only one suspect IDs of this kind in a positive server, this ID is certainly an attacker.\par
iii. Partial Non adaptive Detection Considering the fact that in the two sequential algorithms mentioned, we cannot identify any attackers until we isolate each of them to a virtual server with negative outcome, which may bring up the detection latency. In this scenario, the requests from the same client will be received and responded by different servers in a round-robin manner. Different from SDP and SDoP, a d-disjunct matrix is used as the testing matrix in this scheme and attackers can be identified without the need of isolating them into servers.\par
The attack traffic can be identified by using any of the three methods defined and QoS of the system is completely depends on the number of tests performed, number of rounds conducted on the pools .Once the attack traffic is identified ,then it is easy to find the attack source using the traffic entities. In our paper we focused on the flooding based attacks and these are generated using the botnet. The attacker floods the target ITM by sending the commands through C \& C server. Here the attack traffic contains the C \& C server address, and then it is very easy to block or point out that server to avoid the flooding attacks on the system.\par
While identifying the attack traffic with GT approach one can remember that the data should not be lost; these can be effectively done with false positives and negatives.\par
Despite the number of needed testing rounds differs for these three algorithms above, the time complexity of calculating each testing round for these algorithms is approximate in practice. It is trivial to see that the costs for SDP and SDoP are negligible, but not for PND algorithm which involves polynomial computation on Galois Field. However, considering that the upper bound of both the number of clients n and attackers d is estimated, the detection system can pre compute the d-disjunct matrices for all possible (n, d) pairs offline, and fetch the results in real time. Therefore, the overhead can be decreased to O(1) and the client requests can be smoothly distributed at the turn of testing rounds without suffering from long delays of matrix update. 
\section[{VII. CONCLUSION AND FUTURE WORK}]{VII. CONCLUSION AND FUTURE WORK}\par
The frame work integrates active real time flooding attack flow identification from botnet with GT approach. The GT approach has been used at Data center to detect the attack traffic that interns helpful, while identifying the C\&C server to block the flooding attack against the ITM. The false positive and false negatives can be effectively minimized to improve the QoS factors of the system. Some of the avenues for further extensions are with larger and heterogeneous networks. Back tracking can be applied on attack flows to reach the attack source. Both of them hold promise for evaluating and improving our DDoS detection and defense method and data center information protection. The data center load can be still minimized by used some distributed load sharing algorithms.\begin{figure}[htbp]
\noindent\textbf{12}\includegraphics[]{image-2.png}
\caption{\label{fig_0}Figure 1 :Figure 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-3.png}
\caption{\label{fig_1}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3}\includegraphics[]{image-4.png}
\caption{\label{fig_2}Fig. 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-5.png}
\caption{\label{figure5}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{}
\end{longtable} \par
 
\caption{\label{tab_0}?}\end{figure}
 			\footnote{Modeling and Counter Measures of Flooding Attacks to Internet Threat Monitors (ITM): Using Botnet and Group-Testing approach © 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXI Version I 16 2011 December} 			\footnote{Modeling and Counter Measures of Flooding Attacks to Internet Threat Monitors (ITM): Using Botnet and Group-Testing approach © 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXI Version I 17 2011 December} 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXI Version I 18 2011 December} 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXI Version I 19 2011 December} 			\footnote{Modeling and Counter Measures of Flooding Attacks to Internet Threat Monitors (ITM): Using Botnet and Group-Testing approach © 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXI Version I 20 2011 December} 			\footnote{Modeling and Counter Measures of Flooding Attacks to Internet Threat Monitors (ITM): Using Botnet and Group-Testing approach © 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXI Version I 21 2011 December} 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXI Version I 23 2011 December} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Sans and Center ()]{b2}\label{b2} 	 		\textit{},  		 			Internet Storm Sans 		,  		 			Center 		.  		 \url{http://isc.sans.org/}  		2010.  	 
\bibitem[Mirkovic and Reiher (2004)]{b1}\label{b1} 	 		‘A Taxonomy of DDOS Attack and DDOS Defense Mechanisms’.  		 			J Mirkovic 		,  		 			P Reiher 		.  	 	 		\textit{ACM SIGCOMM Computer Comm.Rev}  		Apr. 2004. 34  (2)  p. .  	 
\bibitem[Racine (2004)]{b14}\label{b14} 	 		\textit{Analysis of Internet Relay Chat Usage by DDoS Zombies},  		 			St´ephane Racine 		.  		April 2004.  		 			Swiss Federal Institute of Technology Zurich 		 	 	 (Master's thesis) 
\bibitem[Freiling et al. (2005)]{b11}\label{b11} 	 		‘Botnet Tracking: Exploring a Root-Cause Methodology to Prevent Distributed Denial-of-Service Attacks’.  		 			F C Freiling 		,  		 			T Holz 		,  		 			G Wicherski 		.  	 	 		\textit{Proc. 10th European Symp. Research in Computer Security (ESORICS)},  				 (10th European Symp. Research in Computer Security (ESORICS))  		Sept. 2005.  	 
\bibitem[Yegneswaran et al. (2004)]{b4}\label{b4} 	 		‘Global Intrusion Detection in the Domino Overlay System’.  		 			P Yegneswaran 		,  		 			S Barford 		,  		 			Jha 		.  	 	 		\textit{Proc. 11th IEEE Network and Distributed System Security Symp. (NDSS)},  				 (11th IEEE Network and Distributed System Security Symp. (NDSS))  		Feb. 2004.  	 
\bibitem[Wang et al. (2008)]{b8}\label{b8} 	 		‘Iloc: An Invisible Localization Attack to Internet Threat Monitoring Systems’.  		 			X Wang 		,  		 			W Yu 		,  		 			X Fu 		,  		 			D Xuan 		,  		 			W Zhao 		.  	 	 		\textit{Proc.IEEE INFOCOM},  				 (.IEEE INFOCOM)  		Apr. 2008.  	 
\bibitem[Moore et al. (2001)]{b3}\label{b3} 	 		‘Inferring Internet Deny-of-Service Activity’.  		 			D Moore 		,  		 			G M Voelker 		,  		 			S Savage 		.  	 	 		\textit{Proc. 10th USNIX Security Symp. (SEC)},  				 (10th USNIX Security Symp. (SEC))  		Aug. 2001.  	 
\bibitem[Cabuk et al. (2004)]{b9}\label{b9} 	 		‘Ip Covert Timing Channels:Design and Detection’.  		 			S Cabuk 		,  		 			C Brodley 		,  		 			C Shields 		.  	 	 		\textit{Proc. 2004 ACM Conf. Computer and Comm.Security (CCS)},  				 (2004 ACM Conf. Computer and Comm.Security (CCS))  		Oct. 2004.  	 
\bibitem[Bethencourt et al. (2005)]{b6}\label{b6} 	 		‘Mapping Internet Sensors with Probe Response Attacks’.  		 			J Bethencourt 		,  		 			J Frankin 		,  		 			M Vernon 		.  	 	 		\textit{Proc. 14th USNIX Security Symp. (SEC)},  				 (14th USNIX Security Symp. (SEC))  		July/Aug. 2005.  	 
\bibitem[Oikarinen and Reed ()]{b13}\label{b13} 	 		 			J Oikarinen 		,  		 			D Reed 		.  		\textit{RFC 1459: Internet Relay Chat Protocol},  				1993.  	 
\bibitem[The Honeynet Project. Know your enemy: rackingbotnets (2005)]{b15}\label{b15} 	 		 \url{http://www.honeynet.org/papers/bots/}  		\textit{The Honeynet Project. Know your enemy: rackingbotnets},  				March 2005.  	 
\bibitem[Bailey et al. (2005)]{b5}\label{b5} 	 		‘The Internet Motion Sensor: A Distributed Blackhole Monitoring System’.  		 			M Bailey 		,  		 			E Cooke 		,  		 			F Jahanian 		,  		 			J Nazario 		,  		 			D Watson 		.  	 	 		\textit{Proc. 12th Ann. Network and Distributed System Security Symp. (NDSS)},  				 (12th Ann. Network and Distributed System Security Symp. (NDSS))  		Feb. 2005.  	 
\bibitem[The mstream distributed denial of service attack tool]{b12}\label{b12} 	 		\textit{The mstream distributed denial of service attack tool},  		 \url{http://staff.washington.edu/dittrich/misc/mstream.analysis.txt}  		 	 
\bibitem[Cooke et al. (2005)]{b10}\label{b10} 	 		‘The Zombie Roundup: Understanding, Detecting, and Disrupting Botnets’.  		 			E Cooke 		,  		 			F Jahanian 		,  		 			D Mcpherson 		.  	 	 		\textit{Proc. Steps to Reducing Unwanted Traffic on the Internet Workshop (SRUTI)},  				 (Steps to Reducing Unwanted Traffic on the Internet Workshop (SRUTI))  		July 2005.  	 
\bibitem[Shinoda et al. (2005)]{b7}\label{b7} 	 		‘Vulnerabilities of Passive Internet Threat Monitors’.  		 			Y Shinoda 		,  		 			K Ikai 		,  		 			M Itoh 		.  	 	 		\textit{Proc. 14th USNIX Security Symp. (SEC)},  				 (14th USNIX Security Symp. (SEC))  		July/Aug. 2005.  	 
\bibitem[Wei Yu and Zhao (2010)]{b0}\label{b0} 	 		 			Riccardo Wei Yu 		,  		 			Wei Zhao 		.  		\textit{localization attacks to internet threat monitors:Modeling and countermeasures"on ieee transactions on computers},  				december 2010. 59.  	 
\bibitem[Xuan et al.]{b16}\label{b16} 	 		 			Ying Xuan 		,  		 			My T Shin 		,  		 			Thai 		,  		 			Taieb Member 		,  		 			Znati 		.  		\textit{Member, Detecting Application Denialof-Service Attacks: A Group-Testing-Based},  				 	 
\end{bibitemlist}
 			 		 	 
\end{document}
