51–60 of 64 posts
First, thanks for disclosing this. Second - and any incident response team will tell you this - patching and removing the backdoor is not enough. You have to wipe that machine. It's not uncommon for an attacker to leave multiple backdoors. Even if you don't think they got root, you have to wipe it completely.
Destroying data is never a solution.
All kinds of sites, some supposedly super-secure, have been hacked. Now a serious question: What does this say for storing everything, including tax filings, in the Cloud?
I'm curious why you picked tax filings as an example of information that would be catastrophic to leak. Here in Finland tax information is public and it doesn't seem to be that bad. As you guess, yellow papers embarrasingly make yearly rankings of rich people and they lose some anonymity. But anybody that was in any way interested in their life likely knew that they were rich. I don't say that this Finnish practice o…
I'm assuming that the original poster is from U.S. One reason why tax filling are considered sensitive is that they include the individual(s) social security number (SSN). This number is meant to be private and, since it's often used as an identifier, it's frequently used for identity theft. See the wikipedia article below.
http://en.wikipedia.org/wiki/Social_Security_number#Identity...
First, thanks for disclosing this. Second - and any incident response team will tell you this - patching and removing the backdoor is not enough. You have to wipe that machine. It's not uncommon for an attacker to leave multiple backdoors. Even if you don't think they got root, you have to wipe it completely.
Destroying data is never a solution.
Typically when a breach-in happens you do two things:
1. backup the entire disks for forensics purposes
2. wipe everything clean, re-install the latest version of the OS + all the latest patches, re-install the latest version of the apps.
Nowhere did parent suggest to "destroy evidence".
All kinds of sites, some supposedly super-secure, have been hacked. Now a serious question: What does this say for storing everything, including tax filings, in the Cloud?
I'm curious why you picked tax filings as an example of information that would be catastrophic to leak. Here in Finland tax information is public and it doesn't seem to be that bad. As you guess, yellow papers embarrasingly make yearly rankings of rich people and they lose some anonymity. But anybody that was in any way interested in their life likely knew that they were rich. I don't say that this Finnish practice o…
It's very convenient before you start contracting for someone to see if they look like a legit business and to see if they do any kind of volume (and are in the business since a few years).
Earlier quoted context omitted.
If it was, at it occurred after the vulnerabilities were made public, they probably wouldn't say so as it would look pretty bad given the amount of advance warning they had.
Are you suggesting most popular rails (if not all) apps are upgraded by now?
First, thanks for disclosing this. Second - and any incident response team will tell you this - patching and removing the backdoor is not enough. You have to wipe that machine. It's not uncommon for an attacker to leave multiple backdoors. Even if you don't think they got root, you have to wipe it completely.
Modern servers have firmware running on internal devices, including Linux runnning on full ARM cores, that can be 1) imaged from the base OS, and 2) have full control over hardware or other important data.
This includes:
- IPMI Modules: http://fish2.com/ipmi/itrain.html
- HDD Controllers (in your HDD/SSD drives): http://www.arm.com/markets/enterprise/hdd-ssd.php
... as well as ethernet controllers, any devices with PCI option ROMs (they can control boot), and quite a few other things.
This essentially means that you have a bunch of fixed, poorly documented, runtime reconfigurable and re-imageable hardware, with full access to data and system resources.
Earlier quoted context omitted.
There's also Detectify : http://detectify.com They are in beta.
Actually, I've had really bad experiences with Detectify. Their results didn't provide anything useful that I couldn't have gotten from something like Nessus. They have a pretty nice design, but not much in the way of actual useful security.
But since the question was one of a live monitor that detects intrusion, I've never heard of such a thing. There's always the possibility of aliasing `mysqldump' or `pg_dump' to another command that emails your admins, or other manual commands that shouldn't be run throughout the course of the day. My personal boxes run such an email script anytime someone logs in as root, and emails the logfile anytime someone uses sudo. That won't help against SQLi, but might against RCE that's allowed someone to tunnel into your box.
But, in the long run, there's nothing that won't beat subscribing the the security lists of all the software you run to get immediate notice of any vulnerabilities, hiring a pen tester, and stopping every day to read the code you've written to discover what kind of edge cases might help an attacker compromise your system.
Anybody knows a good alternative? Leaking my personal info is one thing, loosing customers personal info is simply far too boneheaded to begin with.
From the perspective of a complete server administrator novice, are all of the mainstream "hacks" due to the complexity of these applications? For example, if I were to setup a basic, updated Ubuntu Server LAMP stack with a MySQL database, is this system vulnerable? I understand how to protect against XSS and SQL injection and how to hash and salt passwords properly, but where can I begin to learn about implementing…
So, how to keep safe:
1. The app itself:
If you have a small web app, you have an incredible advantage that makes your web app potentially way more secure than that of a big corporation: You write the code and you know the inside outs of the system. And you are probably the only one having passwords etc. to the system.
In a big corp, sometimes the interns write some code and they have no clue of web app security. From an attacker's perspective, one security hole is enough.
So, if you know about web app security, you're probably better off than any other big corp.
2. The server infrastructure:
If you worry about the server architecture, get a managed dedicated server. There's probably not really a guarantee that this system is set up perfectly, but there might be trustable hosters that know what they're doing.
- Keep everything up-to-date (apt-get update, apt-get upgrade). - Don't install software you don't know or can't trust - use SSH only with public key authentication, remap port 22 to something else - use SFTP + SSL for your website - don't include any third party JS-software that messes with your website. Personally, I don't even include Google Analytics. I self-host everything and install only stuff that is trustable. - don't use the root user if not necessary
There's this "myth" going on that every system is hackable. This is only partly true. You can't do anything against 0-day hacks, but if you protected your web app against XSS, SQLI etc. and your software is uptodate, there's hardly any chance that you get hacked.
What makes every system "hackable" is the human factor. The secretary that gives out her password to some guy on the telephone who pretends to be the technical administrator of server X. Are you likely to get social engineered? Probably not.
Earlier quoted context omitted.
Destroying data is never a solution.
You got downvoted by several people because what you say is not related to the person you answered to. Typically when a breach-in happens you do two things: 1. backup the entire disks for forensics purposes 2. wipe everything clean, re-install the latest version of the OS + all the latest patches, re-install the latest version of the apps. Nowhere did parent suggest to "destroy evidence".