RE: Firewall Rules for NT Server and PDC

["Benjamin P. Grubin" <bgrubin () pobox com>]

I would never try and convince anyone that NBT or windows networking is safe
to pass through a firewall, but this example is bogus.  psexec does nothing
sexy, it is equivalent to rexec on the un*x platform, which has existed for
eons.  In order to make use of a tool like this, a trust relationship would
have to be exploited.  Allowing this trust relationship to exist between
something like an IIS web server in a DMZ to a PDC, member server, or
workstation on a LAN is the *real* security issue, not the existence of
tools like psexec OR allowing NBT through a firewall.

Compromising a domain member server SHOULD NOT compromise your domain.  When
dealing with a DMZ environment that requires domain connectivity, the trust
relationships should be carefully considered.  The optimal way to do this
(imho) is to have a DMZ PDC, which is seperate from the LAN domain.
Carefully architecting the appropriate trust relationships with the user
domain should be straightforward (if you need them at all).

Remember, firewalls are not the complete solution.  Proper security practice
dictates that you must evaluate the trusts and the application
interconnectivity between each security zone in your network and ensure that
they can not be used to exploit each other to cross those zones, regardless
of infrastructure connectivity.

Cheers,
Ben

----
Benjamin P. Grubin                      bgrubin () pobox com
PGP Fingerprint: EDE9 A88F 3BCC 514A  F310 FEFB 7109 2380

> -----Original Message-----
> From: firewall-wizards-admin () nfr com
> [mailto:firewall-wizards-admin () nfr com]On Behalf Of Dawes, Rogan (ZA -
> Johannesburg)
> Sent: Monday, July 09, 2001 2:21 AM
> To: 'Bjørnar B. Larsen'; 'Ernest Opoku-Agyemang'
> Cc: 'firewall-wizards () nfr com'
> Subject: RE: [fw-wiz] Firewall Rules for NT Server and PDC
>
>
> I saw a tool fairly recently called "psexec", which is able to execute
> arbitrary commands via nbt services.
>
> For this reason, I (where I have the say-so) refuse to allow
> NBT through a
> firewall.
>
> The example that scares me immediately is:
>
> psexec \\computer cmd.exe
>
> Instant telnet, if the account on one PC is permitted to
> access the other
> computer. Otherwise, start guessing passwords.
>
> Rogan
>
> C:\>psexec
>
> PsExec v1.11 - execute processes remotely
> Copyright (C) 2001 Mark Russinovich
> www.sysinternals.com
>
> PsExec executes a program on a remote system, where remotely executed
> console
> applications execute interactively.
>
> Usage: psexec \\computer [-u user [-p psswd]] [-s] [-c] [-d] program
> [arguments]
>
>      -u         Specifies optional user name for login to remote
>                 computer.
>      -p         Specifies optional password for user name. If
> you omit this
>                 you will be prompted to enter a hidden password.
>      -s         Run the remote process in the System account.
>      -c         Copy the specified program to the remote system for
>                 execution. If you omit this option the application
>                 must be in the system path on the remote system.
>      -d         Don't wait for process to terminate (non-interactive).
>      program    Name of application to execute.
>      arguments  Arguments to pass (note that file paths must be
>                 absolute paths on the target system).
>
> You can enclose applications that have spaces in their name with
> quotation marks e.g. psexec \\marklap "c:\long name app.exe".
> Input is only passed to the remote system when you press the enter
> key, and typing Ctrl-C terminates the remote process.
>
> If you omit a user name the process will run in the context of your
> account on the remote system, but will not have access to network
> resources (because it is impersonating). Specify a valid user name
> in the Domain\User syntax if the remote process requires access
> to network resources or to run in a different account. Note that
> the password is transmitted in clear text to the remote system.
>
>
> C:\>
>
> -----Original Message-----
> From: Bjørnar B. Larsen [mailto:Bjornar.B.Larsen () ementor no]
> Sent: 05 July 2001 07:30
> To: 'Ernest Opoku-Agyemang'
> Cc: 'firewall-wizards () nfr com'
> Subject: Re: [fw-wiz] Firewall Rules for NT Server and PDC
>
>
> "Volker Tanger" <volker.tanger () detewe de> wrote:
> > The connection NT-webserver and PDC necessarily is symmetrical.
> > You will probably need to open both tcp & udp 135, 137-139 and
> > 1024+ in both directions with no questions asked.
>
> What you need is to allow udp137, udp138 and tcp139 (often
> called the NBT
> ports). Open them exclusively between the web-server and the
> PDC. There's no
> need for the high ports. (Tested with NT4SP6a on both servers.)
>
> > But with doing
> > that you will grant the web server and thus all hackers attacking
> > it (seen the latest IIS exploits yet?) all access to your
> > internal system(s).
>
> Assuming the web server is on its own interface in the
> firewall like this
>
>     INET---FW---WEB
>             |
>             |
>            LAN
>
> and assuming you've made sure nothing but HTTP(S) can reach your
> web-server(s) from the Internet:
>
> Attackers need to gain control over the web-server by cracking the
> web-service through HTTP, then crack the PDC through NBT (typically
> password-cracking or -sniffing). That's when they're finally
> in and can do
> everything imaginable to your internal net.
>
> You obviously want to make sure both the PDC and the
> web-server are locked
> down tight and patched, and that the developers of your
> webserver make their
> scripts/appliations secure.
>
> :) Bjørnar
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards