Quote:
In regards to this subject I am a professional. Original Big Three.
If ASPD where my client I would have simply done to following if true backups existed: (by 'true' I mean valid data that is NOT compromised)
1. I would have the board software vendor on the phone and decide upon the best most up to date board version that supports my existing backups.
Assuming that you have an extended support agreement (aspd is 10 years out of date, right?) and /or market leverage. Barring that, the best you'll get is "upgrade to current release and call us back if you still have problems." Been there, done that, usually in the middle of the night with Trillions (honest, I'm not making that up - if the public only knew how money flows!!) of dollars at stake, with EVPs of MS, IBM, SUN, etc.
2. I would discuss with board software vendor which Operating Systems are available for my chosen platform which again support my existing backups. I would also discuss HTTP server change.
Hmm, was it the OS that was hacked? Was it HTTP? Was it some middleware? Was it SQL security? I don't know and I am not asking. I won't assume facts not in evidence. Perhaps the evidence is elsewhere and I've not seen it. The initial symptom on 2/7 was IMO, not usually indicative of OS issues, but application layer security issues.
3. If at all possible, I would change the OS, perhaps even platform if money is not an issue. Quite simple: Completely re-image existing hacked server. Examples: Change Linux vendor versions. Buy a nice little Sun or IBM pizza box.
That's a great plan if it was the OS that was hacked.
4. With fresh OS installed, I would have next installed latest board software. Perform all required processes and change management updates.
And how many testing iterations must be done to determine a stable platform? If aspd's software is as far out of date as has been mentioned in this thread, it will take MULTIPLE iterations to determine the software works, the security is sound and the databases are in tact for the new front end. Is it possible that this is EXACTLY what is happening during this outage?
5. Restore databases. Done.
The point of the above is that IF the backups are valid, there is no need to mess around with a compromised OS. Wipe the OS, install new board software, update board, perform restore, done.
Not if upgrades are in the plan, especially if the "bad" software is multiple revisions old.
I realize with #4 if no change management processes existed, there could be A LOT of work before a restore could take place.
Why # 3?
Because, if truly hacked by those suspected, they are waiting and WILL RETURN. AGREED!!!
Platform and OS change will allow at least some time to monitor site activity.
Come back up with the same OS that was hacked..... forget it. Was it the OS or was it SQL?
Come back up with a freshly installed OS, but not an upgraded or different version.... forget it, unless patching and updates where not being practiced, the hackers will know exactly where to hit next.
<span style="color:#4169E1">Agreed again if that was the point of attack. If the point of attack was elsewhere, say the middleware security, "fixing" the OS won't have great effect.</span>
Since the site runs an Apache HTTP server based upon a RedHat Linux platform, if the OS is not completely re-installed, it is just gonna be a time bomb.
Not a fault of RedHat, but a fault of running ten year old board software.[/b]