Assuming something is in place to block any random processes/people from the internet trying to authenticate against AD and possibly locking out userids you are doing much better. The two main concerns I see are DOS and information disclosure. DOS is easy for anyone who has the ability to send an auth packet to an internal AD that can force a lockout given enough bad passwords are tried. If they have userids it is even easier. Information disclosure is tougher and generally requires more information, a bug on a machine on the edge (or a machine that has traffic routed straight back to it from the internet), or something else along that track of reasoning though someone who doesn't understand security could pretty easily stick an LDAP box on the internet and have it wide open to anyone who wants to query it.
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Noah Eiger Sent: Tuesday, February 01, 2005 12:11 PM To: [email protected] Subject: RE: [ActiveDir] FTP Server In or Out So would you just forward ssh to the SFTP box? So, then there is a hole to the outside into AD, but it is encrypted. Is this then a similar security risk as OWA, etc? What about simply requiring external FTP users to connect via VPN? If this VPN terminates on an internal box and uses AD credentials (e.g., forwarding PPTP or IPSec), where does that sit in the "risk" scale? -- nme _____ From: Brian Desmond [mailto:[EMAIL PROTECTED] Sent: Monday, January 31, 2005 5:46 PM To: [email protected] Subject: RE: [ActiveDir] FTP Server In or Out Van Dyke's product will tie back into AD. It encrypts all the traffic with the SSH protocol, which I think has been pretty good as far as history goes. --Brian Desmond [EMAIL PROTECTED] Payton on the web! www.wpcp.org v - 773.534.0034 x135 f - 773.534.8101 _____ From: [EMAIL PROTECTED] on behalf of Noah Eiger Sent: Mon 1/31/2005 5:38 PM To: [email protected] Subject: RE: [ActiveDir] FTP Server In or Out Wow. Thanks for the reply. It sounds to me like it simply is not worth it. At least in our case, it is just not that many accounts to setup. Frankly, since it is pretty open anyway, I would be willing to setup some slightly more generic accounts (violating my rule about not having anonymous accounts) and just change the passwords frequently. Just out of curiosity would those SFTP servers tie back into AD or does that just mean that the data and initial challenge are encrypted? -- nme _____ From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, January 29, 2005 9:19 PM To: [email protected] Subject: RE: [ActiveDir] FTP Server In or Out Single Sign On is the holy grail, however getting it internally versus everywhere is a noble goal on its own. Getting it there would relieve tremendous amounts of admin work for many companies and it is pretty feasible to pull off with the support of kerberos. Going outside makes things sticky. AD on its own with other MS resources really isn't enough of a segregated bastion I think for this type of use. AD was designed at the time of share everything and keep it all open and interconnect. The lockdown of security came after that and most people are afraid (rightly I often think) of locking down the default security in fear of what other MS apps will break and then they hear the dreaded words of not supported in that configuration from MS. I encountered that a couple of times with Exchange when trying to tighten things down. You are not only dependent upon any apps that were developed internally by people who didn't understand AD security but those written by other vendors including Microsoft. For fun, take away authenticated users read access sometime and see how many apps nose dive. If you look at the security of AD/AM, it is much closer to what the security of AD should be. In fact I would like to see an MS high AD security pack for people deploying AD that sets up the directory in a secure manner that is fully supported by MS. As it is, you can start locking it down (especially some of the prop sets) and you can't get complete answers out of MS on what MS apps will break. The times I have asked I have gotten responses along the lines of well, we can't track all apps across the world... etc etc, So then I say, I just want the info for MS apps, they can't produce even that. If you could say this machine here in the DMZ, can only send auth packets only to AD for these specific users that would be much better. If it only allowed x auths from a certain IP and then blocked the IP that would be better. If it did the same with address blocks even better. You can't tell the OS to do that. You can play with firewalls and see what you can block off but again, you run the risk of running into a configuration that MS will say.... well we don't really recommend that. Plus, things piggyback and if you can get one thing through, something else will probably go with it. I have no problem having the single signon barrier be at the internal/external line assuming you don't have something else to block the intial access to the internal stuff. Again if you are frontending the access to AD with something like a securID FOB then AD is significantly less exposed. People who have OWA and whatever out there exposed and backending into their production internal AD aren't necessarily safe because nothing has ever happened. They just haven't been hit yet or don't think they have been hit yet. That isn't secure by any definition. I agree with Brian's comment of "Anything that prompts a user for credentials and takes them to AD is just as much a problem as the next, assuming the apps are all coded properly.". From the standpoint of DOSing that is quite true. Outside of that though is what else does it need from AD and how much access does it have to AD. Do you put deny ACE's on everything in AD for computer accounts or remove all mention of everyone and authenticated users and pre-windows 2000 in the event someone compromised one of those boxes and starts dinging against AD as localsystem of that machine? In the end you can never positively prove something is secure. You can prove something is insecure, but the state of not being known to be insecure isn't secure. Another one I like to throw out there is that just because you or your friends can't work out a way to hack into something doesn't mean it can't be done. Assuming that is dangerous. So you put compensating controls into place and think about how bad it could get if something that you don't think can happen, does happen. If someone compromises your ftp server, how bad could it be for AD? How bad would it be for you if someone landed a program on that box that constantly fired authentication at the DCs and locked out ever single admin account, or ever single account on every single domain? How costly would that be for you? How fast could you figure out and stop what happened? If you don't have lock outs, how long would it take for a password to be found? How much data in the directory is avaialble to a machine account that you don't want being posted on public boards on the internet or have all of the email addresses sold to spammers? How many people are running around now thinking that giving someone else domain admin on a child domain is perfectly safe for their forest because they are locked into their own domain? How long did people think in the beginning that was safe until some of us started saying... hey, these DCs across an entire forest are pretty interconnected.... If I have a DC of my own in a forest that isn't mine, how are you stopping me from writing to common NCs and replicating to DCs that aren't mine? Everyone thought that was safe at first or at least most did. Five years later many people are still thinking it is. Relate that to other things that you think are safe now. How much risk do you have? How much is acceptable? I was responding to a post in one of the newsgroups this weekend about some guy who has a manager who feels that wide open WAP's is acceptable risk. I think it is insane, they think it is fine. Does he know the actual risk and accept it or does he not understand the risk? Could be either way. When you deploy an FTP server that ties back to the corporate internal production AD that runs all of your critical internal business functions, do you know the risk? Have you compensated for it? Personally in a large environment that controls any machines that I am not the only admin on I could never say I understand all of the risks involved so couldn't possibly have compensating controls for all of it. So you back up and say, how much is reasonable? That is dangerous territory because everyone has different definitions of what is reasonable. If you tie back to AD you can never say it is safe. The only way you could say your internal AD was safe is if they were completely disseparate systems with no way to even connect to AD from the outside like that. Paranoid. Absolutely. I know some real smart scary people out there and I trust no one. joe _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas M. Long Sent: Saturday, January 29, 2005 7:16 PM To: [email protected] Subject: RE: [ActiveDir] FTP Server In or Out 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
<<attachment: winmail.dat>>
