The Full Story Behind Our Recent Disaster - Printable Version +- The VG Resource (https://www.vg-resource.com) +-- Forum: Archive (https://www.vg-resource.com/forum-65.html) +--- Forum: July 2014 Archive (https://www.vg-resource.com/forum-139.html) +---- Forum: Main Stuff (https://www.vg-resource.com/forum-1.html) +----- Forum: Site Discussion (https://www.vg-resource.com/forum-3.html) +----- Thread: The Full Story Behind Our Recent Disaster (/thread-24411.html) Pages:
1
2
|
RE: The Full Story Behind Our Recent Disaster - Phaze - 01-11-2014 (01-10-2014, 08:30 PM)Raz Wrote: Petie and I use MySQL Workbench when connecting to the MySQL server. Of course the server itself isn't public facing and we need to tunnel in for security purposes but basically with MySQL Workbench it's as easy as right clicking and selecting Truncate as Petie said. Hm... you know, this post got me thinking. After futzing about for a while and deciphering the mysterious runes inherent in "ssh user@server -L sourcemysqlport:localhost:servermysqlport" I managed to replicate a tunneling setup. I guess I can get rid of phpMyAdmin (one less potential hole to worry about!) now! Thanks, Raz RE: The Full Story Behind Our Recent Disaster - Raz - 01-11-2014 (01-11-2014, 09:05 AM)Phaze Wrote:(01-10-2014, 08:30 PM)Raz Wrote: Petie and I use MySQL Workbench when connecting to the MySQL server. Of course the server itself isn't public facing and we need to tunnel in for security purposes but basically with MySQL Workbench it's as easy as right clicking and selecting Truncate as Petie said. Good. That's exactly the way it should be. PHPMyAdmin isn't so bad so long as it's running on the server side and you're not exposing MySQL to any external network traffic but even security is paramount and so SSH with RSA keys is the way to go. RE: The Full Story Behind Our Recent Disaster - Phaze - 01-12-2014 (01-11-2014, 09:19 AM)Raz Wrote: Good. That's exactly the way it should be. PHPMyAdmin isn't so bad so long as it's running on the server side and you're not exposing MySQL to any external network traffic but even security is paramount and so SSH with RSA keys is the way to go. Server side? I thought the risk inherent in phpMyAdmin was if it was on a site since it's vulnerable to attack at times, especially if outdated. Wouldn't it make more sense if it was on another server that is having its connection tunneled through to the server with the database on it via SSH? I still use a password to SSH into my box instead of RSA keys but I'd like to believe the password is reasonably secure to make bruteforce infeasible. RE: The Full Story Behind Our Recent Disaster - Raz - 01-12-2014 (01-12-2014, 02:18 AM)Phaze Wrote:(01-11-2014, 09:19 AM)Raz Wrote: Good. That's exactly the way it should be. PHPMyAdmin isn't so bad so long as it's running on the server side and you're not exposing MySQL to any external network traffic but even security is paramount and so SSH with RSA keys is the way to go. PHP is PHP no matter where it's hosted, putting it on a remote server and tunneling the information back to the MySQL server and having the MySQL server on the same box as PHP have the exact same risks. PHPMyAdmin will connect to the same MySQL server regardless of where it's sitting so the risk is no more or less for it being installed locally, indeed the preference for it being local is to reduce data transaction latency since it won't have to tunnel to send/receive any data. SSH with RSA keys just means you can automate a lot of the work, indeed we automate a lot of processes such as offsite backups and RSA keys means there's never any passwords lying around. RE: The Full Story Behind Our Recent Disaster - Phaze - 01-12-2014 (01-12-2014, 11:55 AM)Raz Wrote: PHP is PHP no matter where it's hosted, putting it on a remote server and tunneling the information back to the MySQL server and having the MySQL server on the same box as PHP have the exact same risks. PHPMyAdmin will connect to the same MySQL server regardless of where it's sitting so the risk is no more or less for it being installed locally, indeed the preference for it being local is to reduce data transaction latency since it won't have to tunnel to send/receive any data.PHP is PHP, yes... but it's a lot harder to exploit an insecure PHP client when you don't even know it exists or where it exists, especially if it's not running all the time and is inaccessible from behind a Router. If it's on the server, all you gotta do is compromise the software to gain PHP-level-access to the server! Then you have an attacker who effectively has access to any DB you're currently using in forums etc. on the same HTTP server. Couldn't you just cron shellscripts for automation or do you need SSH access for stuff like backups? Edit: Oh hey, 512th post \o/ RE: The Full Story Behind Our Recent Disaster - Petie - 01-12-2014 You need SSH access for offsite backups. We do use cron jobs to automate backups but to copy those backups to another server, you need to be able to access it. Also, I love that 512 was a milestone for you. RE: The Full Story Behind Our Recent Disaster - Phaze - 01-13-2014 (01-12-2014, 10:37 PM)Petie Wrote: You need SSH access for offsite backups. We do use cron jobs to automate backups but to copy those backups to another server, you need to be able to access it. Fair enough. Well it is a power of 2. Those are the best numbers (64 is prob'ly my favorite power of 2, though)! RE: The Full Story Behind Our Recent Disaster - Petie - 01-13-2014 Oh, I'm well aware of why you chose it. That's specifically why I enjoyed the choice RE: The Full Story Behind Our Recent Disaster - Raz - 01-13-2014 (01-12-2014, 08:41 PM)Phaze Wrote:(01-12-2014, 11:55 AM)Raz Wrote: PHP is PHP no matter where it's hosted, putting it on a remote server and tunneling the information back to the MySQL server and having the MySQL server on the same box as PHP have the exact same risks. PHPMyAdmin will connect to the same MySQL server regardless of where it's sitting so the risk is no more or less for it being installed locally, indeed the preference for it being local is to reduce data transaction latency since it won't have to tunnel to send/receive any data.PHP is PHP, yes... but it's a lot harder to exploit an insecure PHP client when you don't even know it exists or where it exists, especially if it's not running all the time and is inaccessible from behind a Router. If it's on the server, all you gotta do is compromise the software to gain PHP-level-access to the server! Then you have an attacker who effectively has access to any DB you're currently using in forums etc. on the same HTTP server. Absolutely, and in our case we don't even use PHPMyAdmin in favour of command line MySQL from SSH and the MySQL Workbench application. If you're talking about a production hosting environment though then you're going to need PHPMyAdmin and it's going to need to be available all the time and be public facing. My preference is running it and changing the alias to something that is not /phpmyadmin or /pma. I would also use fail2ban to pick up any brute force attempts and IP ban clients that are caught doing so, the same system I use to ban SSH and webmail brute force attempts. Like Petie said, we do use cron in our backup utilities but since we have offsite backup included in to the mix we require SSH on both the production and backup servers. We also have access to a third FTP backup server which is offiste and has been disallowed access other than by the production server IP, I also disabled password based authentication after I set up RSA key based authentication to this server. RE: The Full Story Behind Our Recent Disaster - tigerlily - 01-13-2014 Dazz made me read this out loud to him. What. Techno-babble! RE: The Full Story Behind Our Recent Disaster - Raz - 01-13-2014 (01-13-2014, 03:36 AM)tigerlily Wrote: Dazz made me read this out loud to him. What. Techno-babble! Well SOMEONE has to know what's going on, right? RE: The Full Story Behind Our Recent Disaster - psychospacecow - 01-13-2014 Is web design just a bunch of acronyms? RE: The Full Story Behind Our Recent Disaster - Phaze - 01-13-2014 (01-13-2014, 03:08 AM)Raz Wrote: My preference is running it and changing the alias to something that is not /phpmyadmin or /pma. I would also use fail2ban to pick up any brute force attempts and IP ban clients that are caught doing so, the same system I use to ban SSH and webmail brute force attempts. Yeah I did those both (I notice the bots also look for things like "/admin" too) but I still felt too skittish about having it around. At least this way I don't need to worry about keeping it up-to-date and not relying on obscurity to protect my server. Not being a popular server that serves lots of users every month helps (01-13-2014, 05:58 AM)psychospacecow Wrote: Is web design just a bunch of acronyms? Yes, you become a professional sysadmin/web designer by memorizing all 17576 TLAs and appropriately applying them in the right order. RE: The Full Story Behind Our Recent Disaster - psychospacecow - 01-13-2014 Heck, I can't memorize the instructions to make a bowl of ramen without checking twice. I got to give you guys kudos if nothing else. RE: The Full Story Behind Our Recent Disaster - Phaze - 01-13-2014 (01-13-2014, 06:47 AM)psychospacecow Wrote: Heck, I can't memorize the instructions to make a bowl of ramen without checking twice. I got to give you guys kudos if nothing else. Google memorizes a lot of these things for us, but I guess it's something you learn by doing it enough |