Security – Page 2 – closingtags </>
Categories
Linux Security Server

Converting Privileged LXC Containers to Unprivileged

Not long ago, I was looking through my container configurations in the Proxmox GUI and noticed that one very important container had been running as privileged. I must’ve forgotten to click the “Unprivileged” checkbox when I was creating it. For security sake, I try making all of my containers unprivileged. It makes things like sharing files between the host and containers slightly more difficult, but if that particular container is ever compromised by someone with malicious intent, it makes it much more difficult for that malicious actor to compromise the entire host. See the Proxmox documentation on unprivileged containers for more information.
To make this particular container more secure, and to avoid having to set everything up again, I thought it might be easier to simply try and converting it to an unprivileged container. While you can’t just shut the container down, go into the GUI and mark it unprivileged, you can create a backup and make a new container from that backup unprivileged. If you clicked the link to the Proxmox documentation from earlier, you’d see just what I was talking about. In it, you can see under the Creation section, that all you need to do is run
pct restore 1234 var/lib/vz/dump/vzdump-lxc-1234-2016_03_02-02_31_03.tar.gz
-ignore-unpack-errors 1 -unprivileged 
where the first 1234 is your new container ID, and the second (in the backup file) is the old container ID. You can overwrite the previous container with the restore, but it might be a safer bet to just create a new container and then shutdown your old one.
You can also do this through the GUI by navigating to the backups of your container, selecting your backup, and clicking restore. However, when I ran it through the GUI, it gave errors and destroyed the container. Thank goodness for backups, right? Even when running the above command in the CLI, I received errors. Fortunately, they were easy enough to troubleshoot. If you see something like
400 Parameter verification failed.
storage: storage ‘local’ does not support container directories
then you’ll need to specify your storage. This is easy enough to get around by providing the –storage option and selecting the proper storage location. In my case, the entire command looked like
pct restore 1234 /var/lib/vz/dump/vzdump-lxc-1234-2018_05_25-10_29_59.tar.lzo
-ignore-unpack-errors 1 -unprivileged –storage local-zfs.
With that done, you can start up your new container and use it the same way you were before, but this time, it’s a little more secure.

Categories
Linux Security Server

Storj-CLI Update + Shortcuts

I hate typing the same commands over and over into the terminal. I hate it so much that every time I have CLI deja-vu, the first thing I say to myself is “How can I automate this?” Usually, it’s as simple as adding a quick alias to my `~/.bash_aliases` file but this time I did that along with throwing together a quick bash script. If you ever install the storjshare client on an Ubuntu or Debian based machine, putting these aliases and script on your system might help you with a few of the commands I found myself typing frequently.
Storjshare Aliases

https://gist.github.com/Dilden/ec379a64532ec5e1d36586fd35ed0101

If these helped you out at all, let me know by starring the repo or leaving a comment here.
UPDATE!Something that bothered me about the storjshare daemon was that it didn’t startup when the system did. Depending on how you look at this, it can be a good thing. Fewer system resources consumed during startup is nice, but if it’s the only thing you’re hosting on your machine and you’re striving for up-time, then it’s a necessity. To get around this quickly and easily, you can update the cron jobs to fire on startup.
@reboot su – YOUR_STORJ_USER_HERE -c “storjshare daemon && storjshare start -c /home/YOUR_STORJ_USER_HERE/.config/storjshare/configs/YOUR_STORJ_NODE_ID.json”
This will likely need to be put in your root user’s cron which you can gain access to with the command `crontab -e` (while logged in as root).

Categories
Linux Security Server WordPress

WordPress Backup Bash Script

I threw together a simple bash script to be run via cron jobs that will backup an entire WordPress site. Technically, it will work for a lot more than that assuming the site you’re backing up has a single directory to be backed up and a MySQL/MariaDB database. It’s a fairly simple script and it is easy to expand to work with multiple directories. Just take a look at the source for yourself!
To use, fill in the information at the top of the script (site name, database name, database user + password, path to site, and backup path), upload the script to `/etc/cron.daily/` on your server and you’ll be good to go!
Take note of the `SITE_PATH` variable at the top of the script. For whatever reason, there needs to be a space between the first “/” and the rest of the path.

Categories
PHP Security

I’m back!

After deciding not to renew hosting with my previous provider and that hosting expiring in the middle of a very turbulent time for me, closingtags.com is back online!

Categories
PHP Security WordPress Yii2

Deployments w/Capistrano

For so long, developers have been moving code with FTP/SFTP. It’s time consuming, and comes with its faults. One false click, and you could easily overwrite a file that you haven’t downloaded yet. And that’s not good. Especially if there’s no version control in place. I know; it’s 2015 and if that happens to you, you kind of deserve it. But the fact of the matter is that a lot of developers at smaller organizations are still doing things this way.
This is where Capistrano comes in. Capistrano is a Ruby gem that makes deployment a one command process. Seriously.
cap production deploy
That command is all you need to push code to your production server.
Capistrano lets you use a git repo to launch your application. Instead of opening up FileZilla, finding a directory, and uploading everything manually, Capistrano will go to your repository, and move that code via a secured connection (SSH) to your server. The Capistrano website has everything you need to get setup so I won’t go into that here, but I will drop in my configuration to show how I’m using it to deploy a Yii2 app.
config/deploy.rb
set :application, ‘PROJECT_NAME_HERE’
set :repo_url, ‘https://GIT_REPO_HERE.git’

# Default deploy_to directory is /var/www/my_app_name
set :deploy_to, ‘DIR_TO_DEPLOY_TO_ON_SERVER’

# Default value for linked_dirs is []
set :linked_dirs, fetch(:linked_dirs, []).push(‘web/uploads’, ‘vendor’, ‘runtime’)

# Default value for default_env is {}
# set :default_env, { path: “/opt/ruby/bin:$PATH” }

# Default value for keep_releases is 5
# set :keep_releases, 5

Rake::Task[”deploy:symlink:linked_dirs”].clear
Rake::Task[”deploy:symlink:linked_files”].clear
Rake::Task[”deploy:symlink:release”].clear

namespace :deploy do

after :restart, :clear_cache do
on roles(:app), in: :groups, limit: 3, wait: 10 do
# # Here we can do anything such as:
# within release_path do
# execute :rake, ‘cache:clear’
# end
end
end

namespace :symlink do
desc ‘Symlink release to current’
task :release do
on release_roles :all do
tmp_current_path = release_path.parent.join(current_path.basename)
execute :ln, ‘-s’, release_path.relative_path_from(current_path.dirname), tmp_current_path
execute :mv, tmp_current_path, current_path.parent
end
end

desc ‘Symlink files and directories from shared to release’
task :shared do
invoke ‘deploy:symlink:linked_files’
invoke ‘deploy:symlink:linked_dirs’
end

desc ‘Symlink linked directories’
task :linked_dirs do
next unless any? :linked_dirs
on release_roles :all do
execute :mkdir, ‘-p’, linked_dir_parents(release_path)

fetch(:linked_dirs).each do |dir|
target = release_path.join(dir)
source = shared_path.join(dir)
unless test “[ -L #{target} ]”
if test “[ -d #{target} ]”
execute :rm, ‘-rf’, target
end
execute :ln, ‘-s’, source.relative_path_from(target.dirname), target
end
end
end
end

desc ‘Symlink linked files’
task :linked_files do
next unless any? :linked_files
on release_roles :all do
execute :mkdir, ‘-p’, linked_file_dirs(release_path)

fetch(:linked_files).each do |file|
target = release_path.join(file)
source = shared_path.join(file)
unless test “[ -L #{target} ]”
if test “[ -f #{target} ]”
execute :rm, target
end
execute :ln, ‘-s’, source.relative_path_from(target.dirname), target
end
end
end
end
end

task :composer do
on roles(:app) do
within release_path do
execute “cd #{release_path} &amp;&amp; php-latest ~/composer.phar install”
end
end
end

task :setup do
on roles(:app) do
within release_path do
execute “cd #{release_path} &amp;&amp; php-latest yii.php setup”
# execute :php, “yii setup”
end
end
end

after :updated, “deploy:composer”
after :updated, “deploy:setup”

end
config/deploy/production.rb
server ‘closingtags.com’,
roles: %w{app},
branch: ‘master’,
ssh_options: {
user: ‘SSH_USER_NAME_HERE’,
keys: %w(~/.ssh/id_rsa),
# forward_agent: false,
auth_methods: %w(publickey)
# password: ‘please use keys’
}
Now, I’m no Ruby developer, so if my code could be cleaned up, which I know it can be, let me know. But let’s take a quick walk through with what we have here. Firstly, anything starting with # shows a commented line. I’ve removed most of mine, but left a few I thought might be helpful. You’ll notice the first three uncommented lines of the deployment file are just setting some variables for the configuration.
The fourth line, set :linked_dirs, is doing something really interesting. When Capistrano deploys my app, it creates a git repo on the server and will keep the last 5 versions. The linked_dirs variable is basically creating a symlink on my server, so that it doesn’t recreate those files every time. This was necessary for my uploads directory, which needs to be have the same location each time I deploy. If I created a new directory each time I deployed, users would get 404’d every time I deployed.
The next few segments actually contain a description so there isn’t much to say about those, other than they were necessary to deploy to MediaTemple’s GridServer. Most of the time, this stuff isn’t necessary, but I had a special case with our server.
task :composer installs all of my dependencies and task :setup runs a custom yii2 command that upgrades the database, if necessary.
Now like I said earlier, I’m using this to deploy a Yii2 app, but really, it could be used for anything. It’s mostly used to deploy Ruby applications, but there really isn’t anything stopping you from deploying something built WordPress or Laravel. If you have some suggestions on how I could streamline my process, let me know!

Categories
PHP Security WordPress

Status Update + wp-class.php backdoor

It’s been a very long time since I’ve written anything, and I’m really sorry about that. This summer has been crazy, but I know that’s not an excuse. That being said, I have a new job now, so I’m not putting in as much time with WordPress as I’d like to. I’m working with a different framework (Yii2, still PHP) now and WordPress development may become something more like a hobby for me. I still have plans to develop some more plugins, but being realistic, those things might not happen until the cold winter falls and I’m stuck indoors for 9+ months. Such is life in the tundra of ND. Also, security and penetration testing have fallen on my radar so there may be more blog posts about things like that. Actually, this is a great post to lead into that, so let’s talk about security.
A long while back, I found another compromised site, and it being my job to clean it up, I had to do some dirty work by getting into a few files. While I was doing that, I found this little guy. It was so obfuscated that I almost just deleted it and left it at that, but I’m glad I didn’t. I cleaned it up, and made it legible so take a look at it.
This file, is pretty cool actually. It’s basically a backdoor to read, write, and delete anything on the file system. It has a file system browser built in, plus a few tools to execute code, and some others to analyze the system it’s on. Basically, once somebody gets this onto your system, they’re making their life easier to make your life harder. All of the things this file does, could be done with other tools, but how great is it to have one file do it all on the target system? Plus, if you’ve got a bot crawling known exploits on systems anyways, it’d be even easier to just have it drop this little devil on the target for you so you can come back later. It also helps that it was called wp-class.php (not a real WordPress file), because nobody would think to delete something that sounds that important.
Jesse, over at blackdoorsec.blogspot.com, did a nice write up on this file, and posted some comments on it line by line. I definitely recommend taking a look at his post. He’s much more thorough than I was here.