Re: IPSec to encrypt SMB traffic?

From: Research Services (key_at_lamar.n0-sp@m.colostate.edu.NO)
Date: 01/25/05

  • Next message: mherchel: "Re: Alerting on Failed Audits"
    Date: Tue, 25 Jan 2005 08:30:55 -0700
    
    

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


  • Next message: mherchel: "Re: Alerting on Failed Audits"

    Relevant Pages

    • Re: IPSec to encrypt SMB traffic?
      ... Ettercap can not decrypt ssl. ... > the attacker and of course then the attacker can read whatever the user ... > Group Policy and such that users do not have the option to accept ...
      (microsoft.public.windowsxp.security_admin)
    • [NT] Opening Group Policy Files for Exclusive Read Blocks Policy Application
      ... Group Policy in Windows 2000 is implemented by storing data in the Active ... enable an attacker to lock the Group Policy files, ... An attacker would likely exploit the vulnerability by first logging onto ... any new policy settings would not be applied. ...
      (Securiteam)
    • Revised: Microsoft Security Bulletin - MS02-016
      ... This bulletin has been revised. ... Opening Group Policy Files for Exclusive Read Blocks Policy Application ... The vulnerability would enable an attacker to block the application of new Group Policy settings, but any settings that had been applied during previous logons would remain in force. ...
      (NT-Bugtraq)
    • Alert: Microsoft Security Bulletin - MS02-016
      ... Opening Group Policy Files for Exclusive Read Blocks Policy Application ... Network administrators using Microsoft® Windows® 2000 domain controllers. ... The vulnerability would enable an attacker to block the application of new Group Policy settings, but any settings that had been applied during previous logons would remain in force. ...
      (NT-Bugtraq)