RE: Windows File Sharing with IPCop

From: Benjamin D. Goldman (bgoldman@kipany.com)
Date: 08/22/02 

Date: Thu, 22 Aug 2002 09:59:51 -0400
From: "Benjamin D. Goldman" <bgoldman@kipany.com>
To: "Scott Lammers" <slammers@sscglobal.net>

Even without NAT - you cant do authentication on permissions in windows
NT or 2000 without using these ports. This is of course a problem for
putting up remote file servers for all windows users, because of the
plethora of security problems with even thinking about exposing these
ports to the outside world.

If you are regularly monitoring some of your netowrk traffic, or run a
decent IDS with some logging capability, you should notice that these
ports are used in scans to help determine what OS you are running.
Considering how easy it is to take over an ill configured windows
computer, scanning for these ports being open can be a precursor for a
bulk attack on what the evil doer considers to be a block of windows
machines.

Whenever I see a block of such scans over a time period, on all of my
networks, I get a bit paranoid, and run around checking my patch status
(which, contrary to popular belief about practice, CANT always be
upgraded, because of major MAJOR problems with some of the service
packs/security updates in windows, in combination with hundreds of
thousands of lines of custom code developed by people who re-use too
many of the built in components and dont build enough of their own)

So - the rule of thumb is ALWAYS block these ports on a windows network.

-----Original Message-----
From: Scott Lammers [mailto:slammers@sscglobal.net]
Sent: Thursday, August 22, 2002 7:56 AM
To: Benjamin D. Goldman
Cc: Bryan Ponnwitz; focus-ms@lists.securityfocus.COM
Subject: RE: Windows File Sharing with IPCop

I have also tried a similar setup, not using an IPCop firewall, but also
ran into problems. I had opened up ports 137, 138, and 139. The
problem
that I had was NAT. For some reason, the way I had NAT set up, it would
not allow me to send packets back and forth through the firewall. Your
situation sounds similar so you may want to check out the limitations on
NAT, if in fact you are using it.

On Wed, 21 Aug 2002, Benjamin D. Goldman wrote:

> even without NetBios, you probably have to open up the RPC, etc etc
> ports... the ones that you should always block..
>
> 135-139... someone correct me if I am wrong - but I dont think you can
> even use the browsing capability (which is still required even without
> netbios use explicitly) without having these open.
>
> -----Original Message-----
> From: Bryan Ponnwitz [mailto:bponnwit@btboces.org]
> Sent: Tuesday, August 20, 2002 8:36 PM
> To: focus-ms@lists.securityfocus.COM
> Subject: Windows File Sharing with IPCop
>
>
> I've run into a road block with my IPCop firewall and I'm hoping for
> some help. Here's the scenario:
>
> I'm running IPCop at work to segment me from the rest of the network.
I
> have a WinXP box behind my IPCop firewall. The XP machine is acting
as
> a File and Printer Sharing and Terminal Services server. File sharing
> is configured for TCP/IP (no NetBIOS). I would like to be able to
> access the WinXP box from the outside network. I looked on the
> Microsoft support site, and found that you need to forward 445/TCP and
> 445/UDP to get it to work. I set this up and still cannot access the
> shares. I did the exact same setup for Terminal Services (except on
> port 3389) and it works like a charm. When I try to telnet to port
445
> on the IPCop machine from the external network, it doesn't connect
which
> makes me think that it's a problem with IPCop. Could it be that IPCop
> runs it's secure web UI on port 445 and is therefore blocking that
port?
> Any help would be much appreciated!!
>
>
> Bryan Ponnwitz
> Webmaster - Broome-Tioga Boces
> bponnwit@btboces.org
> (607) 763-3609
>

Relevant Pages

  • Re: "Network" icon
    ... To close a number of ports, GRC suggests to use the Network icon and re-configure bindings to a certain indicted form. ... There seems to be no control of Server Types, no way to uncheck "i want to enable NetBIOS over TCP/IP" on any and all protocol lines, no way to install NetBEUI, and no way to change/set hardware adaptor bindings. ... 1- The information on the GRC page is severely out of date, it was written pre Windows 2000, it makes absolutely no mention at all of any operating systems post 1998. ...
    (microsoft.public.win2000.general)
  • Re: Strange ports open
    ... but both NetBIOS / Windows networking and Exchange open ... I recommend keeping a log of the ports found open ... Administration Tools [Server Manager, User Manager, Event Viewer, Registry ...
    (microsoft.public.security)
  • Re: New/old Trojan?
    ... > looking on google ... anything on Windows systems, ... Sounds like this malware may have rootkit-like ... ports can be useless. ...
    (Incidents)
  • Re: DCOM 10009 errors on SBS2008 with NAS
    ... make a specific GP rule that allows the ports to that NAS unit. ... The DCOM event id 10009 will occur when a client workstation has a miss-configured firewall or other issues affecting its network communications within the domain, for example if the workstation is not managed by an SBS GPO. ... Depending on your firewall solution this might be implemented or might require opening several ports. ... If the workstation is on a different subnet than the SBS server and it is running Windows XP SP2 or higher, the firewall exceptions provided by the SBS group policies will not properly allow the required connectivity. ...
    (microsoft.public.windows.server.sbs)
  • Re: [fw-wiz] how prevelant
    ... over the same few ports), and the tendency of script kiddies to run ... Windows attack tools, I tend to suggest that if you open your firewall up ... > it amazing they were passing domain information across the internet. ...
    (Firewall-Wizards)