ActiveDirSec.Org

The world's most trusted forum on Active Directory Security


Post Info TOPIC: Denial of Service Attack on Active Directory by flooding the Event Logs


Member

Status: Offline
Posts: 6
Date: May 31, 2011
Denial of Service Attack on Active Directory by flooding the Event Logs
 
 


Hi again, was wondering if anyone's had to deal with a denial-of-service (DoS) attack to their Active Directory, involving a deliberate programmed execution of events that would cause the event logs to completely fill up and starve the DC of disk space.

Yes, I know it could be mitigated by setting an upper-bound on the size taken up by the security and event logs, but I wanted to know if anyone has experienced it.

We're currently reviewing our auditing settings to try and manage the amount of data generated, even in such a planned programmatic attempt to do so.

If you have experienced such an issue, kindly little-R or feel free to share here.

Thanks.



__________________

I’m sorry, but having a DB9 on the drive and not driving it is a bit like having Keira Knightley in your bed and sleeping on the couch.



Newbie

Status: Offline
Posts: 3
Date: Jun 16, 2011
 
 

Hello Mate,

Yup, I've had to deal with a situation like this. We had a disgruntled insider who scripted an attribute modification on an entire OU of accounts that he somehow found that he had rights to be able to modify, and it so happened that we had enabled auditing for the modification of that attribute on user accounts.

Sure enough, by the morning, our disks were entirely depleted of disk space, and we had a situation where users could not log in (DoS). To make a long story short, it was a bad day and we made sure that this would never happen again.

We learnt that there are four ways in which you can prevent something like this from happening -

1. Make sure you have large disks and that you always have a reserve file in place which can be deleted to free up space should it come to this point.

2. Have some sort of alerting mechanism in place, so you can be informed if a large number of events are being generated in a short amount of time.

3. Make sure you've reviewed your auditing settings and that you've only configured auditing for the occurrence of a small set of administrative tasks

AND, most importantly, although not as apparent,...

4. Make sure you know exactly who can perform these tasks to begin with!

Believe it or not, #4 has been SO valuable, because, say for example, if you already know that only 10 people in the company can reset passwords, you can sleep SO much better, than if you have no idea and you're hoping that only a small number of people in your 1,000 user company can reset passwords!

We've actually implemented all these measures in place, and we all sleep so much better.

>- Matt



-- Edited by Matthew on Thursday 16th of June 2011 01:11:52 AM

__________________

Go Aussie!

Page 1 of 1  sorted by
Quick Reply

Please log in to post quick replies.

Post to Facebook Post to Digg Post to Del.icio.us
Members Login
Username 
 
Password 
    Remember Me