IPSec to encrypt SMB traffic?

[Research Services]

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

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
(e-mail address removed)

 

[Research Services]

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

 

[Steve Clark [MSFT]]

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]

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!

 

[Research Services]

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?

 

[Steve Clark [MSFT]]

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.

 

[Steven L Umbach]

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]

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]

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]

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]

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]

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

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

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