Checking a Dos/Ddos attack (Denial of service) on a network dump (PCAP file)

Asked

Viewed 356 times

2

from scapy.all import *
import dpkt

f1 = open("semAtaque.pcap")
pcap = dpkt.pcap.Reader(f1)
f1.close()

f2 = open("Ataques.pcap")
pcap = dpkt.pcap.Reader(f2)
f2.close()

I have two network traffic captures referring to an experiment in the laboratory: one free of attacks (semAtaque.pcap) and another with Ddos attacks (Attacks.pcap).

To verify if the experiment was valid, I need to initially verify if the server denied the service, when this happened and how the server buffer was throughout the attack (Attacks.pcap).

The IP of the server that suffered the attack : 192.168.1.5

How to check the state of buffer from the server before and after the attack? How to check if the server denied the service and when it occurred ?

Remark: the buffer is only related to connection (Flood) flooding the server and paralyzing the services (DDOS) and not the attacks of buffer overflow!

The server (laboratory test) actually crashed with the simulated attack. What I would like is to be able to display the connection buffer before and after the attack. It would be possible with Python?

  • What do you mean by buffer? Are you talking about remote attacks using buffer overflow? or just connection (Flood) flooding the server and paralyzing the services (DDOS) ?

  • sorry: buffer for connection -> flooding!

2 answers

4


I believe you’re talking about attacks DDOS.

When a DDOS happens the server discards connections for lack of resources, the service cannot handle so many simultaneous connections, usually when analyzing a Sniffer file, when a DDOS happens, you will notice a large volume of connections in a short period, if an attack is distributed you will notice different IP’s connecting in the same second, for each connection there must be at least one response, ie this demonstrates a conversation, communication between the source IP and your server, so a DDOS attack will be successful when the amount of requests sent exceeds the responsiveness of a service/server and this can be observed in Sniffer by looking at whether the amount of requests matches the amount of responses that your server sent, that is if your server received 500 requests in a 10-second interval it was able to respond to those 500 requests? you have to note if you have been to and from Sniffer, if there has been no response or if your server has responded a much smaller amount of request than it should be this is a great indication that your service is overloaded or down.

One rudimentary way to find the maximum connection your server has endured is to check and count on Sniffer the amount of incoming connections before your server stops responding or responds less than it should ...

Open a loop and start counting from the line that starts Flood, increment each pair of connections in the . pcap (connection received/connection answered), when you realize you are only receiving connections and no longer have the response from your server (your server stopped responding) stop the loop and you will have found the critical point, this will give you a number of connections that your service has endured before falling/overloading.

Still on that question:

How to check the status of the server buffer before and after attack?

There is no way to know the state of the server buffer before the attack using Sniffer with accuracy, you can only estimate by analyzing the Sniffer (how many connections with your server’s response occurred within a certain range), each service (ftp, www, dns, email)an engineer, network admin, etc., will study the architecture the processing power of the server and the network where these services run and configure within each service the maximum possible capacity of simultaneous connections that they must withstand.

How outside the laboratories is this done? (real life man) I’ll send you a real example of where I work, it’s totally unfeasible you keep a Sniffer running on the network capturing everything, this is surreal, as you may have realized this will generate files with an absurd order of grandeur, Identifying attacks like this in real time is impracticable, so for every server running a service I pick up by sampling the amount of simultaneous connections that the service has at each time interval:

netstat --tcp -n | grep -v "LISTEN" | awk '{print $4}' | grep ":443" | grep  "$ServerIP" | wc -l

This command runs automatically from time to time (every 5 min for example) on the server that runs an https(port 443), it returns how many connections it has at the time of execution, with this it is possible to know if the service is close to the limit of simultaneous connections configured and generate real-time alerts by activating the network engineers and admin’s, to each captured sample of this command I also go assembling a graph that will contain all the history of amount of connections, then just I choose the period I wish to see the connections of the port https:

inserir a descrição da imagem aqui

This is done for all network services, I just showed this to exemplify!

A Sniffer was made for point use and not to keep capturing 24x7 network traffic, when an alert from this system triggers ai yes everyone starts sniffling the network looking for which or which IP’s are generating unusual traffic.

Remember it’s relatively simple to analyze, identify, and block attacks when they come from the same IP, but all your work (entropy calculation, calculating how many connections the service has endured before you stop responding, etc.) falls apart if it’s a distributed attack (from different backgrounds).

  • The server (laboratory test) actually crashed with the simulated attack. What I would like is to be able to display the connection buffer before and after the attack. It would be possible with Python?

  • the word buffer is wrong, in fact it varies with the capacity of each server and each service, you can have a quantum server that will do no good if for example a web service (apache) is not configured to receive X simultaneous connections ...

  • I think you’re confusing the word buffer with something else, a DDOS attack is not like a variable in the tcp/udp package that fills up, every tcp package coming on the network will have the same size every time, the problem is that it is sending so many at the same time that your service or server starts responding precariously ...

  • I should have said then: "display the number of connections the server was configured to receive" and the "number of connections requested from the server during the attack", right?

  • that ai, ie there is a command that will give you this answer, each configured service will work to receive the maximum connections configured for the service, an email(Postifix), a web(apache), an ftp(proftp), a dns(bind)etc, each service of these is fully configurable how much you want it to handle from simultaneous connections ie if you have a parrudo server you can put higher values to support more connections, if you have a server barbie vc can put to have less connections ...

  • a rudimentary way to find the maximum connection your server has endured is to check and count in Sniffer the amount of incoming connections before your server stops responding, or respond less than it should ....

  • interesting idea, how to make this count with Python?

  • One goes and walk line by line on the . pcap, count as long as you have been to and from the ips in question (increment at every outward and outward pair), when you begin to realize that it has only come from connection and no longer has the back (ie your server stopped responding) stop the for and you found the critical point and will have a connection number that your service has endured before falling/overloading

  • you are helping me so much. Thank you!

  • if you can, take a look at the code below!

Show 5 more comments

0

from scapy.all import *
from collections import deque

def print_attack_measure(pcap_file):
    plist = rdpcap(pcap_file)
    server_ip = "192.168.1.5"
    n = 300
    d = deque(maxlen=n)

    # If you want source/destination IP addresses
    getsrcdst = lambda x:(x.src,x.dst)
    # If you want MAC addresses
    getmacs   = lambda x:(x.addr1, x.addr2, x.addr3)

    def filterpackets(ip):
        for p in plist:
            try:
                c = getsrcdst(p)
                if(ip in c[0]):
                    # server IP is source IP of packet
                    yield -1
                if(ip in c[1]):
                    # server IP is destination IP of packet
                    yield 1
            except AttributeError:
                pass

print("This prints a measure of packets received to packets sent, using a moving average of %d packets."%(n))
print("0 indicates a perfect balance of sent-received.")
print("+1 indicates all packets are sent to the server.")
print("-1 indicates all packets are sent by the server.")
print("A larger positive number indicates an unresponsive server.")

count = 0
for pack in filterpackets(server_ip):
    d.append(pack)
    count += 1
    if(count>n):
        print("%0.4f"%(sum(d)/(1.0*n)))


print_attack_measure("1.pcap") # sem ataques
print_attack_measure("2.pcap") # com ataques

This code is an attempt to implement the suggestion of @ederwander Unfortunately it still doesn’t work. Any suggestions?

Lambda function extracts the source and destination Ips from the package.

package sent to server : +1 package sent by server : -1

O código está em http://pastebin.com/DFEnZzqn

Erro: http://imgur.com/a/KC87V

Browser other questions tagged

You are not signed in. Login or sign up in order to post.