I see the view point that everyone else is talking about, but it seems kinda hard to keep AD from the internet. What do you do for VPN access, OWA, portals that authenticate against AD, etc? Is the solution for these things to create another username and password for all of them? Generally speaking the whole point of AD is to reduce admin task. The other holy grail that is all the buzz these days is SSO, is that just a CIO (shiny things are cool) idea? That aside, wouldnt it be better to setup a *nix box that is authenticating against AD and use SFTP for such a thing? Or heck, maybe there is SFTP for windows? I guess that would require a client, but you could link to one. Honestly I would like to keep this discussion going, but maybe more on the topic of security in general. I value alot of peoples opinions who take part in this group, and wouldnt mind opening my mind to ideas or side effects that i may have not thought about. Just my two cents (or is mine only worth one)
________________________________ From: [EMAIL PROTECTED] on behalf of joe Sent: Sat 1/29/2005 11:21 AM To: [email protected] Subject: RE: [ActiveDir] FTP Server In or Out The thing to keep in mind, is if ever the machine is compromised, the attacker has the same access to resources that the box has. So if the box can see the directory, so can the attacker. Also keep in mind that if there is any method to push auth back to the main directory, the D.O.S. possibility is there. Enumeration of accounts may or may not be there, but probably is. Unless there is something non-domain related front ending the whole thing I am not a big fan of anything that touches a real production AD in an way being available from the internet for the D.O.S. lockout issues alone. You throw something in front of it say a securID auth or something like that. Otherwise, if they get a hold of your SAM Name or somehow guess it, you have possible D.O.S. problems at least. How hard is it for someone to get your SAM Name? I don't believe you can really front-end normal ftp with any real protection, you are kind of hanging out there so my preference would be to have it stand alone. This is just an opinion though. There are probably people on the list that are violently opposed to what I am saying. I am a "look for the worst case" kind of person by training though. I build out with the maximum redundancy I can get away with and try to lock things down to within an inch of everyone's life. On the other hand, I am often not surprised by bad things happening and usually have it covered. There was one case I was involved in where a local resource domain had its password hashes cracked by one of the resource domains admins and he got maybe 50 or 60 passwords. One of the other admins of the resource domain involved had an admin ID in a related account domain, he had the same password so his ID was used to crack the account domain, this resulted in the guy getting another 40,000 or so accounts and passwords. One of the IDs in the account domain was an account for an Exchange admin, his password was the same in the Exchange domain so the Exchange domain got cracked and about 40 or 50 more IDs were compromised including the Exchange Admin ID which was a bear under Exchange 5.5. Several of my domains were attached to that Exchange domain as well and we had several of the people of the Exchange domain in our domain but I am a big isolationist and different systems get different passwords and I don't let people have rights in my environments unless they truly need them all of the time, etc etc etc so there was no step for this person to jump to my domains except as a normal user. However just the same, we forced the expiration of some 200k userids over the course of the couple of weeks so the cracker couldn't access user data of someone silly enough to have synced their passwords on multiple accounts across the environment instead of using trusts or having separate passwords for the separate accounts. Security is risk management, you need to judge how much risk there is, what the risk is, what the compensating controls if any are, and then determine how open (aka insecure) you can be. Open/insecure tends to be synonymous with ease of use. The less open you can afford to be, the more difficult it will generally be to use the environment. But if the risk justifies it, people need to deal with it. joe ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Garrett Sent: Friday, January 28, 2005 7:28 PM To: [email protected] Subject: RE: [ActiveDir] FTP Server In or Out Do you have a DMZ you can put the FTP server into? This would allow the low security "Outside" interface to reach the medium security DMZ interface and the DMZ interface could then validate usernames via LDAP (AD) to the high security "Inside" interface, right? -----Original Message----- From: Noah Eiger [mailto:[EMAIL PROTECTED] Sent: Friday, January 28, 2005 4:23 PM To: [email protected] Subject: RE: [ActiveDir] FTP Server In or Out That sounds miserable. If I put it outside the firewall and out of the domain, does that mean that I'd need to setup individual local accounts on the ftp server? The idea was to set up certain folders that only a specific business client and certain in-house staff would have access to. We would have a folder for each business client and then only their in-house reps could have access. What about some sort of one-way trust from the inside out? Is there some standard way (besides simply replicating the AD user directory to the local accounts) to do this? (in the end it is simply not a lot of users - 50 or 60) -- nme ________________________________ From: joe [mailto:[EMAIL PROTECTED] Sent: Friday, January 28, 2005 3:22 PM To: [email protected] Subject: RE: [ActiveDir] FTP Server In or Out I don't think I would do it but it isn't entirely crazy. I assume you are reverse proxying 20/21 to the server? The main thing I see wrong would be if someone knows one of your internal userids and assuming you have a lockout policy, she could do a D.O.S. on that user by sending bad passwords for that account. Alternatively, it is a vector in to try and hack passwords overall. Also if someone somehow compromises the machine with an FTP overflow exploit of some sort, they then have control of a machine inside your firewall and a part of your forest. At the very least they could possibly work out a way to enumerate user account information from the entire forest and such. joe ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Noah Eiger Sent: Friday, January 28, 2005 6:11 PM To: [email protected] Subject: [ActiveDir] FTP Server In or Out Hello: Is it crazy to place a publicly accessible FTP server 1) inside the firewall and 2) on a domain? We want to control domain users' access to certain directories as well as partners connecting from the outside. Only one directory would be available to the world and then as read only. Thanks. -- nme
<<winmail.dat>>
