Firewall rules for AD and mapping network share

[Chris]

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

 

[Guest]

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)

 

[Guest]

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

 

[Guest]

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)

 

[Guest]

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

<quote who="Lars M. Hansen">

<snip>

Thank you Lars for the information!

GJ

 

[Guest]

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)

 

[Guest]

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.
>
>--

 

[Guest]

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

 

[Guest]

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)