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.
Brice, Yeah. Carnac the Magnificent's got nothing on me. :-) I'll work on it today and probably have something out early next week. > Do you do a mentalist act on the weekends? You know, where you tell people > things about themselves that you shouldn't know, or what's going to happen to > them? > > Yesterday when we initiated our first test using the palindromic requests, > the obsolete termination entries stopped at 10:15 and stayed stopped. At > 9:12 today Richard started back up with the new "^(MSFC-sun|WT ...)" > "^(MSFC-moon|WT ...)" request patterns and I could see that in my log. > Interestingly they both were tagged 'Alternate' the first time in the log. > At 9:53 they were both terminated as obsolete and restarted as 'Primary'. > Then at 10:21 they were terminated and restarted as 'Alternate'. Looks like > this happens about every 30 minutes and that the code is not flushing the > connections properly. > > So. My problem is that with more than two clients I don't think I can craft > a series of request strings that the system won't identify as too similar. > My hopes for simply adding the pseudo-host pattern did not seem to do the > trick. Here's where your prognostication skills have come into play. > > My next option was to find out where the code resides that makes this check > and disable it. As you have seen, we have several checkpoints in-place to > control who can attach to our servers via the SSH tunnel. And SSH has > mechanisms in-place to throttle an attack. So we should be good from that > standpoint. I still don't understand the issue with the internal clients > getting the same error. > > But if that feature is turned off, the pseudo pattern will still be useful to > me for seeing who is coming in through the tunnel in a more straightforward > way. > > The only thing that will be an issue that I can see, is modifying the base > LDM code to turn that off and keeping track of that mod when we lay a new RPM > down for a new release or a rebuild of the server. > > Let me know how you think we should proceed. Probably won't get to test it > before Monday, but hey, anything is possible. > > Thanks, > > Brice > > Brice Biggerstaff, CISSP > Johnson Space Center > Weather Decision Support System > MIDDS Software Support Lead > 281-853-3011 (w) > 713-764-2601 (p) > address@hidden (alpha pager for text and email) > > Res Confacti Erimus > “We Get Things Done!” Regards, Steve Emmerson Ticket Details =================== Ticket ID: BIG-900661 Department: Support LDM Priority: Normal Status: Closed