krb524 and port 4444 blocks

[James Reynolds]

I just tested the following command:

sudo ipfw add unreach port udp from me to any krb524

and it successfully kills the delay.  We are going to implement this 
on our lab computers, so, problem solved as far as we are concerned. 
We figure nothing is really going to be using port 4444 anymore since 
W32.BLASTER.WORM basically took it over.

Wouldn't it suck if a worm took over a common port like 80?  Can't 
block that at the router.  Ouch...

Thanks everyone who responded and helped.

--

Thanks,

James Reynolds
University of Utah
Student Computing Labs
james at scl.utah.edu
801-585-9811

>On Oct 15, 2003, at 10:58 AM, James Reynolds wrote:
>>Specifically, we are using kerberos 5 to authenticate our Mac OS X 
>>computers and we don't reuse tickets and we don't use kerberos 4. 
>>We are seeing the ~21 second delay.  We would like this to go away.
>>
>>Do you have any recommendations?  Should we poke a hole for port 
>>4444?  Should we downgrade to kerberos 4?  Is it possible to get 
>>krb524 to not do anything?  Is there some other work around?
>
>There is no way to disable this with the version of Kerberos for 
>Macintosh included with Mac OS X 10.2.  If you have Kerberos v5 
>enabled, it always tries to contact the krb524 service on your KDCs. 
>If UDP packages on port 4444 cannot make it to the KDC, or the ICMP 
>port unreachable messages can't make it back, then the Kerberos 
>libraries have to wait for the attempt to time out.  At Stanford, we 
>originally saw thisy with users behind NAT firewalls which often did 
>not forward ICMP messages, and more with campus firewalls that block 
>port 4444 because of a Windows virus.
>
>The best solution we came up with was to have affected users run the 
>following command from a Terminal prompt:
>
>     sudo ipfw add unreach port udp from me to any krb524
>
>This adds a firewall rule to Mac OS X that immediately fails any 
>attempt to contact the krb524 port (4444) on another host.  This 
>eliminates the delay, but it creates a few other problems, including 
>blocking any legitimate use of UDP on port 4444.  It also disables 
>Mac OS X's built in Internet Firewall preferences, so Stanford only 
>hands out the command (I think we built an app that runs it for you) 
>to users who complain about this.
>
>--
>Alexei Kosut <akosut at cs.stanford.edu> <http://cs.stanford.edu/~akosut/>



At 3:25 PM -0700 10/15/03, Alexei Kosut wrote:
>On Oct 15, 2003, at 10:58 AM, James Reynolds wrote:
>>Specifically, we are using kerberos 5 to authenticate our Mac OS X 
>>computers and we don't reuse tickets and we don't use kerberos 4. 
>>We are seeing the ~21 second delay.  We would like this to go away.
>>
>>Do you have any recommendations?  Should we poke a hole for port 
>>4444?  Should we downgrade to kerberos 4?  Is it possible to get 
>>krb524 to not do anything?  Is there some other work around?
>
>There is no way to disable this with the version of Kerberos for 
>Macintosh included with Mac OS X 10.2.  If you have Kerberos v5 
>enabled, it always tries to contact the krb524 service on your KDCs. 
>If UDP packages on port 4444 cannot make it to the KDC, or the ICMP 
>port unreachable messages can't make it back, then the Kerberos 
>libraries have to wait for the attempt to time out.  At Stanford, we 
>originally saw thisy with users behind NAT firewalls which often did 
>not forward ICMP messages, and more with campus firewalls that block 
>port 4444 because of a Windows virus.
>
>The best solution we came up with was to have affected users run the 
>following command from a Terminal prompt:
>
>     sudo ipfw add unreach port udp from me to any krb524
>
>This adds a firewall rule to Mac OS X that immediately fails any 
>attempt to contact the krb524 port (4444) on another host.  This 
>eliminates the delay, but it creates a few other problems, including 
>blocking any legitimate use of UDP on port 4444.  It also disables 
>Mac OS X's built in Internet Firewall preferences, so Stanford only 
>hands out the command (I think we built an app that runs it for you) 
>to users who complain about this.
>
>--
>Alexei Kosut <akosut at cs.stanford.edu> <http://cs.stanford.edu/~akosut/>