RE: Firewall Rules for NT Server and PDC

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

You still missed my point, almost in its entirety.  The point is that many
protocols can be subverted to do nasty things they weren't intended to do.
More importantly, many applications (read: sendmail, bind).

Many situations call for bind and sendmail being allowed through.  But
people take precautions to ensure that environments cannot be severely
damaged by the intrusion.  The same is true of NBT.  NBT has become a
generalized protocol for interacting with all manner of winbloze
(mis)features.  But proper configuration and access control can make NBT not
entirely idiotic to allow through a firewall.  Using some of the methods I
cited in a previous email, relative safety can be achieved through
appropriate internet-facing firewall rules, proper architecting of the
environment, and properly controlled communications channels between the DMZ
and the LAN (both firewall and application-layer).

Now, we haven't gotten into uncontrollable (or difficult-to-control)
information leakage generated by having NBT open.  That's a different
discussion entirely.  Having NBT (at least--Windows NBT) accessible over the
internet interface is always a Bad Idea.

Cheers,
Ben

> -----Original Message-----
> From: firewall-wizards-admin () nfr com
> [mailto:firewall-wizards-admin () nfr com]On Behalf Of Dawes, Rogan (ZA -
> Johannesburg)
> Sent: Wednesday, July 11, 2001 8:05 AM
> To: 'bgrubin () pobox com'
> Cc: firewall-wizards () nfr com
> Subject: RE: [fw-wiz] Firewall Rules for NT Server and PDC
>
>
> I'm not suggesting that this could simply be used without
> thought or effort.
>
> The serious implication (for those who don't realise what a
> problem protocol
> NetBIOS is already) is that if one is allowing netbios
> traffic through a
> firewall, intending to allow only authentication perhaps,
> apart from the
> obvious  file and print access possibilities, the range of exploits is
> actually infinite, based on what commands can be executed
> using psexec.
>
> The effort referred to above could be looking for existing
> credentials on
> the origin server, brute forcing domain or server passwords
> on the target
> server, etc.
>
> The other thing that makes your "bogus" statement bogus
> itself, is that
> rexec has its own port assigned to it.  The functionality is
> well known, and
> defined.  Being able to actually execute arbitrary commands
> over the NetBIOS
> protocol, which it seems was not designed for this, IS new,
> at least to me,
> and I'm sure, to many other readers of this list.
>
> I'm 100% in agreement that firewalls are not the entire solution.
>
> The simplest attack is to ride on the traffic already
> permitted through the
> firewall, whether it be NetBIOS, database access
> (xp_cmdshell, anyone?) or
> IIS and MDAC/Unicode/.Printer. The least one CAN do is limit the
> possibilities that can be exploited using the protocols
> allowed. Allowing
> NetBIOS through under the impression that all that can
> potentially be done
> is auth, file and print, event log, and registry access is
> not actually
> limiting the possibilities (depending on your access controls
> over those
> various functions on the target server - I'm not sure exactly
> how psexec
> works)
>
> Rogan
>
> -----Original Message-----
> From: Benjamin P. Grubin [mailto:bgrubin () pobox com]
> Sent: 11 July 2001 03:50
> To: 'Dawes, Rogan (ZA - Johannesburg)'
> Cc: firewall-wizards () nfr com
> Subject: RE: [fw-wiz] Firewall Rules for NT Server and PDC
>
>
> 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

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