This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Jeff, Anyone from the second level on this URL: http://www.unidata.ucar.edu/projects/idd/nexradFeed.html with you being in Ohio, I would suggest either stokes, profhorn, or flood.. traceroutes to each will shed some light as to how well you are connected to these machines.. Yes, I do not forsee any security issues either but David is in the position of holding propriatary data, so I certainly understand his concerns. He is providing a valuable service distributing the NLDN feed. Let me know what you find and who you will be feeding NNEXRAD from so I can update our records here at the UPC. Thanks, -Jeff ____________________________ _____________________ Jeff Weber address@hidden Unidata Support PH:303-497-8676 NWS-COMET Case Study Library FX:303-497-8690 University Corp for Atmospheric Research 3300 Mitchell Ln http://www.unidata.ucar.edu/staff/jweber Boulder,Co 80307-3000 ________________________________________ ______________________ On Wed, 6 Mar 2002, Sitler Jeffrey L Civ AFIT/ENP wrote: > Jeff, > Who can we get NNEXRAD from? I will place the request. > I understand David's concern, but I will bet we are much > more secure than almost any .edu site out there. > We also don't do any operational weather, it is used > strictly for research and synoptic lab. While we are on > a military base, and we are the Air Force Institute of Technology > we have all the same credentials as every other .edu site out there > except the cirriculum is tailored to meet the Air Forces needs as > far as research goes. Which in David's case, we just had 3 students > each do a different thesis on lightning for Cape Canaveral. > Have a good day. > Jeff > > > -----Original Message----- > From: Jeff Weber [mailto:address@hidden] > Sent: Tuesday, March 05, 2002 3:12 PM > To: Sitler Jeffrey L Civ AFIT/ENP > Cc: 'Anne Wilson'; David Knight; address@hidden; > address@hidden > Subject: RE: SUNY-Albany and AFIT > > > Hi Jeff, > > I understand your security issues. > > However, if you want NNEXRAD data, you will need to allow another IP for > that feed source. Redwood only carries a brief subset of NNEXRAD..only one > site. So if you desire NNEXRAD we need to evaluate that issue. Also, > regarding the NLDN data, we need to be certain David feels comfortable > feeding an IP, and then you would need to allow the IP for striker as > well, so now we are up to 3 IP (holes) in your firewall not to mention > allowing at least imogene from unidata access to your machine... > > > Keep us posted we will do all we can from here, > > -Jeff > ____________________________ _____________________ > Jeff Weber address@hidden > Unidata Support PH:303-497-8676 > NWS-COMET Case Study Library FX:303-497-8690 > University Corp for Atmospheric Research 3300 Mitchell Ln > http://www.unidata.ucar.edu/staff/jweber Boulder,Co 80307-3000 > ________________________________________ ______________________ > > On Tue, 5 Mar 2002, Sitler Jeffrey L Civ AFIT/ENP wrote: > > > Hello all, > > Just to keep you updated on where we stand. I have found out that as far > as > > incoming data. > > Our SC people want to know the specific IP address and the port, and who > > they are. > > They allow by IP only outside of "fujita", basically once our request > leaves > > fujita for Albany, it will only allow back in from the IP of redwood, but > > not the name redwood. > > I think they forget we are an .edu site inside of a .mil site, so you can > > see our > > firewall nightmare. Anything we open up has to clear the military side of > > things, then the education side of things > > before we can even get the clearance. I am sure you can imagine the > > paperwork and the explanations I had to go > > through to get the data coming in from Unidata, then I was told, "OK, this > > is the only site you want, correct?". > > They don't even like that I have a failover site, they want one site and > one > > site only. > > I really appreciate all the help I am getting from outside the base > believe > > me, as well as the understanding. > > I hope I am explaining all this so you understand, please remember I am a > > weather person in a computer position, with a whole 1 year of UNIX now > under > > my belt. > > Thanks > > Jeff > > > > > > > > -----Original Message----- > > From: Anne Wilson [mailto:address@hidden] > > Sent: Tuesday, March 05, 2002 1:27 PM > > To: David Knight > > Cc: address@hidden; address@hidden; > > address@hidden; address@hidden > > Subject: 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/ > > **************************************************** > > >