UNIXy

In a perfect world, no one would need such a hack to clean up infected files. But as it is today, so much poorly-written software finds its way into people’s hands and Websites. All it takes is to fall behind by one minor release or sometimes a rare vulnerability to find yourself in hot water.

There are many ways one can end up with iframe-infected files. The most common reason is weak FTP / user passwords! If your password is too easy to guess or is weak, someone will definitely find it and use the password against to say upload modified public files with iframes in them. Another one is vulnerabilities in software you install on your Web server. For example, if you have an outdated version of Wordpress or Joomla, someone somewhere will exploit it and find a way to upload iframes throughout your files. So be on top of your software updates and create long and secure passwords!

Here’s a way to safely clean up your index.php, index.html, default.php, and all iframe-infected files in your public_html folder. Before you run this code against any files, please make a backup of your folder(s). Also, this fix won’t prevent the attacker from injecting the  iframes again unless you patch up the software / application and reset passwords.

So, if your index.html files are infected, simply run the following command against the directory that’s infected (but mostly public_html/):

# cd /home/username/public_html && find ./ \( -iname ‘index.html’ \)|while read file; do sed -i ’s/<iframe.*<\/iframe>//g;’ ${file}; done &

If you need to patch up multiple file names at once, for example index.html and index.php, add them as such (-o -iname newfilename.ext):

# cd /home/username/public_html && find ./ \( -iname ‘index.html’ -o -iname ‘index.php’ \)|while read file; do sed -i ’s/<iframe.*<\/iframe>//g;’ ${file}; done &

That’s all folks. I hope this helps someone somewhere. Feel free to post your comments or questions.

UNIXy Break-Fix

If you attempt to store a file larger than roughly 5GB, the Amazon service will generate the following error and fail to store the file:

<Error><Code>EntityTooLarge</Code><Message>Your proposed upload exceeds the maximum allowed object size</Message><ProposedSize>6091682399</ProposedSize><MaxSizeAllowed>5368709120</MaxSizeAllowed></Error>

One way around this limitation is use the GNU/Linux command split to divide the file into several smaller chunks, which are in turn stored in Amazon’s S3. It’s important to know the order of these chunks as the original file is split. The good news is that the split command preserves the order of the chunks by adding a suffix to each chunk. Here’s an example of the split command in action. In this example, we’re splitting file outfile.tmp, which is of size 2.3GB, into chunks of 1GB each:

# du -sh outfile.tmp
2.3G    outfile.tmp

# split -a 1 -b 1073741824 outfile.tmp outfile.tmp.

# ls -alh outfile.tmp.*
-rw-r–r– 1 root root 1.0G Apr 11 09:51 outfile.tmp.a
-rw-r–r– 1 root root 1.0G Apr 11 09:51 outfile.tmp.b
-rw-r–r– 1 root root 274M Apr 11 09:51 outfile.tmp.c

As you can see, split is appending alphabetical letters to the end of the split file name. This comes handy when reassembling the file. Here’s a quick proof of concept following our earlier example:

# md5sum outfile.tmp
e1f4bbcfc2309b3c7ea48028c3f1c9e9 outfile.tmp
# cat outfile.tmp.a outfile.tmp.b outfile.tmp.c > reassembled.tmp
# md5sum reassembled.tmp
e1f4bbcfc2309b3c7ea48028c3f1c9e9 reassembled.tmp

All as planned! That’s all folks.

UNIXy Break-Fix 5368709120, Amazon, File size limitation, Limitation, S3

A customer wanted Amazon’s S3 tools installed on his Centos 5.3 server in order to backup important files off-network. The task is straight forward as it requires installing the usual Ruby interpreter, tools, and Gems. But as it turned out, cPanel appends an exclude line in /etc/yum.conf to prevent installing anything related to Ruby:

exclude=apache* bind-chroot courier* dovecot* exim* httpd* mod_ssl* mysql* nsd* perl* php* proftpd* pure-ftpd* ruby* spamassassin* squirrelmail*

I’m reluctant to un-exclude the ruby* entry as it could somehow break the cPanel production install. The next logical thing to do in this case is to scan /scripts for anything ruby related:

[/scripts]# ls -1|grep -i ruby
installruby*

Bingo! The cPanel conformant way of installing Ruby is to run /scripts/installruby. But it’s important to read cPanel’s document on RoR just in case. Here’s the URL:

http://www.cpanel.net/docs/ror/index.html

I then simply ran the script to install Ruby and configure S3 to keep the customer happy! I hope this will help someone carry on the Ruby installation.

UNIXy Crash Course Amazon, cPanel, RoR, Ruby, S3, yum