Re: IPsec - restrict communcation

From: Steve Riley [MSFT] (steriley_at_microsoft.com)
Date: 12/23/04 

Date: Thu, 23 Dec 2004 11:07:54 -0800

IPsec can use three different methods to initially authenticate machines:
digital certificates, preshared keys, and Kerberos. Kerberos will work only
if all the machines are in the same forest and are able to contact their
domain controller(s). Preshared keys are good for testing your policies but
do understand they're stored in the clear in the registry and are visible
to anyone with administrative privileges on the computer (although they aren't
transmitted in the clear during session establishment) -- and in your case
they can be very useful since you are trying to control individual machines.
For digital certificates, if you set up your own certificate authority then
you can use that to issue certificates to the computers and there is no charge
for that.

In your filter lists you will define how the computers can communicate. Each
machine will have a policy composed of several rules. A rule links a particular
filter list with a particular filter action. Filter lists define the specs
of the machines and protocols involved; filter actions define, well, the
action: permit, block, or negotiate security, as well as authentication methods
and more. Keep in mind that it is unsupported to create IPsec security associations
with domain controllers when using Kerberos as the authentication method
(http://support.microsoft.com/default.aspx?scid=kb;en-us;254949).

I'd recommend no policies on the domain controllers, really. Traffic between
members and DCs is already authenticated and protected. In your policies
for B-D and C-D communications, I'd recommend using ESP-null; it sounds like
what you're after here is authentication of the machines to each other but
you don't need the communications to be private.

So on B you'd have this:

 * from my-ip:all-ports to D-ip:all-ports, mirrored, ESP-null, pre-shared
key for B-D
 * from my-ip:all-ports to A-ip:all-ports, mirrored, allow (this allows the
computer to talk to its DC)
 * don't allow communications from computers that don't support IPsec

On C you'd have this:

 * from my-ip:all-ports to D-ip:all-ports, mirrored, ESP-null, pre-shared
key for C-D
 * from my-ip:all-ports to A-ip:all-ports, mirrored, allow (this allows the
computer to talk to its DC)
 * don't allow communications from computers that don't support IPsec

And on D you'd have this:

 * from my-ip:all-ports to B-ip:all-ports, mirrored, ESP-null, preshared
key for B-D
 * from my-ip:all-ports to C-ip:all-ports, mirrored, ESP-null, preshared
key for C-D

The "don't allow" settings on the rules for B and C mean that you don't have
to write "block" rules for the policies on those computers. I've omitted
the "don't allow" setting on D because I'm assuming that clients will need
to communicate with the application server. B is allowed to communicate only
with D (after authenticating) and only with A (in the clear) and nothing
else. C is allowed to communicate only with D (after authenticating) and
only with A (in the clear) and nothing else. D is required to use IPsec when
communicating with B and C but will communicate with anyone else normally.

So what we've got here is a set of policies that enforcing the communications
you want to permit without having to explicitly block stuff, which I'm not
really a fan of. By using individual pre-shared keys it wasn't necessary
to have rules on B and C blocking communications with each other. (Note that
if you had used Kerberos or certificate authentication in your policies,
then you *would* need such rules.)

I'm writing a two-part series on IPsec in the security newsletter. The first
part, which describes IPsec in (I hope) understandable language, is online
now. The second part, which describes scenarios, will be in January's newsletter.
See http://www.microsoft.com/technet/security/secnews/articles/itproviewpoint121504.mspx.

Steve Riley
steriley@microsoft.com

> Great Thankyou Roger.
>
> One last question,.Are the certs that are listed available free to
> use..?
>
> "Roger Abell" wrote:
>
>> Basically, you can define rules which do indicate
>> qualifications by IP or IP subnet; but you can also
>> define other forms of evidence (like availability
>> of correct cert) as qualifiers for a rule.
>> IPsec is really quite flexible in capabilities.
>> -- Roger Abell
>>
>> "davran" <davran@discussions.microsoft.com> wrote in message
>> news:6F6BC806-22BD-4B5E-9679-C2581A755ECC@microsoft.com...
>>
>>> Thanks Roger.
>>> Sorry Steve, here's more info.
>>> Let introduce a 4th server (server D) which is an application
>>> server. Both
>> B
>>
>>> and C need to communicate with this
>>>
>>> Server A would be domain controller/DNS.
>>>
>>> B and C are member servers that will have communication with Svr
>>> D,..
>>> application server but B doest not need to talk C.
>>> I'm assuming you can create a filter list to permit traffic for
>>> communication from specific IP addresses to specific IP addresses. I
>>> will
>>> read up more on this but just wanted to get a overall concept of
>>> whether
>> it
>>
>>> can happen.
>>>
>>> Thanks for you responses, appreciated
>>>

Relevant Pages

  • Re: Unauthorized workstation connections to network...
    ... the great 802.1X vs. IPsec debate... ... that goal is to keep unauthorized machines from ... at the network level with 802.1X or at the host level with IPsec. ... are standard IP -- there's no per-packet authentication after the initial ...
    (microsoft.public.windows.server.security)
  • Re: MSFT Bans insecure hashes - was"Passwords with Lan Manager (LM) under Windows"
    ... After I pointed out that "IPsec based auth" is not a basic netlogon ... authentication protocol like Kerberos, LM, NTLM and NTLMv2, you said I was ... based auth" to authenticate the request as opposed to LM, NTLM, or NTLMv2. ... Up to 75% of cyber attacks are launched on shopping carts, forms, ...
    (Pen-Test)
  • RE: Passwords with Lan Manager (LM) under Windows
    ... A device's security associations are contained in its Security Association Database ... Internet Protocol Security (IPSec) provides application-transparent encryption services for IP network traffic as well as other network access protections for the Windows 2000 operating system. ... As for "article you reference does indeed use the phrase "IPSec Authentication," but as any who reads it ...
    (Pen-Test)
  • Re: Kerberos machine authentication - apparent authentication fail
    ... as the case may be) which will delay authentication until ... I also have an Intel network adapter and WAP that does not have this> problem and even works well with 802.1X EAP-TLS for domain logon. ... In> most cases [ipsec a possible exception] kerberos authentication is not> needed to access domain resources as long as the client and server use a> common authentication method for lm/ntlm/ntlmv2. ... The main issue is to> NEVER include an ISP dns server in the preferred server list in the tcp/ip> properties or DHCP scope of any domain computer or any computer you want to> join to the domain in which case your computers may be trying to locate the> domain _srv records on the ISP dns server and fail. ...
    (microsoft.public.windows.server.security)
  • Re: Attacks on IPsec
    ... The real problem seems to be not the IPSec protocol, ... RFC 2406 says that encryption without authentication ... This cipher can be used in an ESP ...
    (sci.crypt)