Need better Upload Strategy
Trying to get my website set up, and not hang myself in the process!!
So, last night I was able to upload my website's DB from my laptop to my VPS using CyberDuck. Being new to all of this, I uploaded the .sql file to... Code:
/home/rob123/public_ftp/ That went well, but now I have this naked script floating around on my VPS! How can I delete this .sql file and be 100% certain that it is NOT lingering somewhere else on the server, and that it CANNOT be recovered?? (For those of you who have followed my threads, I am *very* worried about files and login credentials and passwords getting stored in places that they shouldn't!!!) Also, in retrospect I am thinking it wasn't so smart to upload my DB to a public folder like that. In the future, what is a better way to upload sensitive files to my VPS to maintain complete Privacy and Security?? Oh the stress of it all!!! :( Sincerely, Rob |
Quote:
Code:
locate *.sql Code:
find / -iname ".sql" http://www.hypexr.org/linux_scp_help.php |
Quote:
Quote:
Quote:
|
*Also note traditional UNIX doesn't give a rodents behind about file extensions so a SQL dump doesn't need to be named as such. Something like ".kernel32.dll" should work just fine.
|
Quote:
Which directory do I have to be in when I type those? Quote:
But for now CyberDuck is working well. Either way, my OP is asking about *after* I upload a file onto my VPS. (Even if I used SCP, I would have the same concerns...) For example, if I delete the .sql upload using cPanel, maybe it just drops the file into a "Trash Bin"? Or maybe when I uploaded my database, things were stored in some temporary cache? Or maybe my web host has the server set up so when I delete a file from my VPS, it still lingers... Follow my concerns? Sincerely, Rob ---------- Post added 02-26-15 at 01:10 PM ---------- Quote:
|
Absolutely I follow your concerns. It was just a response to your question of In the future, what is a better way to upload sensitive files to my VPS to maintain complete Privacy and Security?? As regards to the location of where to run those commands you can be anywhere in the filesystem and run those commands. I forgot to mention you may need to run updatedb first before the locate command works.
As far as deleting the file from Cpanel it will delete it and there is no trash bin when deleting files from the terminal which is basically all the Cpanel is doing. Taking a web based action and turning it into a terminal command. probably a more secure practice would be to encrypt the file and use a secure upload means which will help provide security all around. This will provide Protection for In flight and at rest. Here is a link for encrypting a file http://www.cyberciti.biz/tips/linux-...-password.html |
Quote:
And to be sure, would an uploaded file ever get stored somewhere else (e.g. Physical Server my VPS is on, Cache, etc.)?? Quote:
Quote:
Who would have thought encrypting a file could be so easy?! Is there a way for me to use GPG on my MacBook, or is it just for Linux? Sincerely, Rob |
For GPG on MAC I would look into this https://gpgtools.org.
|
Quote:
If you delete a file with rm or hitting delete in a gui - most likely it either moves it to a trash folder or just had the indicator towards it removed. The data is likely still in place until something overwrites it. Since you also do not own the server two things can happen: While the file was sitting around, the owner of the server could of copied it. Until the file is overwritten (following a delete), the file can be recovered (partially, in full or not at all) To securely delete, you should use shred or something similar. Having a gpg encrypted file works fine, until you decrypt it and use it at which point it can be copied by the server owner again. Quote:
I seem to be following you around with that message aren't I? |
Quote:
Quote:
Quote:
Quote:
What is "shred"? Quote:
At the same time, though, it would seem that if I export/backup my MySQL database to a directory outside of the Web Root, and then encrypt it, and then download it onto my MacBook in an encrypted form, that it would be resonably secure, right? Quote:
Yes, Miati my shadow!! :p Hey, I think you need to give me some credit here! While maybe you could do this by the time you were 12, I finally learned how to use SSH to log into my VPS, and then use command-line on my VPS to copy and move some files, and to upload and download some files. Small steps, I know, but I am getting there. Also, to your point, no, I have not tried SCP yet. But I will. For now, my brain needs time to get comfortable with CybeDuck. Then as I get more comfortable with all that I'm doing, I will gladly try SCP and lots of other command-line things. I am listening to my teachers on here - you guys just need to be patient. (It takes a while to unlearn a lifetime of using GUI!!) Sincerely, Rob |
I didn't read everything.
Just FYI: If you're using a VPS you definitely have an intermediate layer (the hypervisor machine that controls your VPS) which (has to) intercept everything which is read/written from/to HDD, RAM, CPU and whatever. Therefore, at least your hosting company, if they want to, they can read anything - doesn't matter if you write or not stuff or if you keep it encrypted until the last stage (CPU). Summarized: if you're using VPS for secret data, you've definitely lost. Even in the case of an owned root host, as long as you're not the one that is hosting it, you don't have ultimate control over the data that is handled (saved and/or processed) and you cannot be sure that what you see "from within your server" is really communicating directly to the HW, and without duplication or being just a plain imitation. |
Quote:
(man shred) Code:
shred - overwrite a file to hide its contents, and optionally delete it Quote:
I recall at one point deciding to learn everything I could about the terminal. My reasoning for doing so is because while gui's will likely change dramatically over short periods of time (gnome and windows are good examples) terminal commands stay the same. For a longgg time. I often read up on forum posts and guides from 2000-2005 that are still relevant. Commands have been the same for 30 years (not all, but a lot). So if you work on learning the cli now, it'll still be relevant years from now. In the tech world, that kind of assurance is rare. (just IMO) |
Quote:
Rob |
Quote:
:) Rob |
A final paranoia-boost: :)
read the "man shred" until the end. It is mentioned that overwriting files is not guaranteed to work with most of the filesystems. The reason is that in order to save time or because of other functionality offered by the filesystem (e.g. historical snapshots of data), even when you overwrite a file the data is not going to land at the same place that the original file was using => the original data will still be lying somewhere on the HDD. |
All times are GMT -5. The time now is 12:48 PM. |