Re: SUNY-Albany and AFIT

David Knight wrote:
> 
> Hi Anne,
> 
>     Jeff Sitler at afit tells me the machine is/will
> be known as fujita.afit.edu (not that it really matters
> since the name seems to be irelavant...).
> We have an allow for both the machine name and the IP
> number. It appears that when they they connect the request
> comes from the ip#
> 
> Mar 04 19:30:34 redwood rpc.ldmd[6793]: gethostbyaddr: failed for
> 129.92.9.62
> Mar 04 19:30:34 redwood 129.92.9.62[6827]: Connection from 129.92.9.62
> Mar 04 19:30:34 redwood 129.92.9.62(feed)[6827]: Starting Up:
> 20020304190240.510
>  TS_ENDT {{NNEXRAD|UNIDATA,  ".*"}}
> Mar 04 19:30:34 redwood 129.92.9.62(feed)[6827]: topo:  129.92.9.62
> NNEXRAD|UNIDATA
> 
> Even though the gethostbyaddr fails we apparently accept their
> connection (I'm not sure if this is because we have an explicit
> allow for the IP address, or if it is a change we made to our ldm
> configuration some time ago that I simply forget right now).
> There is no entry for fujita in /etc/hosts or our NIS+ tables.
> I really don't like feeding an IP number - it doesn't bother
> me with the NOAAPORT feed, but, given the restrictions we face
> with the NLDN feed I'd really much rather be able to document
> we are feeding an .edu site.
> 
> Hope this helps...
> David
> 
> p.s. I understand that afit has security concerns, but, they are
> not alone in this regard. In fact I am becoming less and less
> comfortable feeding an essentially anonymous host at what appears
> to be a military site. For example, what if despite our best
> efforts either redwood or striker get hacked, and the hacker
> uses these machines to send nasty stuff over the IDD to
> the afit site - should we even be taking that risk, or, be
> exposing ourselves to that responsibility? Also IP numbers
> can be easily spoofed, and a military machine might be a likely
> target for this. If I had any hair left I'd probably have to
> say I must be having a "bad hair day" ;-)
> 

Hi David,

Thanks for the information.  You raise very good points regarding both
proprietary feeds and security.  I will raise these issues here for
discussion, this time in the context of .mil sites.  (LDM security is a
perennial topic.)  Although, Jeff Stitler assures us that fujita is a
.edu site.  This morning I was able to confirm that on the AFIT network
fujita is known as fujita.afit.edu.

Regarding the hacking potential, one significant safeguard is that the
LDM uses its own protocol.  Thus, there are only a few messages to which
the ldm will respond (HEREIS, COMINGSOON, BLKDATA, etc.), and it will
respond in well understood, predictable ways.  It would be very hard to
write some nefarious executable, wrap it properly, send it properly, and
get the remote ldm to do something beyond just stuffing it in the queue.

And, due to your message I learned something about the LDM this
morning.  When the IP addresses is used in ldmd.conf, the server will
try only once to do a reverse lookup.  And, that lookup doesn't need to
succeed, just as we saw in your logs above.

This means that some machine could spoof being AFIT by providing that IP
address to you and get you to feed them data.  This could be an issue
for your proprietary data.  I can understand your wanting to verify that
you're feeding a .edu.  With AFIT's restrictions that currently can't be
done.  We'll have to leave it to you to decide whether or not to feed
such sites.  

Regarding security on AFIT's side, AFIT is using names in their
ldmd.conf file instead of IP addresses, which forces the forward and
reverse lookup requirement.  So, it would be harder for some machine to
spoof being redwood.atmos.albany.edu.

I don't mean to dismiss your concerns, only to allay them.  We must
always be thinking about security.  

Anne
***************************************************
Anne Wilson                     UCAR Unidata Program            
address@hidden                 P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************