Hello,

I googled for it and came up with this:
http://www.ietf.org/rfc/rfc1510.txt
"When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
   using IP transport, the client shall send a UDP datagram containing
   only an encoding of the request to port 88 (decimal) at the KDC's
IP
   address; the KDC will respond with a reply datagram containing only
   an encoding of the reply message (either a KRB_ERROR or a
   KRB_KDC_REP) to the sending port at the sender's IP address."

So I guess from this it is still not clear, guess I could watch the
traffic with a sniffer...

Anyway I decided to include the results of my test.

Test:
Windows 2000 servers (neither a domain controller)
Added ipsec filter on 169.254.30.10 to block all traffic from ip
169.254.30.20
Used the FoundStone Scanline utility which yielded the following
results:

Scan 1 : from 169.254.30.20:12305 - notice scan failed

C:\foundstone>sl -g 12305 -p -t 1-443 169.254.30.10
ScanLine (TM) 1.01
Copyright (c) Foundstone, Inc. 2002
http://www.foundstone.com
Scan of 1 IP started at Mon Oct 21 10:29:34 2002
--------------------------------------------------------
169.254.30.10
Responds with ICMP unreachable: No
TCP ports:
--------------------------------------------------------

Scan 2: from 169.254.30.20:88 - notice scan succeeded

C:\foundstone>sl -g 88 -p -t 1-443 169.254.30.10
ScanLine (TM) 1.01
Copyright (c) Foundstone, Inc. 2002
http://www.foundstone.com
Scan of 1 IP started at Mon Oct 21 10:29:00 2002
--------------------------------------------------------
169.254.30.10
Responds with ICMP unreachable: No
TCP ports: 25 80 111 135 139 443
--------------------------------------------------------

Then I added the registry key and restarted the ipsec policy agent on
169.254.30.10

Scan 3 : from 169.254.30.20:88 - notice scan failed

C:\foundstone>sl -g 88 -p -t 1-443 169.254.30.10
ScanLine (TM) 1.01
Copyright (c) Foundstone, Inc. 2002
http://www.foundstone.com
Scan of 1 IP started at Mon Oct 21 10:32:49 2002
--------------------------------------------------------
169.254.30.10
Responds with ICMP unreachable: No
TCP ports:
--------------------------------------------------------

Thanks
Fred

>>> "Roger Seielstad" <rogerwiredeuclid.COM> 11/05/02 07:52PM >>>
Would that not be traffic destined to port 88, not sourced from port
88?
Or is Kerberos 88 to 88 (like ISAKMP is 500 to 500)?

----------
Roger D. Seielstad
Email Geek

-----Original Message-----
From: Fred Williams [mailto:A20FBW1wpo.cso.niu.edu]
Sent: Tuesday, November 05, 2002 1:29 PM
To: focus-mssecurityfocus.com; security-basicssecurityfocus.com
Subject: was - RE: Access to well-known ports on Win2K -now [IPSec
-Default behavior]

Hello,

As long as you're discussing ipsec filters please permit this bit of
"thread drift"... Most all of you know this already but there are
always
new readers or perhaps those new to Win2k ipsec policies...

According to the article:
Traffic That Can--and Cannot--Be Secured by IPSec
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q253169

All traffic from any ip port 88 is ASSUMED to be Kerberos traffic and
hence is exempt from all ipsec filters. So just by implementing a
"block
all" ipsec policy, ANYONE can still port scan your computer by binding
their scanner to their local port 88 and targeting your computer.

According to this article:
IPSec Does Not Secure Kerberos Traffic Between Domain Controllers
http://support.microsoft.com/default.aspx?scid=KB;EN-US;q254728&

A registry setting was added in Win2K SP1 to support disabling this
"feature" HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC
REG_DWORD: NoDefaultExempt
Value: 1

I wrote a quick VBScript to then set this key on all computers in an
Active Directory OU. If anyone is interested in the script just email
me
directly. Note the ipsec policy agent needs to be restarted for the
change to take effect...this can be scripted as well... Hope someone
finds this helpful.

Thanks
Fred

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]