Re: IPSEC Policies in AD
From: Michael C. Gates (michaell_._gatesadweb_._com)
Date: 08/24/03
- Next message: Jonathan Maltz [MS-MVP]: "Re: Need some help with personal Firewall"
- Previous message: Mark Souter: "Re: Lost Microsoft Office"
- In reply to: Brian: "IPSEC Policies in AD"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 24 Aug 2003 16:29:43 -0400
Brian,
I just started using IPSec when my Novell firewall (HD) crashed. I just
needed to get something up and running fast, and I am not familiar with
Novell, so I didn't want to go that route.
I set up for all traffic to be blocked. Then I opened the ports that I
needed and set one rule up for all my computers in the LAN (subnect) to be
able to access any port. Nobody has access to these computers, so I don't
fear someone internally getting in. But I did have to have them
unrestricted, because they talk to each other all the time for various
reasons.
The only thing I had problems with is, I wanted to let any port OUT. This
way, I could still get on the internet, make DNS requests, etc. from the
servers. This I haven't figured out.
I used to think it was SRC: MY IP > DEST: ANY, but that didn't work. I tried
a million other things, but couldn't get it working correctly. The interface
is a little confusing for me.
But none-the-less, it worked. I don't get the millions of hack attempts per
day like I used to.
If you have any suggestions for me on this, let me know.
Michael C. Gates
"Brian" <brian_anon@hotmail.com> wrote in message
news:04fb01c369b4$3fc87f40$a001280a@phx.gbl...
> I am familiar with how IPSEC policies are created for
> Windows and stored in AD.
>
> We currently do not use IPSEC policies to control
> communications between machines. However, I'm considering
> to begin testing this strategy and procedure for emergency
> response purposes (and possibly as ongoing configuration
> if maintenace and support effort is low).
>
> I believe in a NACHI outbreak an IPSEC policy could have
> been pushed to servers or desktops to do any one or a
> combination of the following:
>
> 1. Block inbound ICMP traffic (non broadcast)
> 2. Block outbound ICMP traffic (non broadcast)
> 3. Block inbound TCP traffic to ports 666-765
> 4. Block outbound TCP traffic to ports 666-765
> 5. Block inbound UDP traffic to port 69
> 6. Block outbound UDP traffic to port 69
>
> #1-2 help to regain control of network utilization to
> allow other application to function reliably. It's likely
> that Windows monitoring, discovery and diagnostic
> application may no longer function and a low probability
> that other Windows applications rely on this protocol.
>
> #3-6 Any one of these will help prevent the worm from
> propagating (even if the system remains unpatched). There
> is the possibility that it may prevent some Windows
> applications from functioning, however in most Windows
> environemnts these are rare and unusual ports.
>
> Depending on requirements, someone could also do a
> combination of blocking for the usual suspects (135/TCP,
> 137/TCP, 139/TCP, etc). This will reduce scanning traffic
> but will break many Windows functions.
>
> Does anyone have any practical experience deploying IPSEC
> policies in a large distributed Windows environment?
>
> What's a realistic expectation on how rapidly IPSEC
> policies are pushed and synchronized?
>
> Any comments or thoughts about this?
>
> Brian
> brian_anon@hotmail.com
>
- Next message: Jonathan Maltz [MS-MVP]: "Re: Need some help with personal Firewall"
- Previous message: Mark Souter: "Re: Lost Microsoft Office"
- In reply to: Brian: "IPSEC Policies in AD"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
