Just posting this here for my own benefit. Off and on since about 12/12/06 I have been seeing SYN floods (nothing huge, just a trickle) coming into my web servers on port 80 tcp and apparently coming from systems at softkit.ro and evolvatelecom.net (both European). I’ve not thought much of them as they are not huge and I’ve had other things I’ve been busy on, but this afternoon I did a check. I found this on the mynightwatchman.com site:

We are aware of this problem, but it is not originating from our network. As of last month we are the target of a DRDOS attack coming from the internet. From what we’ve gathered the attacker is sending source-IP spoofed SYN packets to a very large number of web servers (including yours – directed at port 80 only), the result being those servers flooding us with SYN+ACK packets afterwards.
We’d love any help from you on this matter, given that you have extensive logs on your affected servers.
Something of interest would be that we are not receiving any RST packets so this lead us to believe the attacker is probing the ports on the machines he’s using subsequently and not sending the packets blindly at random IPs.
As you can imagine, this is very disturbing for us too, but we have found absolutely no way and no support in catching this attacker. We would appreciate any support…

That pretty much sucks.

I can’t believe what I’m reading as I catch up on news from the long weekend. There’s a lot of things suddenly being found that I need to look at and/or evaluate. I would have better links, but I can’t browse some sites without being flagged while at work.

VLC Media Player has a bug in even the Windows version. So much for trying to hide from Windows Media Player.

WinZip (not that I necessarily use it, I think I still just use an old cracked version 8 or 9 copy and have been looking at open source alternatives lately) has a bug in it that now has exploit code released.

XSS Vulnerability leads to G-Mail contact list disclosure. Guess it is time to add to the list of things people should do to stay safe: always log out of web sites when you are done using them for your session. This is becoming more and more necessary.

Daylight Savings Time is changing (whoa, boy, a silent and likely more potent “y2k” issue?).

Symantec still has lots of vulnerable installations out there, and they are growing, which is a bit disconcerting.

Update: I forgot about Adobe!

Tracking user access in a corporate network is one of those, “Don’t say that very loudly!” topics. No one likes to think about it because everyone knows they suck at it and trying to get it under control is a frustrating exercise. But what if you absolutely have to do this?

If you’re like most small- and medium-sized companies, you use some sort of Windows-based file server and manual permissions management with Active Directory user accounts. Nothing could be messier when not managed properly. I’ve recently had the pleasure (?) of tackling such a project in my company. If you’ve ever utilized cacls/acls tools to dump permissions lists in folder shares, you know they can fill up all the rows in a .csv file and more, even for a medium-sized file server.

Here is my approach in four major steps: 1) take inventory, 2) file permission organization, 3) account organization, and 4) data ownership. The goal of this project is to be able to answer the following questions: Who can access data X? What does person Y all have access to? What is the process for requesting access to data Z?

1. Take inventory
The first order of business is to measure the pain. Grab a trusty Windows permission enumation tool and dump the permissions on all your file server shares, including all subdirectories. I recommend limiting yourself to folders and not including files. Windows files are very annoying in their permissions and will inject a lot of weird data into your intial acl dumps. The best tool I’ve come across for reporting on permissions is ScriptLogic’s Enterprise Security Reporter. This is a commercial tool which does more reports than just permissions, but the ability to report permissions in configurable ways is invaluable. They have a 30-day trial on this product. You can create reports that pull out what a user has access to, as well as who all has access to a particular folder including pulling users from groups in AD. Check out your file servers and all the folders you expect to have different permissions and see how accurate things are or are not. Take a deep breath, and move on.

2. file permission organization
Next, you have to determine how you will be doing permissions in the future. Here are my recommendations:

– Do not use the DENY right! This rarely shows up in reporting tools and is just frustrating to use.
– Do not use complicated subdirectory permission changes. You want to use permission inheritance as much as possible. The reason for this is accidental changes to permissions that are pushed down to all subfolders and files will overwrite all subdirectory differences. Oops! Eliminate the possibility of this very real mistake by being as flat as possible. Do only one or two levels of permissions differences; I prefer just one level. Our file server for departmental and team folders is I: on the desktops. From there, we do I:\Accounting, I:\Sales, and so on. Each of those folders has its own permission structure, and that’s it. No odd I:\Accounting\SuperSecret\ folders with different permissions. If they need that, it can become I:\SuperSecret\ and be on the same level. Anyone who has worked with complicated permissions structures will no doubt be able to tell amazing horror stories.
– Use only those permissions that you need to use. For almost everyone, this can be narrowed down to Modify and Read-Only. Don’t get fancy with Change or List or others.
– Use as few explicit permissions on folders as possible.
– Do not use EVERYONE or AUTHENTICATED USERS. User Domain Users if you absolutely must have a share open to “everyone.”

By following these guidelines, you accomplish a few things:

– Reduce the chance of permission inheritance mistakes.
– Improve the ability to pull accurate permissions reports.
– Decrease the amount of time and effort needed to make permissions changes and re-establish permissions (you can just push down permissions from I:\Accounting to all subdirectories and not worry about what you’re wiping out).

3) account organization
While ScriptLogic has a nice tool to pull access reports, it is still yet another program for staffers to learn and, really, you can do much the same thing with some effective use of Active Directory accounts and groups.

For every folder on your file server that needs different permissions, create two groups to hold the users who will use those permissions: Read-Only and Modify. For I:\Accounting, I would make the groups Accounting Folder-Read-Only and Accounting Folder-Modify. Then anyone who needs Modify access to Accounting should be placed into the Accounting Folder-Modify group. Apply both of these groups to the explicit permissions on the folder with their respective permissions. This should mean you will have only a few explicit permissions on each folder: SYSTEM (likely), Adminstrators (likely), the Modify group, and the Read-Only group. Nice and clean!

One caveat to this approach is in the way Windows handles group tokens. When a user logs into their computer, the logon process will inform that computer which groups the user is a member of. If the user’s group memberships change, their current session will not get the updated group membership information until the user logs out and logs back in (I typically just tell people to reboot, as they understand that better).

So all permissions changes will now require you to put that user or groups of users into the proper permission group, and then have them reboot. In a way, this is much easier than logging into the file server and updating permissions directly on the folders.

The biggest benefit, however, is in the ability to report on access. If you want to see what John Smith has access to, you just have to see which groups he is a member of. You’ll see Accounting Folder-Modify, and it is quite obvious what he has access to. Likewise, if you check the members of the Accounting Folder-Modify group, you will see who all has access to that folder. Quick and simple!

One last note about AD organization, it really helps to have a very updated and group-based AD organization. Every employee in the company should be set to report to someone else in the Ogranization tab, and they should belong to some sort of role-based group. Accounting employees should be in the Accounting group, and so. This way you can use groups instead of individual users when placing people into their Modify and Read-Only groups. This is tough, however, if HR is not very clear about the roles people play, or if the department and team names change frequently and without warning.

4) data ownership
Lastly, if a company is going to take permissions and access seriously, then ongoing support needs to be able to question requests made for those access levels. John Smith shouldn’t just be able to request access to the Sales folder to the Help Desk himself. Someone has to authorize this access. Unfortunately, while most would think his manager is an appropriate authority, in reality, his manager typically has no idea what sort of information is in the store and will likely not do anything that prevents his employee from being productive.

A solution to this is similar to the Discretionary Access Control (DAC) method where data owners are assigned to data stores. The Accounting folder would be assigned an owner. This owner is then responsible for authorizing who has access to that folder. As part of that responsibility, that data owner should also know what sort of data they are a custodian of. If there are sensitive documents in the data store that some departments should not be privvy to, the data owner should know this.

Accounting or Human Resource file shares are perfect examples of this sensitivity. The Help Desk should not be blindly granting this access just because a user requested it.

Some other tasks:

– regularly report permissions, both in AD groups and in explicit permissions. This will definitely show you how Windows “copy” screws with permissions. Likely, you’ll want to regularly “re-push” inheritance down through each folder so that you can refresh the cleanliness of your permissions reports.
– reports should be given to data owners for their review
– make sure all permissions change requests are clear, explicit, and tracked, such as in a help desk ticket system. Don’t assume Bob J. means Bob Jones. The requestor should be as explicit as possible so that Bob Johnson doesn’t accidentally get access to HR.

There are plenty of other caveats and approaches to doing user access security in a Windows environment, and quite a lot more work than is described here, but this should at least give some good ideas on an approach that I think works pretty darn well.

I am embarking on a new project with a good friend of mine. I have taken one of my older laptops and installed an insecure version of Windows XP onto it. The insecurity has a number of different levels, and includes some vulnerable third-party services as well. The goal of this is to give it to him for a week and have him break into it. I’ve even put some fake services up that give back fake banners and capture whatever he does to those services. Maybe in a few more weeks, he’ll set one up for me in similar fashion. If he breaks into the box, he has to show me how he did it. If he doesn’t, I’ll show him what I had in mind for an attack (i.e. there has to be a known and demonstratable attack vector).

The point of this little game will be not to stump each other by creating hardened systems or to try to find some 0day (we’re not that sophisticated by any means!), but rather to just practice what we know, be aware of how security holes are created and where to look for them, and show each other different tools and ways to do things. Maybe after I have done this I’ll post more details, but I certainly don’t intend to do something profound or amazing with this.

Over time, sometimes I get a few little pet peeves built up and I tend to use my blog here as a way to release those peeves. So today is deemed “rant day” and I’m going to shoot out a few small items that bother me.

community peeves
I understand that we’re a worldwide community and as such, English is not everyones first language. That’s cool with me. But I dislike seeing English-speakers just massacre the language. Constant grammatical errors and broken sentences make Jesus want to punch babies.

Reading comprehension. This is a big one. You can almost tell when someone has read the first three lines of a mailing list email and spits out a reply to just those three lines; completely missing the rest of the message. Sometimes they give really good answers…to the wrong questions.

People who argue that there is only one right way to do something (their way). While protocols have not hugely changed and some things are very much the way they were 10 years ago, environments and business uses are vastly different. What works in one environment will maybe not work or be acceptable in another.

Saying there is no silver bullet to security, then pointing out how everything is broken just because it has one problem or two. This creates a nice little unachievable paradox. I see this used a lot by analysts who refuse to be wrong. I think the only acceptable solution to them is if Jesus sends down a sword-bearing angel to protect the data.

workplace peeves
Making work requests without providing the reason, authority, or problem that is being fixed. “I need access to John’s files.” Please explain the request in context so that we’re not just making willy-nilly changes that may or may not fix the problem and may or may not be authorized. I think I see this in the workplace more often than any other pet peeve of mine.

Reading comprehension. My last job was not so bad at this, but my current company is just downright terrible when it comes to email coherency and reading comprehension. I purposely send out emails that are 2-3 sentences long to get right to the point, and people still don’t read. Just yesterday I got a request to stand up a new email account. I replied back asking who needs access. The response I got back was, “It doesn’t work yet.” Jesus is starting to kill kittens now.

I love when users engage multiple people on a problem without telling anyone, i.e. abusing support processes or authority. Sometimes some people ask each IT employee their question until someone gives them the answer they want. Sometimes people escalate everything they don’t get their way on, complaining to everyone until it is done. Others with authority sometimes engage 3 people to get their important task done, without realizing those three people may be stepping on each other’s toes and wasting 2 of those people’s time and possibly breaking other things in the process. If 3 people are going to work on a problem, I’d rather work together and share ideas than each of us secretly working separately.

Just finished standing up an OpenSSH server on a Windows box mostly just to do it for once. I know, I know, it should be Linux. But I firmly believe this is a Windows world and like it or not, this request will someday come up just like this. I’ll put a Linux one up on my next box.

All told, there are plenty of sites around that walk through setting up SSHD and Cygwin on Windows. Sadly, they all seem to leave the unsuspecting user very insecure. These commands are always listed:

mkpasswd -cl > /etc/passwd
mkgroup –local > /etc/group

These commands copy Windows users and groups over to the cygwin environment. Yes, that includes accounts like Administrator and any other group that exists. There is a reason that “root” is and should be denied login via SSH: it is an ultimately predictable account to brute! Well, I would bet that on many Windows SSH installations, Administrator is likely pretty predictable. To get around this, I just remove those users in /etc/passwd.

This just reminds me that security is not something everyone thinks about. And too often instructions that get passed around are not the most prudent instructions. That’s great that a lot of people who likely shouldn’t be allowed to, can now set up SSH servers on Windows and plop them onto the Internet and they work just fine. I guess it just takes a little more knowledge to know about the potential issues and then to solve them. I hear a lot about how security needs to be baked in, and while I agree, I think it will be a long time coming and will always cost either time and effort or money. (The same holds true for physical home security…)