The service's key is only known from the service and the KDC. It means that the keytab should be created with proper rights : only the service which requires it should be allowed to read the keytab. If not, any person (or service) having read access to this keytab could spoof the service's identity.
So, your're right about the attacker spoofing through the keytab, that's no better than a password in the open in the insecured backup.
I guess you could just refuse to back up those keytabs on the client machines. In a disaster recovery, couldn't you just re-export the keys from the KDC? It looks easy enough.
Please excuse my ignorance, but what is the difference?
Between Windows Active Directory (Windows Integrated Security) and Kerberos? For the sake of my argument, there is none, because AD IS a Kerberos server. You can even authenticate Linux machines against it.
If the plain text file is only readable by the webserver account (and root), then the attacker still needs to obtain the webservers privileges (or root). Same as with Kerberos.
Not if its in a clearly readable backup file on another running machine, Chief. That's how they got compromised, remember? The backup crapped up their security model. If your text config file has no password in it, due to you using "trusted connections", the attacker can't read it, no matter where you store it on the network.
Any security comes from restricting access to the credentials themselves.
Exactly my point. You must restrict access to the credentials themselves, as they are the keys to everything in your network. Those credentials are attacker gold.
Best practice is to have a separate machine (physical or virtual) that does nothing but authentication (Kerberos) and authorization (LDAP) of principals (logon accounts) for the network. No Apache, no db server, no DNS, nothing goofy, just handles security requests.
Your separate security server would only be SSH or console accessible, using Kerberos authentication only, so the attacker couldn't brute-force his way in through SSH. Even then only the Network Admin(s) would even have logon rights to that one machine.
If that sounds like work...well, it is. But is it more work to try to undo the untold damage some knucklehead did to their production servers? I'd be willing to bet their admins would LOVE to have their sleepless nights back.
The other parts of their problem are A) that the db's user name and password were available in their backups and B) that db user had permission within the database to perform DDL operations.
Part B is pretty easy to fix...just change your permissions within the db server. Part A requires that you stop putting the db user's password in the connection string.
In Windowsland, you can user Windows Integrated Security. In Unixland, you'll have to set up Kerberos.
Either way, the web server's service process logs onto the database with the credentials of its own user account (a Kerberos ticket), providing no password. The attacker cannot log in to the database server unless they manage to get logged in AS the web server's user account. This is much harder to do than just snagging the db logon info out of some plain-text script or configuration file.
In this case, if they had used trusted connections between their machines, they would have only lost their backups, not their production data as well.
Actually, my new Acura RSX (also a Honda product) has an oil change frequency of 10,000 miles, with the added bonus of taking run-of-the-mill 5W30 oil. The Insight takes 0W20 oil which, interestingly enough is pretty much unobtainable from anybody other than the Honda dealer.
Also interesting, the Accord that I traded in on my new car suggested 7,500 miles for its oil change, and it was a 96 model.
For me and my 25k, I decided that the Insight was simply too underpowered for my needs, despite the fuel economy and cool factor. If they were more around 15k...
Slashdot Mirror
Except in the case of Trend Micro's product, which is both shoddy and malicious.
Ok, I see what you're getting at.
The service's key is only known from the service and the KDC. It means that the keytab should
be created with proper rights : only the service which requires it should be allowed to read the
keytab. If not, any person (or service) having read access to this keytab could spoof the service's
identity.
http://www.kerberos.org/software/adminkerberos.pdf, page 25.
So, your're right about the attacker spoofing through the keytab, that's no better than a password in the open in the insecured backup.
I guess you could just refuse to back up those keytabs on the client machines. In a disaster recovery, couldn't you just re-export the keys from the KDC? It looks easy enough.
Please excuse my ignorance, but what is the difference?
Between Windows Active Directory (Windows Integrated Security) and Kerberos? For the sake of my argument, there is none, because AD IS a Kerberos server. You can even authenticate Linux machines against it.
If the plain text file is only readable by the webserver account (and root), then the attacker still needs to obtain the webservers privileges (or root). Same as with Kerberos.
Not if its in a clearly readable backup file on another running machine, Chief. That's how they got compromised, remember? The backup crapped up their security model. If your text config file has no password in it, due to you using "trusted connections", the attacker can't read it, no matter where you store it on the network.
Any security comes from restricting access to the credentials themselves.
Exactly my point. You must restrict access to the credentials themselves, as they are the keys to everything in your network. Those credentials are attacker gold.
Best practice is to have a separate machine (physical or virtual) that does nothing but authentication (Kerberos) and authorization (LDAP) of principals (logon accounts) for the network. No Apache, no db server, no DNS, nothing goofy, just handles security requests.
Your separate security server would only be SSH or console accessible, using Kerberos authentication only, so the attacker couldn't brute-force his way in through SSH. Even then only the Network Admin(s) would even have logon rights to that one machine.
If that sounds like work...well, it is. But is it more work to try to undo the untold damage some knucklehead did to their production servers? I'd be willing to bet their admins would LOVE to have their sleepless nights back.
Offline storage is a good first step.
The other parts of their problem are
A) that the db's user name and password were available in their backups
and
B) that db user had permission within the database to perform DDL operations.
Part B is pretty easy to fix...just change your permissions within the db server. Part A requires that you stop putting the db user's password in the connection string.
In Windowsland, you can user Windows Integrated Security. In Unixland, you'll have to set up Kerberos.
Either way, the web server's service process logs onto the database with the credentials of its own user account (a Kerberos ticket), providing no password. The attacker cannot log in to the database server unless they manage to get logged in AS the web server's user account. This is much harder to do than just snagging the db logon info out of some plain-text script or configuration file.
In this case, if they had used trusted connections between their machines, they would have only lost their backups, not their production data as well.
Actually, my new Acura RSX (also a Honda product) has an oil change frequency of 10,000 miles, with the added bonus of taking run-of-the-mill 5W30 oil. The Insight takes 0W20 oil which, interestingly enough is pretty much unobtainable from anybody other than the Honda dealer.
Also interesting, the Accord that I traded in on my new car suggested 7,500 miles for its oil change, and it was a 96 model.
For me and my 25k, I decided that the Insight was simply too underpowered for my needs, despite the fuel economy and cool factor. If they were more around 15k...