1.

INTRODUCTION
An active worm refers to a malicious software program that propagates itself on the Internet to infect other computers. The propagation of the worm is based on exploiting vulnerabilities of computers on the Internet. Many real-world worms have caused notable damage on the Internet. These worms include Code-Red worm in 2001, Slammer worm in 2003, and Witty/Sasser worms in 2004. Many active worms are used to infect a large number of computers and recruit them as bots or zombies, which are networked together to form botnets These botnets can be used to: (a) launch massive Distributed Denial-of-Service (DDoS) attacks that disrupt the Internet utilities , (b) access confidential information that can be misused , through large scale traffic sniffing, key logging, identity theft etc., (c) destroy data that has a high monetary value , and (d) distribute large-scale unsolicited advertisement emails (as spam) or software (as malware).There is evidence showing that infected computers are being rented out as Botnets for creating an entire black-market industry for renting, trading, and managing owned computers, leading to economic incentives for attackers . Researchers also showed possibility of super-botnets, networks of independent botnets that can be coordinated for attacks of unprecedented scale .For an adversary; super botnets would also be extremely versatile and resistant to counter measures. Due to the substantial damage caused by worms in the past years, there have been significant efforts on developing detection and defense mechanisms against worms. A network based worm detection system plays a major role by monitoring, collecting, and analyzing the scan traffic (messages to identify vulnerable computers) generated during worm attacks. In this system, the detection is commonly based on the self-propagating behavior of worms that can be described as follows: after a worm-infected computer identifies and infects a vulnerable computer on the Internet, this newly infected computer1 will automatically and continuously scan several IP addresses to identify and infect other vulnerable computers. As such, numerous existing detection schemes are based on a tacit assumption that each worm-infected computer keeps scanning the Internet and propagates itself at the highest possible speed. Furthermore, it has been shown that the worm scan traffic volume and the number of worm-infected computers exhibit exponentially increasing patterns.

2. SYSTEM ANALYSIS

2.1 EXISTING SYSTEM

The C-Worm is quite different from traditional worms in which it camouflages any noticeable trends in the number of infected computers over time. The camouflage is achieved by manipulating the scan traffic volume of worm-infected computers. Such a manipulation of the scan traffic volume prevents exhibition of any exponentially increasing trends or even crossing of thresholds that are tracked by existing detection schemes. DRAWBACK IN EXISTING SYSTEM C-Worm scan traffic shows no noticeable trends in the time domain, it demonstrates a distinct pattern in the frequency domain. Specifically, there is an obvious concentration within a narrow range of frequencies. This concentration within a narrow range of frequencies is inevitable since the C-Worm adapts to the dynamics of the Internet in a recurring manner for manipulating and controlling its overall scan traffic volume.

2.2 PROPOSED SYSTEM:

We adopt frequency domain analysis techniques and develop a detection scheme against Wide-spreading of the C-Worm. Particularly, we develop a novel spectrum-based detection scheme that uses the Power Spectral Density (PSD) distribution of scan traffic volume in the frequency domain and its corresponding Spectral Flatness Measure (SFM) to distinguish the C-Worm traffic from non-worm traffic (background traffic).

ADVANTAGES IN PROPOSED SYSTEM Our evaluation data clearly demonstrate that our spectrum-based detection scheme achieves much better detection performance against the C-Worm propagation compared with existing detection schemes. Our evaluation also shows that our spectrum-based detection scheme is general enough to be used for effective detection of traditional worms as well.

2.3 FEASIBILITY REPORT

The feasibility of the project is analyzed in this phase and business proposal is put forth with a very general plan for the project and some cost estimates. During system analysis the feasibility study of the proposed system is to be carried out. This is to ensure that the proposed system is not a burden to the company. For feasibility analysis, some

understanding of the major requirements for the system is essential. Three key considerations involved in the feasibility analysis are ECONOMICAL FEASIBILITY TECHNICAL FEASIBILITY SOCIAL FEASIBILITY

ECONOMICAL FEASIBILITY
This study is carried out to check the economic impact that the system will have on the organization. The amount of fund that the company can pour into the research and development of the system is limited. The expenditures must be justified. Thus the developed system as well within the budget and this was achieved because most of the technologies used are freely available. Only the customized products had to be purchased.

TECHNICAL FEASIBILITY
This study is carried out to check the technical feasibility, that is, the technical requirements of the system. Any system developed must not have a high demand on the available technical resources. This will lead to high demands on the available technical resources. This will lead to high demands being placed on the client. The developed system must have a modest requirement, as only minimal or null changes are required for implementing this system.

SOCIAL FEASIBILITY
The aspect of study is to check the level of acceptance of the system by the user. This includes the process of training the user to use the system efficiently. The user must not feel threatened by the system, instead must accept it as a necessity. The level of acceptance by the users solely depends on the methods that are employed to educate the user about the system and to make him familiar with it. His level of confidence must be raised so that he is also able to make some constructive criticism, which is welcomed, as he is the final user of the system.

2.4 SYSTEM SPECIFICATIONS

HARDWARE:
PROCESSOR RAM HARD DISK : : : PENTIUM IV 2.6 GHz, Intel Core 2 Duo. 512 MB 40 GB

SOFTWARE
Front End Back End Operating System IDE : : : : JAVA (SWINGS) MS SQL 2000/05 Windows XP/07 Net Beans, Eclipse

3. SYSTEM DESIGN

3.1 SYSTEM ARCHITECTURE

Centralized data center

Monitor 1

Monitor 2

Monitor 3

User 1

User 2

User 4

User 5

User 3

Fig:1

SYSTEM ARCHITECTURE

3.2UML DIAGRAMS
The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing objects oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. 3.2.1. Use Case Diagrams A use case is a set of scenarios that describing an interaction between a user and a system. A use case diagram displays the relationship among actors and use cases. The two main components of a use case diagram are use cases and actors. Use case diagrams are behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system.

UserLogin

Monitoring

Monitor

Centralized data center

DataCollection

Detection User

Distribution

fig : Use Case Diagram

3.2.2. CLASS DIAGRAM The class diagram is the main building block of object oriented modeling. It is used both for general conceptual of the systematics of the application, and for detailed modeling translating the models into programming code. Class diagrams can also be used for data modeling. The classes in a class diagram represent both the main objects and or interactions in the application and the objects to be programmed. In the class diagram these classes are represented with boxes which contain three parts:

The upper part holds the name of the class The middle part contains the attributes of the class The bottom part gives the methods or operations the class can take or undertake

In the system design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the static relations between those objects. With detailed modeling, the classes of the conceptual design are often split into a number of subclasses.

Fig : CLASS DIAGRAM

3.2.3 SEQUENCE DIAGRAM

Sequence diagram is the most common kind of interaction diagram, which focuses on the message interchange between a numbers of lifelines. Sequence diagram describes an interaction by focusing on the sequence of messages that are exchanged, along with their corresponding occurrence specifications on the lifelines. The following nodes and edges are typically drawn in a UML sequence diagram: lifeline, execution specification, message, combined fragment, interaction use, state invariant, continuation, destruction occurrence.

DataCenter

Monitor

LogCollection

LogDistribution

Client

Login

Monitoring

TrafficLog

DetectWorm

PrepareReport

Distribution

Fig : SEQUENCE DIAGRAM

3.2.4 COLLABORATION DIAGRAM
Communication diagram (called collaboration diagram in UML 1.x) is interaction diagram which shows interactions between objects and/or parts (represented as lifelines) using sequenced messages in a free-form arrangement.

Communication diagram corresponds (could be converted to/from or replaced by) to simple sequence diagram without structuring mechanisms such as Interaction Uses and Combined Fragments. It is also assumed that message overtaking (i.e., the order of the receptions are different from the order of sending of a given set of messages) will not take place or is irrelevant. Communication Diagrams could be shown within a rectangular frame with the name in a compartment in the upper left corner. There is no specific long form name for communication diagrams heading types. The long form name interaction (used for interaction diagrams in general) could be used.

Monitor

4: DetectWorm DataCen ter 3: TrafficLog 2: Monitoring LogColle ction

5: PrepareReport 1: Login 6: Distribution LogDistri bution Client

Fig : COLLABORATION DIAGRAM

3.2.5 ACTIVITY DIAGRAM
Activity diagram is an important diagram in UML to describe dynamic aspects of the system. Activity diagram is basically a flow chart to represent the flow form one activity to another activity. The activity can be described as an operation of the system. So the control flow is drawn from one operation to another. This flow can be sequential, branched or

concurrent. Activity diagrams deals with all type of flow control by using different elements like fork, join etc. Horizontal bar is used to split and to join the concurrent activities. Activities performed by receiver are spitted using vertical bar.

Start

DataCenter

Monitor

User

End

Fig : ACTIVITY DIAGRAM

4. CONCEPTS AND TECHNIQUES 4.1 Power Spectral Density (PSD)

The goal of spectral density estimation is to estimate the spectral density of a random signal from a sequence of time samples. Depending on what is known about the signal, estimation techniques can involve parametric or non-parametric approaches, and may be based on time-domain or frequency-domain analysis. For example, a common parametric technique involves fitting the observations to an autoregressive model. A common nonparametric technique is the periodogram. The spectral density is usually estimated using Fourier transform methods, but other techniques such as Welch's method and the maximum entropy method can also be used.

4.2 Spectral Flatness Measure (SFM)

Spectral flatness or tonality coefficient, also known as Wiener entropy, is a measure used in digital signal

processing to characterize an audio spectrum. Spectral flatness is typically measured in decibels, and provides
a way to quantify how tone-like a sound is, as opposed to being noise-like. The meaning of tonal in this context is in the sense of the amount of peaks or resonant structure in a power spectrum, as opposed to flat spectrum of a white noise. A high spectral flatness indicates that the spectrum has a similar amount of power in all spectral bands this would sound similar to white noise, and the graph of the spectrum would appear relatively flat and smooth. A low spectral flatness indicates that the spectral power is concentrated in a relatively small number of bands this would typically sound like a mixture of sine waves, and the spectrum would appear "spiky". The spectral flatness is calculated by dividing the geometric mean of the power spectrum by the arithmetic

mean of the power spectrum, i.e.:

where x(n) represents the magnitude of bin number n. Note that a single (or more) empty bin yields a flatness of 0, so this measure is most useful when bins are generally not empty. The ratio produced by this calculation is often converted to a decibel scale for reporting.

5. IMPLEMENTATION Centralized Data Center

 Monitoring User Report Preparation Report Distribution

5.1 Module Description:

Centralized Data Center:

It will collect all the traffic logs from various network monitors for identifying the worms by their IP address. Here the server uses a server socket object with a specified port no and an accept method to accept the clients or monitors to establish a connection

Monitoring:
It will monitor the authorized clients for their transaction and it will identify the traffic log (IP address which are not commonly used and dark IP address).

User:
In this module user can login to the centralized server for authentication, once the client is treated as authorized then it can share data with the neighbors in the network. It does this operation using a socket programming , where a socket object is created and server ip address and port no is provided as a parameter to the socket object to establish a connection with the server(java.net package is used).

Report Preparation:
The purpose of this module is to identify the actual worm by its ratio not by scan traffic time in order to detect the active worm and the normal worm.

Report Distribution:
The centralized data center has to distribute the report logs (dark IP address) to all the users in the network. So the users can be prevented from accessing the worm and spreading of worm in their system.

5.2MODULE DIAGRAMS

User:

Client

Data Center Server

Fig :user
Monitoring:

Client 1 Monitor

Client n

Fig: Monitoring

Centralized Data Center:

Client 1 Monitor Client 1 1 Server

..

Fig: Centralized Data Center

Report Preparation:

Client Client Monitor 1 Server

Client Monitor Client n

Fig: Report Preparation

Report Distribution

Client 1 Monitor

Server

Client n Client 1 Monitor

Client n

Fig : Report Distribution

6. SAMPLE CODE
Server.java:
package centralizedserver;

import java.io.BufferedReader; import java.io.IOException;

import java.io.InputStream; import java.io.InputStreamReader; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.OutputStream; import java.net.InetAddress; import java.net.Socket; import java.net.ServerSocket; import java.util.ArrayList; import java.util.Enumeration; import java.util.Iterator; import java.util.Map; import java.util.Set; import java.util.TreeMap; import javax.swing.JOptionPane; import javax.swing.tree.DefaultMutableTreeNode; import javax.swing.tree.DefaultTreeModel; import javax.swing.tree.TreeSelectionModel;

public class CentralizedServer extends javax.swing.JFrame implements Runnable {

Thread t; String tempPort; int port; Socket s, checkSocket; ServerSocket ss;

Iterator i; DefaultMutableTreeNode addUser, d;

InputStream is; InputStreamReader isr; BufferedReader br; static ArrayList allUser = new ArrayList();

public CentralizedServer() { initComponents();

public void run() { while (true) { try { soc = server.accept();

String address=soc.getInetAddress().getHostAddress();

monitor=new DefaultMutableTreeNode(address); root.add(monitor); jTree1.setModel(new DefaultTreeModel(root));

ObjectInputStream ois = new ObjectInputStream(soc.getInputStream()); ArrayList al = (ArrayList) ois.readObject(); String key = (String) al.get(0);

if (key.equals("update")) { TreeMap tm = (TreeMap) al.get(1); map=tm; System.out.println(tm); update(tm);

} if(key.equals("report")){

String WIP=(String)al.get(1); Set set=map.entrySet();

Iterator it=set.iterator(); while(it.hasNext()){ Map.Entry me=(Map.Entry)it.next(); Integer I=(Integer)me.getKey(); String addr=(String)me.getValue();

try{ Socket socket=new Socket(addr,I.intValue()); ArrayList clientInfo=new ArrayList(); clientInfo.add("report"); clientInfo.add(WIP +"has send worm file... Please dont Access"); ObjectOutputStream oos=new ObjectOutputStream(socket.getOutputStream()); oos.writeObject(clientInfo);

} catch(IOException e){ e.printStackTrace(); }

} } catch (Exception e) { e.printStackTrace(); } }

@SuppressWarnings("unchecked") // <editor-fold defaultstate="collapsed" desc="Generated Code">//GENBEGIN:initComponents private void initComponents() {

jPanel1 = new javax.swing.JPanel(); jPanel2 = new javax.swing.JPanel(); jScrollPane1 = new javax.swing.JScrollPane(); jTree1 = new javax.swing.JTree(); jButton1 = new javax.swing.JButton(); jLabel1 = new javax.swing.JLabel();

setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE); setTitle("Server"); setBounds(new java.awt.Rectangle(50, 50, 200, 200));

jPanel1.setBackground(new java.awt.Color(255, 255, 204)); jPanel1.setBorder(javax.swing.BorderFactory.createMatteBorder(2, 2, 2, 2, new java.awt.Color(0, 204, 0))); jPanel1.setLayout(null);

javax.swing.tree.DefaultMutableTreeNode treeNode1 = new javax.swing.tree.DefaultMutableTreeNode("root"); jTree1.setModel(new javax.swing.tree.DefaultTreeModel(treeNode1)); jScrollPane1.setViewportView(jTree1);

javax.swing.GroupLayout jPanel2Layout = new javax.swing.GroupLayout(jPanel2); jPanel2.setLayout(jPanel2Layout); jPanel2Layout.setHorizontalGroup( jPanel2Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addComponent(jScrollPane1, javax.swing.GroupLayout.Alignment.TRAILING, javax.swing.GroupLayout.DEFAULT_SIZE, 320, Short.MAX_VALUE) ); jPanel2Layout.setVerticalGroup( jPanel2Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addComponent(jScrollPane1, javax.swing.GroupLayout.Alignment.TRAILING, javax.swing.GroupLayout.DEFAULT_SIZE, 390, Short.MAX_VALUE) );

jPanel1.add(jPanel2); jPanel2.setBounds(150, 60, 320, 390);

jButton1.setText("send report"); jButton1.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jButton1ActionPerformed(evt); } }); jPanel1.add(jButton1); jButton1.setBounds(590, 200, 110, 40);

jLabel1.setFont(new java.awt.Font("Baskerville Old Face", 1, 18));

jLabel1.setForeground(new java.awt.Color(255, 0, 51)); jLabel1.setText("SERVER"); jPanel1.add(jLabel1); jLabel1.setBounds(340, 10, 90, 30);

javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane()); getContentPane().setLayout(layout); layout.setHorizontalGroup( layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addComponent(jPanel1, javax.swing.GroupLayout.DEFAULT_SIZE, 850, Short.MAX_VALUE) ); layout.setVerticalGroup( layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addComponent(jPanel1, javax.swing.GroupLayout.DEFAULT_SIZE, 550, Short.MAX_VALUE) );

pack(); }// </editor-fold>//GEN-END:initComponents

private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {//GENFIRST:event_jButton1ActionPerformed TreeSelectionModel t = jTree1.getSelectionModel(); }//GEN-LAST:event_jButton1ActionPerformed public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() {

public void run() { CentralizedServer cs = new CentralizedServer(); cs.setSize(850, 550);

cs.setVisible(true); cs.getInput(); cs.connection();

} }); } // Variables declaration - do not modify//GEN-BEGIN:variables private javax.swing.JButton jButton1; private javax.swing.JLabel jLabel1; private javax.swing.JPanel jPanel1; private javax.swing.JPanel jPanel2; private javax.swing.JScrollPane jScrollPane1; public javax.swing.JTree jTree1; // End of variables declaration//GEN-END:variables ServerSocket server; Socket soc; int serverPort; Thread thread; DefaultMutableTreeNode root; DefaultMutableTreeNode monitor; TreeMap map;

public void connection() {

try { server = new ServerSocket(serverPort);

System.out.println("Server is running");

InetAddress IA=InetAddress.getLocalHost(); root = new DefaultMutableTreeNode(IA.getHostAddress()+ "@" + serverPort); jTree1.setModel(new DefaultTreeModel(root)); thread = new Thread(this); thread.start();

} catch (IOException e) { e.printStackTrace();

} }

public void getInput() {

String s = JOptionPane.showInputDialog(rootPane, "Enter Server Port").trim(); serverPort = Integer.parseInt(s);

public void update(TreeMap tm) {

Set set=tm.entrySet();

Iterator it=set.iterator(); while(it.hasNext()){ Map.Entry me=(Map.Entry)it.next(); Integer I=(Integer)me.getKey(); String addr=(String)me.getValue();

monitor.add(new DefaultMutableTreeNode(addr+"@"+I.intValue()));

try{ Socket socket=new Socket(addr,I.intValue()); ArrayList clientInfo=new ArrayList(); clientInfo.add("update"); clientInfo.add(tm); ObjectOutputStream oos=new ObjectOutputStream(socket.getOutputStream()); oos.writeObject(clientInfo); } catch(IOException e){ e.printStackTrace(); } } root.add(monitor) ; jTree1.setModel(new DefaultTreeModel(root)); System.out.println("Updated"); } }

7. SYSTEM TESTING Unit testing

Unit testing involves the design of test cases that validate that the internal program logic is functioning properly, and that program inputs produce valid outputs. All decision branches and internal code flow should be validated. It is the testing of individual software units of the application .it is done after the completion of an individual unit before integration. This is a structural testing, that relies on knowledge of its construction and is invasive. Unit tests perform basic tests at component level and test a specific business process, application, and/or system configuration. Unit tests ensure that each unique path of a

business process performs accurately to the documented specifications and contains clearly defined inputs and expected results.

Functional test
Functional tests provide systematic demonstrations that functions tested are available as specified by the business and technical requirements, system documentation, and user manuals. Functional testing is centered on the following items: Valid Input Invalid Input Functions Output : identified classes of valid input must be accepted. : identified classes of invalid input must be rejected. : identified functions must be exercised. : identified classes of application outputs must be exercised.

Systems/Procedures: interfacing systems or procedures must be invoked. Organization and preparation of functional tests is focused on requirements, key functions, or special test cases. In addition, systematic coverage pertaining to identify Business process flows; data fields, predefined processes, and successive processes must be considered for testing. Before functional testing is complete, additional tests are identified and the effective value of current tests is determined.

System Test
System testing ensures that the entire is the configuration oriented system integration test. System testing is based on process descriptions and flows, emphasizing pre-driven process links and integration points. .

Test strategy and approach

Field testing will be performed manually and functional tests will be written in detail.

Test objectives

All field entries must work properly. Pages must be activated from the identified link. The entry screen, messages and responses must not be delayed.

Features to be tested
Verify that the entries are of the correct format No duplicate entries should be allowed All links should take the user to the correct page.

Acceptance Testing
User Acceptance Testing is a critical phase of any project and requires significant participation by the end user. It also ensures that the system meets the functional requirements.

7.2 White Box Testing

White Box Testing integrated software system meets requirements. It tests a configuration to ensure known and predictable results. An example of system testing is a testing in which in which the software tester has knowledge of the inner workings, structure and language of the software, or at least its purpose. It is purpose. It is used to test areas that cannot be reached from a black box level.

7.3 Black Box Testing

Black Box Testing is testing the software without any knowledge of the inner workings, structure or language of the module being tested. Black box tests, as most other kinds of tests, must be written from a definitive source document, such as specification or requirements document, such as specification or requirements document. It is a testing in which the software under test is treated, as a black box .you cannot see into it. The test provides inputs and responds to outputs without considering how the software works.

Test Results: All the test cases mentioned above passed successfully. No defects
encountered.

8.RESULT SCREENS

8.1.Server: Login

Send a report:

View Report:

8.2.Monitor:

List Of Users:

8.3 Server: Request to Server:

8.4.User:

Users List:

Sending A Report:

List of Users Connected:

List of Actions Performed

8.4. C-WORM:

Warning Message:

9. CONCLUSION:

In this paper we presented an analytical framework, based on Interactive Markov Chains, that can be used to study the dynamics of malware propagation on a network. The exact solution of a stochastic model intended to capture the probabilistic nature of malware propagation on an arbitrary topology appears to be a major challenge, because of the high computational complexity necessary to analyze very large systems. However, one can resort to simple bounds and approximations in order to obtain a gross-level prediction of the system behavior that can help to understand important characteristics of malware propagation. Although we have focused on the modeling aspects of the problem, we believe our methodology can be usefully applied to evaluate different countermeasures against future malware activity, as well as fundamental issues on network vulnerability assessment. Moreover, the flexibility of the approach based on IMCs allows to apply our work beyond the problem of malware spreading, addressing a wide variety of dynamic interactions on networks. Our modeling effort is to be considered a first step in a rather novel research area that we expect to gain more and more relevance in the next future.

10. BIBLIOGRAPHY: REFERENCES:

[1] D. Moore, C. Shannon, and J. Brown, Code-red: a case study on the spread and victims of an internet worm, in Proceedings of the 2-th Internet Measurement Workshop (IMW), Marseille, France, November 2002. [2] D. Moore, V. Paxson, and S. Savage, Inside the slammer worm, in IEEE Magazine of Security and Privacy, July 2003. [3] CERT, CERT/CC advisories, http://www.cert.org/advisories/. [4] P. R. Roberts, Zotob Arrest Breaks Credit Card Fraud Ring, http://www.eweek.com/article2/0,1895,1854162,00.asp. [5] W32/MyDoom.B Virus, http://www.us-cert.gov/cas/techalerts/ TA04-028A.html. [6] W32.Sircam.Worm@mm, http://www.symantec.com/avcenter/venc/data/w32.sircam.worm@mm.html.