[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #BIG-900661]: Terminated obsolete upstream

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