Uh no
Go to the main breaker that feed the servers whatever. And pull the 600v switch off
The smartest layout for that situation is having the main breaker box close to the hooman IT operator room
No choice if it is very serious breach
Uh no
Go to the main breaker that feed the servers whatever. And pull the 600v switch off
The smartest layout for that situation is having the main breaker box close to the hooman IT operator room
No choice if it is very serious breach
Nah. Rip that shit right out of the chassis. Destroy that RJ45 port. Make it so the security audit team has to resolder a jack to the mobo before they can even ssh to the box.
Trust me I run a security company. If you need help with your security please feel free to contact me! We are the best in the business!
Yea but it take time !!!
How many shit you have to unhook from whatever to save the shit ?? 100 ?? That take minutes !!!!!
just have a tub of water rigged above the server
Y'all... just... unhook the cable from the demarc...?
The advice I've always heard is disconnect network but leave powered for forensics/recovery. Some ransomware store the decryption key soley in memory, so it is lost upon power loss
That actually makes sense. We had a ransomware attack once. We also disconnected the device but I cant remember if we powered it off. At the time it stopped encrypting due to that since our network drives were not reachable anymore.
Is there actually a way to spread the encryption process to a server?
Im not a it expert at alll. But reallly ?
Best I understand the encryption key is needed to encrypt and decrypt, so if the malware isn't written well enough it may well continue to store the encryption key in memory.
There's some old malware on archive.org that just pulls the FAT off the filesystem into memory and offers a dice roll to restore it
I vaguely remember the advice actually being to leave it running but disconnect it from the internet. Although maybe hard disconnect the backups if you can.
And probably the intranet, too, just to be safe.
Depending on where the breaker is relative to the UPS, of course.
No, have a Safety Control Rod Axe Man. The dropping rod hits the breakers and smashes it, cutting power!
Should be a trunk line disconnect switch that kills both power and data. And if your manager is cool, then it's a guillotine switch.
Break and pull now, those are a mess
Only the ones added after initial install. The originals are nice and tidy.
You are not invited to look at my setup then.
These are clearly put together with care.
Ok but what about the door handle
No, the instructions must be followed or it won't work. /j
Hahahahahaahhahaha
Great idea, and realize likely a joke, but wouldn’t you just need to pull the one or two that connect out to the internet?
There could, in theory, be a malicious machine on the internal network that was previously infected, which is now acting as command and control. So if you didn't know which one it was...
Turn of the power, no need to rip anything
Use a bomb. No need to take out the lights.
Nuke it from orbit. It's the only way to be sure.
It's better to throw it away into a black hole.
That's generally a good idea, however, there can be reasons not to do it.
The device could be infected in a way that it won't turn on again.
You might have an isolated management network that allows you to monitor the device and traffic (naturally ripping all cables also disconnects the management network).
And whatnot. But generally I agree.
You two are overlooking the most important thing. It might be fun to crazily rip out the cables then make a junior guy go trace and repatch it all. The opportunity to legitimately do that doesn't come along often.
Where's your sense of drama???
Given that fucking rats nest of cables, even if you needed to only pull one: good luck finding it in a hurry and good luck pulling only that one.
It is either the white one or the blue one so the odds are 50/50, right? /s
Well the white ones look like they were somewhat cable managed.
God have pity on that mortal souls of its a blue one.
Depends. If you're at home with a single endpoint, maybe.
But in cases like the image there's a lot of internal traffic and you'd want to stop the malware spreading internally. There might not even be internet connection at all.
Most serious infections are able to work within isolated internal network. You can stop data breaches by cutting external traffic but if you have ransomware you might want to cut internal connections too.
You might be able to stop the ransomware from triggering on some devices. That of course depends on the type of ransomware and whether it's triggered based on time, external command or something else.
Who cares if it's ransomware, just restore your backups
I think that's rather odd comment. Naturally nobody wants ransomware. And there are good reasons.
Backups may exist, but do they work properly? Or are the backups encrypted too?
How old are the backups? They might be less than a day old. But less than a day might still mean a lot of extra work and financial loss.
There might be a lot of work restoring the backups. You might have a lot of different systems.
In one of the largest ransomware cases in history, Maersk worked for months to get systems back up and running and data up to date. The insurance payout for it was 1,4 billions. Which is at least indicative of the cost.
And Maersk had recent and working backups.
Don't tell me you'd try to continue using the compromised systems if you somehow aborted the drive encryption process
Likely not, but definitely depends on the situation.
And how do you know the backup is not compromised?
I think it's not as clear cut. It's always a risk assessment and depends on context.
I have to say that I'm not a security expert, just an amateur with conceptual understanding of the topic and some opinions.
Wait, we were taking backups?
"Cut the hard line to the mainframe!"
"uh all the cables are soft, i don't see any hard lines"
seen too many times. But thank you for posting it on lemmy
me:
Post funny things about programming here! (Or just rant about your favourite programming language.)