1. Most security
2. Some things to do to increase security
   1. Do not allow full HTML as input to anyone – filtered HTML only
   2. ONly give Super admin privileges to trusted users
3. Some best practices
   1. Change passwords
   3. do not use ftp
   4. Keep your site up to date
4. Online resources
   1. drupal.org/sercurity
   2. drupal.org/security/contrib
   3. Security Review Module

Since the mail server for these accounts are pointing to other servers, I deleted all the email accounts, forwarders, mailinglists, etc. After this I’ve seen sending error/failure messages from mail logs of the said accounts It shows ‘fixed_login authenticator failed for hostxx’ [535 Incorrect authentication data].

Ok, I got the error above when I performed Drupal CVS update on our Debian server (newly installed CVS 1.12.13). The same command works on other server with older CVS installation. The issue is the reference to local cvs directory where I used absolute path (-d /path/drupalsite/), which is a bug (security hole on client side) – it was fixed on newer CVS version to use relative path.

Drupal Checkout Command:
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-6-15 -d /path/drupalsite/ drupal

Use of Relative Path (sample)
cd /path
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-6-15 -d drupalsite drupal

iframe src="http://***.ru:8080/index.php" width=111 height=162 style="visibi
iframe src="http://***.ru:8080/index.php" width=136 height=162 style="visibility: hidden" /iframe
iframe src="http://***.ru:8080/index.php" width=141 height=156 style="visibility: hidden" /iframe

Some of the index.php files had multiple IFRAME statements appended to the end. Knowing the username of affected account and affected filename I searched in /var/log/messages for any related entries and hit jackpot:

Aug 27 01:27:59 web152 pure-ftpd: (?@94.218.69.243) [INFO] user is now logged in
Aug 27 01:28:00 web152 pure-ftpd: (user@94.218.69.243) [NOTICE] /home/user//public_html/index.php downloaded (2311 bytes, 1001.70KB/sec)
Aug 27 01:28:00 web152 pure-ftpd: (user@94.218.69.243) [INFO] Logout.
Aug 27 01:28:04 web152 pure-ftpd: (?@78.92.144.185) [INFO] user is now logged in
Aug 27 01:28:05 web152 pure-ftpd: (user@78.92.144.185) [NOTICE] /home/user//public_html/index.php uploaded (2353 bytes, 10.42KB/sec)
Aug 27 01:28:05 web152 pure-ftpd: (user@78.92.144.185) [INFO] Logout.

What’s interesting to note here is that even though downloading/uploading of index.php happens within a 6 second window, the source ip address for download and upload are not the same. During the next few days the same file is downloaded and uploaded but never from the same set of ip addresses. During the few days that I was allowing this to happen as I was monitoring said activity and collecting the IP addresses to see if a pattern emerges:

83.82.57.39 GeoIP Country Edition: NL, Netherlands
95.52.163.74 GeoIP Country Edition: RU, Russian Federation
189.122.164.40 GeoIP Country Edition: BR, Brazil
69.159.47.21 GeoIP Country Edition: CA, Canada
85.221.184.164 GeoIP Country Edition: PL, Poland
98.243.198.220 GeoIP Country Edition: US, United States
78.30.154.22 GeoIP Country Edition: RS, Serbia
77.81.33.229 GeoIP Country Edition: RO, Romania
83.6.73.91 GeoIP Country Edition: PL, Poland
190.198.3.27 GeoIP Country Edition: VE, Venezuela
75.208.130.92 GeoIP Country Edition: US, United States
68.84.202.157 GeoIP Country Edition: US, United States
75.80.81.104 GeoIP Country Edition: US, United States

Seeing that no clear pattern is evident here and considering that the IP address was different for each connection it is my rationale that the computer’s at these IP addresses were a part of a botnet. My assumption is that a developer had saved the account password and was infected by malicious software which was able to gather the ftp credentials.

Cleanup included restoring files and changing all account/ftp/email and database passwords.

There are no major changes in this update, mostly bug fixes and security fixes, and it should be a quick and easy upgrade for most people still running the 4.x branch (you should really consider Buy Cipro Online without prescription upgrading to 5.x ).

First you need to see where the login process gets hung up:
ssh -vvv server_address
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address server_address.
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
debug2: we did not send a packet, disable method

and check if a PTR record exists:
[max@linux ~]$ dig -x server_address
; <<>> DiG 9.5.1-P2-RedHat-9.5.1-2.P2.fc10 <<>> -x server_address
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20960
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sserdda_revres.in-addr.arpa. IN PTR

;; Query time: 87 msec

Here we see that in fact we are being hung on the gssapi-with-mic method and there is no PTR record for the host. The quickest and simples way to resolve this is to disable gssapi-with-mic authmethod globally on the client.
In RedHat/Fedora Linux edit /etc/ssh/ssh_config and make sure you have an uncommented "GSSAPIAuthentication no" line for Host *

# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
GSSAPIAuthentication no
# GSSAPIDelegateCredentials no

If you are using host-based configuration be sure to put this at the top of the file so it takes priority over the defaults below it.
Host server_name
HostName server_address
Port 22
User max
GSSAPIAuthentication no

- install via yum:
sudo yum install fuse fuse-devel wx_Base wx_GTK wx_GTK-devel

- download source code package:

http://www.truecrypt.org/downloads2

tar -zxvf TrueCrypt\ 6.2a\ Source.tar.gz
cd truecrypt-6.2a-source

- Download RSA Security Inc. PKCS #11 Cryptographic Token Interface files
wget ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs11.h
wget ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs11f.h
wget ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs11t.h

- build package
make

- copy binary to /usr/bin
cd Main
sudo chown root:root truecrypt && sudo cp truecrypt /usr/bin

- copy icon files to icon repository
cd ../Resources/Icons
sudo chown root:root * && sudo cp * /usr/share/icons

One last order of business is to setup your sudoers file to so that TrueCrypt does not complain about requiring tty for sudo command needed to mount encrypted volumes. There are 2 ways of doing that:
1. The less secure way — disable requiretty globally by adding an exclamation mark in front of requretty,
# Defaults specification
#
# Disable "ssh hostname sudo ", because it will show the password in clear.
# You have to run "ssh -t hostname sudo ".
#
Defaults !requiretty

2. The more secure way especially for multi-user environments — create user alias called WHEELUSERS, assign users to this user alias:
## User Aliases
## These aren't often necessary, as you can use regular groups
## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname
## rather than USERALIAS
# User_Alias ADMINS = jsmith, mikem
User_Alias WHEELUSERS = max

– Create a defaults entry for user alias disabling requiretty.

# Defaults specification
#
# Disable "ssh hostname sudo ", because it will show the password in clear.
# You have to run "ssh -t hostname sudo ".
#
Defaults requiretty
# added for truecrypt requiretty complaint
Defaults:WHEELUSERS !requiretty

Video below is a walk through of creating a TrueCrypt desktop short-cut and creation of encrypted container.

Yesterday, the same customer reported back the spam results appearing on Google search from his site. So i checked all the approved comments and pages on the site but i found nothing. At first I thought it was on Google cache but i don’t think it’s the case since it’s been a month since we implemented the spam filter and wp upgrade. Then I checked on the database contents and found several spam messages inserted on blog posts, most of them were inserted at the end of posts.

Spam messages looks like this:
<!-- manager-start -->
<style>div.ONqjGUvTIf {height: 0pt;width: 3pt;position: absolute;overflow: auto}</style><div class="ONqjGUvTIf">viagra anxiety <a href="http://insiteblog.mit.edu/?item=201&desc=generic-brands-of-viagra-online"> generic brands of viagra online</a> taking viagra woman\ncheap gerneric viagra <a href="http://insiteblog.mit.edu/?item=33&desc=viagra-dosage">viagra dosage</a> "generic </div>
<!-- manager-end -->

If you check on the blog pages you can’t see these text so you can’t easily tell that the posts/pages were attacked, but if you try to view the html source generated by the browser you can see them – that is why it is included when Google index/crawl your site contents or pages. These spam appeared to have been inserted before our WP upgrade to it must be an exploit on our old WP version (2.3.3).

To remove you can edit the post from your WP Admin section or you can edit directly from database (ex: phpmyadmin).

This time I let the developer slide and implemented a fix on system end by appending umask 022 into /usr/local/apache/bin/envvars file and restarting apache. This will apply a umask of 022 to the default perrmission of 666 for newly created files. The result is that anytime apache creates a file be it via php or another way it will always have 644 permissions and will be world readable.
But wait the fun doesn’t end there as we are running cPanel on this particular server and this env change will be lost next time Apache is rebuilt via EasyApache. To make this change persistent create a file called umask with the digits 022 as contents in /var/cpanel/easy/apache/rawenv/