[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[LDM #BIG-900661]: Terminated obsolete upstream
- Subject: [LDM #BIG-900661]: Terminated obsolete upstream
- Date: Fri, 13 Jun 2014 13:04:32 -0600
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