>Let me see if I can shed some light here.
>
>1. In the scenario described, the Domain Controllers that the Firewall can
>defer authentication to are inside the Firewall, so any attempts at getting
>either between the Firewall and the DCs requires a breach in the Firewall
>first. So if you're trying to get in between them to get a password, why
>bother, you're already between them if you can see any of the exchange so
>just go off and do whatever damage you're trying to do...;-]
>
>2. I'm not exactly sure how they've implemented this, but I'm aware of two
>possibilities;
>
>a) The first is to have the Firewall act as an "untrusted" domain connected
>to the internal domains. This means that none of the accounts established on
>the Firewall are valid on the internal domains. The Firewall would then
>"trust" the internal domains. This doesn't confer administrator status to the
>internal domain's administrators, but it means that the Firewall could then
>send authentication requests to the internal domain for validation. It would
>do this via an encrypted RPC channel established at boot time between the
>Firewall and a domain controller (not necessarily the Primary Domain
>Controller) for each of the internal domains that it trusts. This encrypted
>channel is based on a number of things, including an unknown password, a
>security descriptor, a machine name, and the domain name. Unlike mere account
>authentication, this method of authentication is not susceptible to the
>limitations of normal accounts (which only require Lan Manager type
>authentication).
>
>This encrypted channel doesn't permit the Firewall access to the internal
>domain's Security Access Manager (SAM), but instead simply allows the
>Firewall to accept authentication requests and pass them along to the
>internal domain for authentication. If authenticated, a "nonce", a one time
>key is created identifying the authenticated user (or object), and the list
>of access rights are returned to the Firewall in the form of a set of keys.
>The Firewall would then compare the list of keys with the key it created when
>it permitted the user (or a group that the user is a member of) access to a
>particular resource (i.e. a service, a port, whatever the Firewall wants to
>define rights for). If the key exists in the set of keys returned for the
>user ID, then access can be permitted, if not, then it is denied.
>
>This could be used to do denial of service, but no more than any device which
>uses a third party for authentication. If the Firewall is going to
>authenticate against a third party, its has to pass the authentication
>request on to another device, as is the case with a trusted domain.
>
>Once again, to forge this you would somehow have to be able to place packets
>on the network link between the Firewall's internal adapter and the trusted
>NT server. Since this isn't a constantly listening two way channel, just
>stuffing packets wouldn't be of any use. You would have to get the Firewall
>to want to authenticate you, and then stuff the packets in place of the
>packets its actually sending or receiving. Since the channel is encrypted,
>and the whole process associated with a time-limited key created between the
>Firewall and NT Server when the Firewall booted, forging this would be quite
>a challenge.
>
>b) I was also aware of some sort of HTTPS channel being used between the
>Firewall and the NT Server to replace the encrypted channel used by the trust
>relationship. This would allow Raptor more control over this channel, and
>possibly more integrity with the communications from their perspective (since
>its their's, and not MS). They could then provide a service to be placed on a
>PDC to interact with the MS Login process to handle the challenge and return
>a simple "Yes/No" response. Rather than speculate too much about this, maybe
>Dale can tell us if this is so.
>
>3. As Peter pointed out, you don't rely on a PDC to do authentication. In an
>NT world, the PDC is the sole place where the user database can be modified,
>but Backup Domain Controllers (BDCs) have complete copies of the entire user
>database, and offer the ability to use them as a logon source. They are
>capable of doing complete authentication including returning the keys for all
>the groups, rights, etc... that the user has access to. So if the PDC fell
>over, first of all, automatically another BDC on the network (either on the
>same LAN or across a WAN link if its part of the same domain) will assume the
>role of PDC and promote itself to this role. It then becomes the sole
>location for the user database modifications.
>
>Now if Raptor has used method 2.b. above, then there is the possibility that
>losing your PDC could render your Firewall inoperative (I'm sure it would
>fail closed, or maybe just be unable to authenticate access and therefore
>deny access to valid users), but the loss of a PDC in any NT environment is
>no small occurrence, and if all it takes is to install a service on the new
>PDC, this would probably not take very long to arrange (i.e. there might be a
>small window of denial). If its using method 2.a. above, then the change
>would be transparent to the Firewall.
>
>4. John Betts proposed that the sniffed password on the Internal network
>would be as valid as the real password, presumably using this sniffed
>password to fool the Firewall into allowing you access to resources.
>
>This is dreaming John...;-] The user ID and password combination are first
>OWF encrypted, and then recombined and encrypted with either DES or RSA,
>depending on what type of client you have. While its true that the data that
>is stored in the SAM (and what is used to compare against the encrypted user
>ID/password combination) could be recreated from the OWF, the problem is that
>you have to somehow get the Firewall to issue the authentication request and
>then stick your sniffed information into the packets that it is sending to
>the NT box. If you don't do that, then having the information doesn't serve
>you any purpose. In addition, the information sent via the encrypted channel
>between the Firewall and the NT box is sent in the clear (inside the
>encrypted channel), so your sniffed information is not what is inside the
>encrypted channel.
>
>In addition, these user ID's can't access the Firewall itself, but are used
>as authentication for Firewall services, so no matter what you do you could
>not use this information to log into the Firewall and change permissions. The
>Firewall, in either case, is using its own, local, user ID's for its own
>administration, not accounts from the Internal domain (although you could
>probably enable this unless Raptor has specifically denied that ability, in
>which case you would have to be careful about the clients you used to
>administer the Firewall...that's assuming they used this method to enable
>remote administration, and I have no knowledge that they have done this...)
>
>5. Paul asked, "what makes a PDC authentic?". Basically, in real simple
>terms, there is a key in the encrypted registry that tells the NT box that it
>is the PDC, and a different one that tells each BDC that they are a BDC, and
>so on. This key can be changed by a user that has Administrative rights on
>the box, but if they did change it, then they would only have access to their
>local SAM, not the SAM on other machines (unless their Administrator account
>was already the domain's administrator account). So, yes, I can make any
>machine I want into a PDC, and I can even make it the PDC of an existing
>domain. This will only result in denial of service of any kind if I make a
>valid BDC of a domain into the PDC of the same domain, since their SAMs, and
>therefore the security keys, are the same. If I was to install a completely
>new machine and just tell it that its the PDC of an existing domain, no
>existing machine on the network would consider it as such. New machines being
>added to the network might get confused, and possibly become members of the
>forged domain, but this would be plainly obvious to a reasonably
>knowledgeable NT administrator and be easily traceable.
>
>As to failover due to router problems, these are an issue with NT. If we
>assume model 2.a above, where there is a trust relationship, the loss of the
>route to a valid DC for a domain which has been trusted will result in the
>collapse of the trust. There is a timeout period, where the Firewall would
>continue to attempt to reestablish the trust, but after this period has
>completed, the trust is broken and would have to be reestablished through
>administrator intervention. Because of the distributed nature of domains, you
>could have valid DCs for a single domain on multiple subnets, in which case,
>as long as one of these can be reached the trust will persist. NT doesn't
>care which one of multiple DCs for a domain it is connecting to.
>
>Most recommended domain configurations will have at least one DC on each
>network segment, physical or protocol, although more cost effective solutions
>can be found if necessary. Since a DC could also be used as a workstation,
>they can be transparently placed in many locations, albeit with a higher
>level of risk.
>
>The process of creating a valid BDC in an existing domain requires the
>presence of the PDC, it cannot be done without it. As I said earlier, you
>could forge the domain altogether by dropping the existing PDC (and all its
>associated BDCs because one of them will immediately become PDC) and creating
>a new PDC with the old domain name. However, if you did this, the trust
>between the Firewall and the domain would be broken, as you would not have
>the keys to validate the trust with the Firewall (its more than just a
>password and domain name). By the way, the same thing is true if you delete a
>user account that has files associated with it through NTFS permissions. Once
>you delete the account, even if you create a new account with the same name
>in the same domain, it still will not be able to access the files.
>
>As for looping routes and such, maybe you could explain that thought a little
>more since I'm not sure what you're describing there. There is some
>under-the-covers kind of authentication going on, however.
>
>Cheers,
>Russ
>...eek, quick, someone give me some broken software, I'm suffering beta
>withdrawls...
>
>
>
|
|
