December 11, 2012 at 05:34

We defeat the broadcast flood in the corporate local area network

Symptoms


It happened in our organization, a terrible thing - the network worked, worked, and suddenly, it seems, for no particular reason, began to work unstable. It all looked very strange (for the first time I encountered a subject problem) - some computers on the network (a small number of them) stopped receiving IP addresses (they say in the logs that they did not receive a response from DHCP), and in the morning some are users, in the morning others are users they call, worry, but we can’t understand anything.


If this is a hardware failure, then it must, according to all the canons, be located in one place, or at least appear more massively (such as with a ring in Ethernet), and then some rare bursts (about 5 out of 300), but in general, everything works. A more detailed analysis of the geography of sick computers showed that they are located on switches 3 or more of the queue, from the gateway (Figure 1).

image
Figure 1. Geography of the problem.

Search and identification


They did not immediately abandon the hypothesis of a problem with hardware - downstream switches turned off, and seemed to receive more or less short-term improvement, but the problem did not disappear to the end.

Naturally, the version arose that this is a kind of virus on the PC - it prevents them from getting an IP address. It was rejected after the network printer did not receive the address. As it turned out in vain (more precisely, almost in vain).

At the same time, they tried to analyze traffic, but due to the inexperience of specialists, only DHCP traffic was analyzed.

So, the first few days did not bring a solution to the problem. I had to expand the field of vision of the sniffer. And at this moment, the cause of the problem was discovered - when analyzing all the broadcast traffic, it turned out that more than 80% of the requests were searched, a certain server - in the sense of the same.

How. later we learned from the Internet, this problem is called broadcast flood.
Eh ... if you knew about this before.

It turned out that a certain service called “PcounterPrint” was very hysterically trying to find its server, which, oddly enough, was not there. The service audits the print of employees of the corporation, and is known worldwide as FollowMe Printing. As it turned out later, the server of this service was successfully decommissioned, naturally without any notification, by higher corporate system administrators.
In fact, user PCs acted as bots for the DDOS attack of our network equipment.

It remains for small to strangle this service on users PC.

Bulk delete


For good, it was necessary to give this task to the system administrators described above, but it’s interesting to ourselves, and now, after 25 minutes of searching the Internet, a script was created in the power-shell:

Here is the script code
main
function main 
{
    $computers = Get-Content C:\Scripts\Computers.txt
    $service = "PcounterPrint"
    foreach ($computer in $computers) 
    {
        (Write-Host "computer - $computer") 
        if (ping-host $computer)
        {
            $srv = (gwmi win32_service -computername $computer -filter "name='$service'")
            if ($srv -ne $null)
            {
              $result = $srv.stopservice()
              $result = $srv.ChangeStartMode("Disabled")
              (Write-Host "Service is disabled")
            }
            else
            { (Write-Host "No service") }
         }
        else
        { (Write-Host "No host") } 
    }
} 
function ping-host 
{ 
    param($computer) 
    $status = Get-WmiObject -Class Win32_PingStatus -Filter 
    "Address='$computer'"
    if( $status.statuscode -eq 0) { return 1 } 
    else { return 0 } 
}



The $ computers variable receives a list of computers from a file, the script sequentially traverses all PCs from this list, and disables the ill-fated service on them.

Next, we check the broadcast traffic with a sniffer, if someone remains, we correct the list, and run the script again, and so do several iterations, until the malicious traffic is completely removed.

Naturally, after that the network worked stably.

conclusions


As they say in one well-known pre-transcendental joke: for this you need a candelabrum on the head ...

In general, I will not write administrative conclusions here, although they are mainly asking for it.

From a technical point of view, there are several measures for the prevention of this disaster:
1. Segment the network into several virtual networks
2. Reduce the network depth using the first paragraph
3. Install smarter switches

Although these events are of course debatable, are they necessary? you will have to spend time and money, especially since the staff is now familiar with this situation and subsequently, will be able to quickly defeat it, although who knows ...
Tags:

Also popular now: