Windows Server

Research Services · Guest

Are there any MS KB articles or whitepapers that detail how to use IPSec to
encrypt SMB traffic?

We are in an Active Directory Forest, and would like to use Group Policy to
configure IPSec to encrypt SMB traffic between all of our Windows XP clients
and our Windows 2003 File Servers (using Kerberos). Is it possible to set
this up so _only_ TCP 445 on _particular_ servers will always be encrypted
when communicating with our XP clients?
We are not currently using IPSec and would like to enable encryption for
ONLY the case mentioned above if possible.

Thanks for any information.

Steve Riley [MSFT] · Guest

Sure, you can configure IPsec policies with filter lists that select ports
445/tcp and 445/udp only for whatever IP addresses or DNS names you wish.
Some deployment guides at http://www.microsoft.com/ipsec can help. Let me
know if you've got specific questions.

Steve Riley
steriley@microsoft.com

Research Services · Guest

Thanks for the link, I'll check it out before I ask a follow up question.

"Steve Riley [MSFT]" <steriley@microsoft.com> wrote in message
news:51839632413148843626719@news.microsoft.com...

Steve Clark [MSFT] · Guest

Do you require encryption of this traffic, or just authentication?

You can use IPsec transport mode to secure communications such that any
machine that can not AuthN with IKE will be unable to communicate. This
means that a user will never get prompted for credentials since IKE fails.

"Research Services" <key@lamar.n0-sp@m.colostate.edu.NO> wrote in message
news:uWsyCHp%23EHA.3236@TK2MSFTNGP15.phx.gbl...

Research Services · Guest

I have read through much of the documentation in the link you provided.

Our environment is a Child Domain in an Active Directory Forest. We have
2000 and 2003 DCs in our Child Domain. All clients are Windows XP and all
of our clients are within our own Domain.

I want to encrypt file sharing traffic between all of our clients and a
particular Windows 2003 file server. Basically, I don't want Word and Excel
files saved on the file server to be sent across the network in plain text.

If I understand it correctly, I must create a "server" IPSec policy on the
Windows 2003 box, and I must create "client" IPSec polices on all of the
Windows XP boxes. For testing purposes, I have created the IPSec polices in
the Local Security Policy on each computer (later I will move them to being
Group Policy-controlled).

Below I will explain how I created my policies - can you take a look and see
if there is anything wrong or not recommended? They do appear to be working
correctly when we packet sniff.

1) Created a new IP Security Policy (CLIENT)

a. Removed all entries under Key Exchange Security Method except for:
3DES/SHA1

2) Created a new Rule (leaving the Default Response rule intact)

3) Created a new IP Filter List (leaving the All IP & ICMP Traffic
default lists intact) - this new list is the Selected one (Radio Button)

a. Mirrored: Yes

b. Protocol: TCP

c. Source Port: ANY

d. Destination Port: 445

e. Source IP Address: 'My IP Address'

f. Destination Address: <IP Address of File Server>

4) Authentication Method: Kerberos

5) Tunneling: NO

6) Connection Type: All Network Connections

7) Filter Action: Selected 'Require Security'

a. Negotiate Security

b. Removed all entries except: 3DES/SHA1

c. Uncheck all option boxes on Security Methods Tab

1) Created a new IP Security Policy (SERVER)

a. Removed all entries under Key Exchange Security Method except for:
3DES/SHA1

2) Created a new Rule (leaving the Default Response rule intact)

3) Created a new IP Filter List (leaving the All IP & ICMP Traffic
default lists intact) - this new list is the Selected one (Radio Button)

a. Mirrored: Yes

b. Protocol: TCP

c. Source Port: ANY

d. Destination Port: 445

e. Source IP Address: <IP Address of Test Client>

f. Destination Address: <IP Address of File Server>

4) Authentication Method: Kerberos

5) Tunneling: NO

6) Connection Type: All Network Connections

7) Filter Action: Selected 'Require Security'

a. Negotiate Security

b. Removed all entries except: 3DES/SHA1

c. Uncheck all option boxes on Security Methods Tab

Once these were created, I assigned them on both the server and the clients,
encrypted communications works fine.

Questions:

1) If I have a small number of clients, can I just add Filters with
each of the client IP addresses to the Server IP Filter List? (Eventually I
will add a 'Specific IP Subnet')

2) It looks like only 1 Filter List can be selected with a Radio
Button, so is this the only one in the list that is being acted on? If so,
is that the same case for the 'Filter Action'?

3) Can I edit the 'Default Response' Rule? Or is it best to leave it
untouched? In particular, I'd like to remove all but the 3DES/SHA1
Encryption and Integrity Security Method.

4) Can I safely change the Connection Type: to: LAN if the only way
for these clients to access the file server is through the LAN. (We don't
have any 'remote access' servers in the mix)

5) Is there anything else I can do to "streamline" this IPSec policy
(i.e., remove any of the other default rules or lists)?

6) I did notice the increased CPU load on the server when copying large
files across the encrypted connection, is there any way to 'help out' the
CPU short of lowering the encryption to DES or removing encryption
altogether? (hardware or software solution.?)

Thank you for taking to time to review these and help me sort this out!

"Steve Clark [MSFT]" <bogus@microsoft.com> wrote in message
news:OOun04M$EHA.2032@tk2msftngp13.phx.gbl...

Research Services · Guest

Another general question -

Can Etercap sniffer/interceptor defeat IPSec? We've seen how Etercap uses
ARP poisoning to grab the router IP and then have the ability to decrypt SSL
traffic - can it do the same thing on IPSec traffic? Or is there a way to
configure IPSec to prevent this?

"Research Services" <key@lamar.n0-sp@m.colostate.edu.NO> wrote in message
news:uztw71W$EHA.1188@tk2msftngp13.phx.gbl...

Steve Clark [MSFT] · Guest

Negative.

Sniffing ESP encrypted traffic is worthless, and sniffing ESP-null traffic
is possible only if the "monitor" can authenticate itself with IKE and has
the appropriate parser to view ESP encapsulated packets.

"Research Services" <key@lamar.n0-sp@m.colostate.edu.NO> wrote in message
news:O6sfxTk$EHA.3592@TK2MSFTNGP09.phx.gbl...

Steven L Umbach · Guest

How does Etercap decrypt ssl protected data payload without the shared
session key?? I understand how arp poising works to redirect a data stream
to another computer but that alone would not allow the decryption of the ssl
payload data since the secret shared key is only known by the ssl server and
ssl client that set up the ssl session. --- Steve

"Research Services" <key@lamar.n0-sp@m.colostate.edu.NO> wrote in message
news:O6sfxTk$EHA.3592@TK2MSFTNGP09.phx.gbl...

Research Services · Guest

I don't know the details, but there is more information in the following
link. Since ettercap can use ARP poisoning and "take over" the router, it
can intercept the network traffic and get ahold of the keys and decrypt SSL
and SSH1...

http://ettercap.sourceforge.net/forum/index.php

"Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
news:%232$np$LAFHA.3616@TK2MSFTNGP11.phx.gbl...

Steven L Umbach · Guest

I already researched that topic somewhat and did not see any mention if it
decrypting ssl payload. The shared session secret keys are kept on the
client and server involved in the ssl connection and are not available via
network sniffing/rerouting in an end to end connection. If the router is a
proxy server such as ISA and the proxy is the endpoint for the ssl then I
see how it could capture traffic between the router and end host since it
then is in clear text. Thanks for the link and I will read it more. ---
Steve

"Research Services" <key@lamar.n0-sp@m.colostate.edu.NO> wrote in message
news:%23IWIzrjAFHA.3376@TK2MSFTNGP12.phx.gbl...

Research Services · Guest

I'd like to know what you find regarding this - we've seen our network guys
"proof of concept" hijack the router IP, and then sniff and decode SSL and
SSH1 traffic all using ettercap. SSH2 seemed secure and we are hoping that
Microsoft IPSec (using Kerberos) is secure as well...

"Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
news:%23K7nMKlAFHA.3264@TK2MSFTNGP12.phx.gbl...

Steven L Umbach · Guest

OK. I read a little more. Ettercap can not decrypt ssl. From what I can tell
it is a kind of man in the middle attack and submits a bogus certificate to
the user. The user must accept the "untrusted" certificate [which many
would] and then a ssl session is set up between the user and the attacker
and of course then the attacker can read whatever the user sends to him. The
MB link you provided specifically said that it would NOT be effective
against ipsec because of the way ipsec authenticates a negotiated session. I
wish MS would soon provide a way to enforce through Group Policy and such
that users do not have the option to accept untrusted certificates. ---
Steve

"Research Services" <key@lamar.n0-sp@m.colostate.edu.NO> wrote in message
news:eEUnwMmAFHA.3016@tk2msftngp13.phx.gbl...

Research Services · Guest

Thanks for the info - and I agree, it would be nice to have that ability
with Group Policy.

"Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
news:%23kEWrnnAFHA.2552@TK2MSFTNGP09.phx.gbl...

	Windows Server Forum Index -> Security	All times are GMT
Page 1 of 1