Windows Server

GaryH · Guest

Hello all,
From time to time we see workstation connections to the network that are not
joined to the domain. Does anyone know how these machines can be bumped off
the network?
Thanks,
Gary

Mark Gamache · Guest

only a technology like 802.1X can keep unauthorized connections off of the
network. It requires a switch that is compliant and an IAS server.

Cheers,

--
Mark Gamache
Certified Security Solutions
http://www.css-security.com

"GaryH" <hornbeck@siskiyous.edu> wrote in message
news:uRfOrSvCFHA.2600@TK2MSFTNGP09.phx.gbl...

Stuart Mackie [MCSE MCSA] · Guest

Hi Gary. You could implementing IPSec so that only authenticated
workstations & servers could communicate. Since your in a domain
environment IPSec with Kerberos would be the best combination, although you
could use Certificates as well if required. Some IPSec deployment guides
can be found on http://www.microsoft.com/ipsec. IPSec is quite straight
forward to implement, the link below is a step by step guide for
implementing IPSec on Windows 2000

http://www.microsoft.com/windows2000/techinfo/planning/security/ipsecsteps.asp

You should also make sure an acceptable use policy is made available to
pupils, employees etc and they are aware of the consequences if they are
broken.

--
Hth,
Stuart Mackie
www.stu.uk.com
MCSE: Sec MCSA: Sec

"Mark Gamache" <mark.gamache@css-security.com> wrote in message
news:%234uMIvvCFHA.868@TK2MSFTNGP10.phx.gbl...

Mark Gamache · Guest

I hate to contradict Stuart's post, but IPSec will not keep unauthorized
connections off of your network. IPSec protects communications with
authentication and encryption. It is a fantastic protocol, however it has
no control over network port access. With IPSec running, an unauthorized
machine can still connect to and use your IP infrastructure.

Additionally, IPSec is a bit more difficult that the link suggests. You
will need to make exceptions for Domain controllers, DNS server and DHCP
servers. If you have a lab and are willing to take the time, its not overly
complex, but there are quite a few little gotchas.

802.1X on the other hand blocks traffic from crossing a port until the
connected user or machine is authenticated. It however provides no
encryption.

Cheers,

--
Mark Gamache
Certified Security Solutions
http://www.css-security.com

"Stuart Mackie [MCSE MCSA]" <newsgroups@--REMOVE_THIS-NO_SPAM--stu.uk.com>
wrote in message news:uKYSLwwCFHA.3376@TK2MSFTNGP12.phx.gbl...

Jeff Cochran · Guest

On Fri, 4 Feb 2005 12:03:59 -0800, "GaryH" <hornbeck@siskiyous.edu>
wrote:

Steve Riley [MSFT] · Guest

Ah, the great 802.1X vs. IPsec debate... ;)

When thinking about this problem, it's instructive to consider what the ultimate
goal is. In most instances, that goal is to keep unauthorized machines from
communicating with authorized machines. There are two ways you can do this:
at the network level with 802.1X or at the host level with IPsec.

802.1X seems to be better choice, at first: after all, if I can keep the
unauthorized machines from communicating on the network, then my authorized
machines will be protected. Thing is, there's a flaw in 802.1X that keeps
it from fully achieving this goal.

802.1X authenticates only the initial connection from the computer to the
LAN switch. Once the computer authenticates, all communications *after* that
are standard IP -- there's no per-packet authentication after the initial
authentication. The switch only keeps track of the MAC address (and in some
cases the IP address, too) of the computer that authenticated and opened
the switch port.

There is a documented attack against 802.1X that takes advantage of the lack
of per-packet authentication. If another computer were connected to the same
port -- say there's a hub between the port and the computers -- and that
computer sniffed the network and then duplicated the MAC and IP addresses
of the first computer -- then that second computer could connect to hosts
on the network after the first computer authenticates to the switch. (The
same thing could happen with VMs running on a single computer.)

Using IPsec instead of 802.1X solves this problem. It's correct that IPsec
can't prevent unauthorized machines from communicating on the network. But
if my real goal is to keep unauthorized machines from communicating with
authorized machines, then IPsec the better choice for achieving this goal.
By applying an IPsec policy to all my authorized computers, I'm requiring
that any computer that wants to communicate with any other computer be equipped
with the same IPsec policy. In my policies I will specify ESP-null (I don't
need encryption, just authentication) with Kerberos authentication. IPsec
performs two authentications: the first is the initial machine-to-machine
authentication, that's the Kerberos bit; after that, every single packet
flowing between the two computers is digitally signed, another form of authentication.
This removes the condition that would otherwise allow man-in-the-middle attacks.

There's a lot of elegance here. Because my IPsec policy requires Kerberos,
only domain-joined computers can communicate with each other. And because
the only way to get the policy is to join the domain, non-conforming computers
won't be able to do anything useful. Rogue machines can flood the network
all they want, but nothing will listen, nothing will respond -- and that's
the real goal here. But what about the flooding attacks? That's something
you can easily detect, and you just shut off their switch port.

Here at Microsoft when we wanted to create such an isolation policy (which
we now call "domain isolation"), we actually started looking at 802.1X first.
But we abandoned that when we discovered that there's really no way to manage
it. Wired 802.1X has no group policy management, whereas IPsec does. There
are certain places where you'll have to exempt IPsec: domain controllers
(since that's how computers initially authenticate), DNS/DHCP servers, IP
printers, and computers that aren't capable of IPsec. Knowing that, it's
very important to have a mechanism that's manageable centrally, and IPsec
can be.

Note: wireless 802.1X networks don't have the same problem. During the authentication
process the RADIUS server and the client construct a WEP key and the RADIUS
server delivers this key to the access point. An "attack" wireless client
won't possess the key and therefore won't be able to connect to the access
point.

Steve Riley
steriley@microsoft.com

Miha Pihler [MVP] · Guest

Hi,

To add to Steve's post and from my experience with IPSec that I deployed for
my customers it is usually cheaper then having all switches 802.1x compliant
and all computers connect directly to them.

To prevent use of IP infrastructure I usually deploy ISA firewall and allow
only authenticated users to browse the internet (for this again -- you have
to be a member of domain) and the only way to send mail out of the network
is through e.g. Exchange server using MAPI protocol (again -- you have to be
authenticated user).
This would prevent use of network for sending out spam or even if someone
left hidden wireless access point they can't go anywhere.
To go even further, I often remove forwarders and root hints from internal
(active directory) DNS servers. Now even if the client gets DHCP address and
DNS (or assigns it manually) it will only be able to resolve internal host,
but nothing from the internet. For clients to be able browse the internet,
they use proxy (ISA server) that resolves the internet address, while ISA
firewall will deny direct DNS queries to the internet.

--
Mike
Microsoft MVP - Windows Security

"Mark Gamache" <mark.gamache@css-security.com> wrote in message
news:%23Wn7iexCFHA.328@tk2msftngp13.phx.gbl...

Steve Clark [MSFT] · Guest

802.1x is the equivalent of asking a bad guy to play nice.

IPsec is needed here. IPsec transport mode is like having Arnold
Schwarzenegger there MAKING machines be nice.. Or at least, making them
follow the security parameters defined by the responder...

"Mark Gamache" <mark.gamache@css-security.com> wrote in message
news:%234uMIvvCFHA.868@TK2MSFTNGP10.phx.gbl...

Steve Clark [MSFT] · Guest

VLAN's are nothing more than defined broadvast domains that people can put
rudimentary ACL's on.

Nothing about a VLAN should ever imply "security"... They are a management
construct, nothing more.

Back to the topic.. Wanna know who wants 802.1x? Infrastructure
manufacturers. Why? Cause if the gear you have right here, right now
doesn't use it, you have to replace it. They love that...

IPsec doesn't require the purchase of thousands (or more) dollars of gear to
make it work. In either case, you need to carefully plan the implementation
of either technology to ensure the threats you are facing are being
mitigated...

"Jeff Cochran" <jeff.nospam@zina.com> wrote in message
news:420a363e.309157725@msnews.microsoft.com...

Mark Gamache · Guest

I have to take issue with the 802.1X bashing.

First of all, the writer was asking specifically about keeping connections
off of the network. IPSec doesn't do that, not even a little. IPSec is
fantastic and if I were planning infrastructure from the ground up, I'd use
it and 802.1X. With IPSec, an attacker still has layer 2 access and can
perform arp redirection and thus sniff Kerberos and NTLM authentication to
harvest weak passwords. If your IPSec policy is based on PKI, obviously
there is no option for that.

Second, there is only one documented attack against 802.1X which requires
the person being attacked to not notice a hub that has been added under
their desk or the DoS when that attacker clones their MAC and uses their
session.

I would appreciate any comments on this (from you MS folks especially). I
think understanding the limitations and overall scope of a technology
solution is important. It seems that the debate is often framed as IPSec
vs. 802.1X, which I think is unfair to both technologies. Assuming that an
organizations networking gear is semi-up-to-date, its likely they already
have everything they need to implement 802.1X. The MS whitepaper on wired
802.1X makes a compelling case.

Cheers,

--
Mark Gamache
Certified Security Solutions
http://www.css-security.com

"Mark Gamache" <mark.gamache@css-security.com> wrote in message
news:%23Wn7iexCFHA.328@tk2msftngp13.phx.gbl...

Steve Clark [MSFT] · Guest

You'll have a hard time attacking IPsec in the manner in which you're
suggesting.

First and foremost, when using IPsec transport mode, you make a hard and
fast decision that states that only those machines that can authenticate
using IKE will respond to requests (if that is how the IPsec policies are
set up). 802.1x doesn't provide end to end protection for *squat*. It
merely sits there when a client establishes a connection to a switch and
decides whether or not that port is allowed to continue operating on the
switch, period.

Having said all that, if you can use them *both*, that is more of a defense
in depth approach which is both useful and timely. They are designed to
protect against different threats at different layers however. Therein lies
the confusion for some folks.

"Mark Gamache" <mark.gamache@css-security.com> wrote in message
news:ep9LmKWDFHA.624@TK2MSFTNGP15.phx.gbl...

Steve Clark [MSFT] · Guest

I forgot to mention, NTLM doesn't enter into IPsec as a threat at all.

Kerberos might, but I have only seen academic references to attacks, nothing
proven.

"Steve Clark [MSFT]" <bogus@microsoft.com> wrote in message
news:e2xk5FXDFHA.208@TK2MSFTNGP12.phx.gbl...

Mark Gamache · Guest

Yeah, I'm not sure where NTLM came from... I must have forgot the context
of the conversation...

There are a couple of GUI tools that grab the K5 exchange and you can run
word lists and brute force against the exchange. Only good against weaker
passwords of course.

Additionally there is a Linux tool that can perform a known plaintext
against the MS K5 pre auth due to its use of system time followed by a $.

Actually, I'm going to take a look at catching weak passwords in K5
exchanges in IKE. I'll let you know how it goes.

If you are interested in taking a look at any of the tools, I'll send you
links out of band. I don't like to post references to hack tools in news
groups.

Cheers,

--
Mark Gamache
Certified Security Solutions
http://www.css-security.com

"Steve Clark [MSFT]" <bogus@microsoft.com> wrote in message
news:e$2%23BJXDFHA.2608@TK2MSFTNGP10.phx.gbl...

Steve Clark [MSFT] · Guest

Remember though, you're looking at Machine authentication... That "attack"
will fail like Clinton trying to tell the truth... Impossible? No..
Improbable? Yep.

"Mark Gamache" <mark.gamache@css-security.com> wrote in message
news:e0H$yuXDFHA.2620@tk2msftngp13.phx.gbl...

Mark Gamache · Guest

Correct me if I'm wrong, but don't all DCs have to have an exception in
their IPSec policy to let all K5 traffic thru (whether for a machine
principal or user principal). So if I request a service ticket to my
exchange server, which will require IPSec, I have to contact the KDC without
IPSec. I can't use IKE (K5) with the DC until I've passed Kerberos
authentication. Catch 22. Does this sound correct?

--
Mark Gamache
Certified Security Solutions
http://www.css-security.com

"Steve Clark [MSFT]" <bogus@microsoft.com> wrote in message
news:%23xJoDNgDFHA.2568@TK2MSFTNGP10.phx.gbl...

Unauthorized workstation connections to network... Goto page 1, 2 Next

	Windows Server Forum Index -> Security	All times are GMT Goto page 1, 2 Next
Page 1 of 2