Firewall rules for AD and mapping network share

Archived from groups: comp.security.firewalls (More info?)

We are implementing desktop firewall for all our users. Do anyone has
the most restrictive rules for:
1. client mapping network drive (client: Win98, Win2K, WinXP; server:
Win2K, Linux Samba)
2. client joining AD domain and the communication between them.

Thanks
8 answers Last reply
More about firewall rules mapping network share
  1. Archived from groups: comp.security.firewalls (More info?)

    On 1 Apr 2004 18:13:17 -0800, Chris spoketh

    >We are implementing desktop firewall for all our users. Do anyone has
    >the most restrictive rules for:
    >1. client mapping network drive (client: Win98, Win2K, WinXP; server:
    >Win2K, Linux Samba)
    >2. client joining AD domain and the communication between them.
    >
    >Thanks

    You need to allow:

    53/UDP/TCP (dns)
    68/UDP (dhcp)
    88/TCP/UDP (kerberos)*
    135/TCP (dcom/rpc)*
    137-139/UDP/TCP (netbios)
    389/TCP (ldap)
    445/TCP/UDP (netbios)
    464/TCP/UDP (kpasswd)*
    500/TCP/UDP (isakmp)*

    * you may get away with not using these. Blocking port 135 in a domain
    situation will disable a lot of functionality such as remote
    management...


    Lars M. Hansen
    http://www.hansenonline.net
    (replace 'badnews' with 'news' in e-mail address)
  2. Archived from groups: comp.security.firewalls (More info?)

    <quote who="Lars M. Hansen">
    >> We are implementing desktop firewall for all our users. Do anyone has
    >> the most restrictive rules for:
    >> 1. client mapping network drive (client: Win98, Win2K, WinXP; server:
    >> Win2K, Linux Samba)
    >> 2. client joining AD domain and the communication between them.

    > You need to allow:
    >
    > 53/UDP/TCP (dns)
    > 68/UDP (dhcp)
    > 88/TCP/UDP (kerberos)*
    > 135/TCP (dcom/rpc)*
    > 137-139/UDP/TCP (netbios)
    > 389/TCP (ldap)
    > 445/TCP/UDP (netbios)
    > 464/TCP/UDP (kpasswd)*
    > 500/TCP/UDP (isakmp)*

    Which remote ports do i need to allow?
    For example, I allow TCP/UDP incomming localport 138 but does the remote
    port also need to be 138 or can it be any port?
    I am particullary interested in the ports 135, 137-139, 445 for the
    networkdrives and shares. (Blaster used 135 i thought, so how do i allow
    management traffic but disallow other traffic?).

    (p.s. there is a router at the top of my network that blocks these ports
    to/from the *evil* internet, so it's just for a local net here).

    Another thing, I always assumed DNS uses only UDP. I'm not an expert, so i
    can be wrong, but do i really need to open TCP for DNS?


    Thanks,

    Gertjan
  3. Archived from groups: comp.security.firewalls (More info?)

    On Fri, 2 Apr 2004 15:09:49 +0200, GJ spoketh

    ><quote who="Lars M. Hansen">
    >>> We are implementing desktop firewall for all our users. Do anyone has
    >>> the most restrictive rules for:
    >>> 1. client mapping network drive (client: Win98, Win2K, WinXP; server:
    >>> Win2K, Linux Samba)
    >>> 2. client joining AD domain and the communication between them.
    >
    >> You need to allow:
    >>
    >> 53/UDP/TCP (dns)
    >> 68/UDP (dhcp)
    >> 88/TCP/UDP (kerberos)*
    >> 135/TCP (dcom/rpc)*
    >> 137-139/UDP/TCP (netbios)
    >> 389/TCP (ldap)
    >> 445/TCP/UDP (netbios)
    >> 464/TCP/UDP (kpasswd)*
    >> 500/TCP/UDP (isakmp)*
    >
    >Which remote ports do i need to allow?
    >For example, I allow TCP/UDP incomming localport 138 but does the remote
    >port also need to be 138 or can it be any port?

    Netbios connections uses any local port higher than 1024

    >I am particullary interested in the ports 135, 137-139, 445 for the
    >networkdrives and shares. (Blaster used 135 i thought, so how do i allow
    >management traffic but disallow other traffic?).

    MS-Blaster and other worms that exploited the DCOM vulnerability did use
    port 135. The only way to protect your LAN from internal spreading of
    MS-Blaster type worms are to patch your systems and/or disable DCOM.
    Remote management uses RPC, not DCOM, so you're still good to go on
    that.

    >
    >(p.s. there is a router at the top of my network that blocks these ports
    >to/from the *evil* internet, so it's just for a local net here).
    >
    >Another thing, I always assumed DNS uses only UDP. I'm not an expert, so i
    >can be wrong, but do i really need to open TCP for DNS?

    There's little harm in allowing or disallowing DNS over TCP. It's is not
    very common that this is used, it happens only when the answer are to
    large to fit in one packet or when performing a zone transfer.

    >
    >Thanks,
    >
    >Gertjan
    >


    Lars M. Hansen
    http://www.hansenonline.net
    (replace 'badnews' with 'news' in e-mail address)
  4. Archived from groups: comp.security.firewalls (More info?)

    <quote who="Lars M. Hansen">

    <snip>

    Thank you Lars for the information!

    GJ
  5. Archived from groups: comp.security.firewalls (More info?)

    In article <2d44b924.0404011813.1a3972e1@posting.google.com>,
    mclo@asia.com says...
    > We are implementing desktop firewall for all our users. Do anyone has
    > the most restrictive rules for:
    > 1. client mapping network drive (client: Win98, Win2K, WinXP; server:
    > Win2K, Linux Samba)
    > 2. client joining AD domain and the communication between them.

    Forgive me, but if you are going to let the computer authenticate and
    share resources, how do you think that installing a desktop firewall
    will prevent them from sharing a virus or other nasty.

    I can't think of any method that you can use to stop the spread after
    opening all the ports that lets it spread.

    --
    --
    spamfree999@rrohio.com
    (Remove 999 to reply to me)
  6. Archived from groups: comp.security.firewalls (More info?)

    I disagree wholeheartedly. While I wouldn't want to open those ports
    either, it would probably be safe to do so over an IPSEC vpn
    connection. If you have to open them, why not consider that as an
    option?


    Dave


    On Wed, 07 Apr 2004 03:17:08 GMT, Leythos <void@nowhere.com> wrote:

    >In article <2d44b924.0404011813.1a3972e1@posting.google.com>,
    >mclo@asia.com says...
    >> We are implementing desktop firewall for all our users. Do anyone has
    >> the most restrictive rules for:
    >> 1. client mapping network drive (client: Win98, Win2K, WinXP; server:
    >> Win2K, Linux Samba)
    >> 2. client joining AD domain and the communication between them.
    >
    >Forgive me, but if you are going to let the computer authenticate and
    >share resources, how do you think that installing a desktop firewall
    >will prevent them from sharing a virus or other nasty.
    >
    >I can't think of any method that you can use to stop the spread after
    >opening all the ports that lets it spread.
    >
    >--
  7. Archived from groups: comp.security.firewalls (More info?)

    David Green <wouldnt@youliketoknow.com> wrote in
    news:li5c70tjogvbqrdpnaajf5us0ge286gaos@4ax.com:

    > I disagree wholeheartedly. While I wouldn't want to open those ports
    > either, it would probably be safe to do so over an IPSEC vpn
    > connection. If you have to open them, why not consider that as an
    > option?
    >
    >
    > Dave
    >

    How do you think that by implementing IPsec with rules set to PERMIT
    traffic on the Win Networking Ports even with VPN enabled in a shared
    resources Windows Networking environment is going to stop a virus or other
    nasty for coming across the network through the shared ports and attack
    another machine?

    It can do it no better than a desktop FW solution that has rules
    implemented to allow the Win Networking Ports on the machine to share
    resources with other machines on the network, which is it cannot be stopped
    if the rules are set to allow the traffic on the ports.

    The only two solutions that can be installed on a machine that will allow
    the Win Networking Ports to be open on the LAN but close the ports to
    attack on something like a virus or other nasty(s) that may be detected in
    the network traffic are BlackIce and Sygate, because of the IDS features in
    both products that will instruct the FW to close the ports to the IP the
    traffic is coming from.

    Duane :)
  8. Archived from groups: comp.security.firewalls (More info?)

    In article <li5c70tjogvbqrdpnaajf5us0ge286gaos@4ax.com>,
    wouldnt@youliketoknow.com says...
    > I disagree wholeheartedly. While I wouldn't want to open those ports
    > either, it would probably be safe to do so over an IPSEC vpn
    > connection. If you have to open them, why not consider that as an
    > option?

    It's hard to maintain a thread with top posters.

    If you are going to use a VPN then you don't really need to open the
    ports as all traffic will pass through the VPN and not the normal
    firewall rules. So, if you trust the other server enough to create a
    tunnel, you don't really need to know what ports to open.

    Or, are you suggesting that you are building a tunnel and then limiting
    the traffic in the tunnel to just what MS needs to share everything
    between the servers?


    --
    --
    spamfree999@rrohio.com
    (Remove 999 to reply to me)
Ask a new question

Read More

Firewalls Mapping Networking