You can normally do this through the gui tool, but I figured it's still fairly easy to do it with the command line tool. In this case, I want to join my machine to the domain and use Active Directory for authentication and user information. You'll likely want to back up your authentication config files (just backup /etc to be safe, unless you know exactly which files you need) before you start. Do this at your own risk.
system-config-authentication --smbrealm=my_ads_fqdn \
--winbindjoin=domain_admin_username --smbsecurity=ads \
--enablewinbindusedefaultdomain --enablekrb5 --enablewinbind \
--update
If you want the users to have a default shell, run system-config-authentication again:
system-config-authentication --winbindtemplateshell=/bin/bash --update
Conversely, you could have added the "--winbindtemplateshell=/bin/bash" to the first command above.
Thursday, May 26, 2011
Friday, May 20, 2011
Qakbot Outbreak and Removal
I recently had to deal with a large Qakbot worm outbreak. Qakbot's an information gathering nuisance. It appeared that there were three different variants of the worm. The problem was that it spread through the desktops and the servers through domain admins. This is likely because of domain admins logging into infected workstations.
Unfortunately, the centralized AV was not fully deployed - and was sometimes out of date. The problem was magnified by the fact that the company is multi-site and fairly wide open, subnet wise.
Apparently, Qakbot spreads through CIFS shares. It likes to push itself through the administrative shares and place executables to be run into the All Users directory. It then creates registry entries to start itself upon login. It does annoying things like changing permissions on the AV program directories such that updates won't work. It then uses the credentials of the user to attack the administrative shares and (likely) remote registry service of other machines. This can be bad if you happen to be a domain admin, Anyway, the virus doesn't seem to work correctly on Windows 7 or 2008 for some reason.
The biggest problem removing it was that we were not able to isolate segments of the network, and by logging on, you'd simply activate it, if the executables had already been placed.
I figured out a simple way to clean up a machine remotely (do this at your own risk, of course. You may damage your system if you are not careful.):
1. First, check out the administrative share of the machine:
\\c$\documents and settings\all users\application data\microsoft
The Qakbot worm creates a randomly named directory. Let's pretend our folder name was "gvcajscwxoq." I can't tell you exactly what it'll be called, but the name will be rather random and should have only one exe, two dlls, and maybe some .tmp or .dmp files. So, we'd have a folder called:
\\c$\documents and settings\all users\application data\microsoft\gvcajscwxoq
There will be an executable and two DLLs witht the same name as the folder "gvcajscwxoq." There may be a few other tmp files. What you need to do is delete or rename the files to a different extension - like .vir.
2. rename gvcajscwxoq.exe to gvcajscwxoq.vir.
3. rename all the DLLs in that folder called "gvcajscwxoq" to another name.
That works well enough if the virus isn't active on the machine. If it is, you'll need to kill the process remotely before logging in. I found a useful freeware commercial tool called Desktop Central:
Desktop Central
(note, I'm in no way associated with that company. I just found the tool to be useful.)
4. Anyway, after installing the free edition on your local work station, launch the tool and launch "remote task manager"
Provided it can connect to the infected machine, you should find the rogue process running as the same random name of the folder you attempted to rename above. End that process (make sure it's the same random name!) Wait about 20-30 seconds and then try to rename the remaining files in the application data\microsoft folder. You should be able to. You probably can't rename the bad folder, yet.
5. Now, you can log into the box. Run msconfig and look under the startup tab very carefully. The worm likes to append itself to a legitimate application's startup. For instance, if you had a network management suite gui that started up, like the Broadcom control suite, it might modify that entry to launch itself and then the Broadcom suite. You should find one entry with the gvcajscwxoq.exe file listed. I'd recommend removing that portion or just disabling the service. Be careful, you'll be disabling a program that normally starts for all users.
6. Now that you've removed the threat, install/update your anti-virus. You may need to modify permissions for your AV software as Qakbot may have changed things. Check out your anti-virus vendor's help section; they may have a tool to change the permissions.
I'd also recommend that all domain admins check out the administrative shares of boxes before logging into them. Remember from above:
For Windows 2000-2003, XP, look in
\\servername\c$\documents and settings\all users\application data\microsoft
For Windows 2008, Vista, and Windows 7, try looking in c:\programdata\microsoft
If you see a randomly named folder with an exe and two dlls in it, you'll need to cleanup the server before logging in.
Unfortunately, the centralized AV was not fully deployed - and was sometimes out of date. The problem was magnified by the fact that the company is multi-site and fairly wide open, subnet wise.
Apparently, Qakbot spreads through CIFS shares. It likes to push itself through the administrative shares and place executables to be run into the All Users directory. It then creates registry entries to start itself upon login. It does annoying things like changing permissions on the AV program directories such that updates won't work. It then uses the credentials of the user to attack the administrative shares and (likely) remote registry service of other machines. This can be bad if you happen to be a domain admin, Anyway, the virus doesn't seem to work correctly on Windows 7 or 2008 for some reason.
The biggest problem removing it was that we were not able to isolate segments of the network, and by logging on, you'd simply activate it, if the executables had already been placed.
I figured out a simple way to clean up a machine remotely (do this at your own risk, of course. You may damage your system if you are not careful.):
\\c$\documents and settings\all users\application data\microsoft
The Qakbot worm creates a randomly named directory. Let's pretend our folder name was "gvcajscwxoq." I can't tell you exactly what it'll be called, but the name will be rather random and should have only one exe, two dlls, and maybe some .tmp or .dmp files. So, we'd have a folder called:
\\c$\documents and settings\all users\application data\microsoft\gvcajscwxoq
There will be an executable and two DLLs witht the same name as the folder "gvcajscwxoq." There may be a few other tmp files. What you need to do is delete or rename the files to a different extension - like .vir.
That works well enough if the virus isn't active on the machine. If it is, you'll need to kill the process remotely before logging in. I found a useful freeware commercial tool called Desktop Central:
Desktop Central
(note, I'm in no way associated with that company. I just found the tool to be useful.)
Provided it can connect to the infected machine, you should find the rogue process running as the same random name of the folder you attempted to rename above. End that process (make sure it's the same random name!) Wait about 20-30 seconds and then try to rename the remaining files in the application data\microsoft folder. You should be able to. You probably can't rename the bad folder, yet.
I'd also recommend that all domain admins check out the administrative shares of boxes before logging into them. Remember from above:
For Windows 2000-2003, XP, look in
\\servername\c$\documents and settings\all users\application data\microsoft
For Windows 2008, Vista, and Windows 7, try looking in c:\programdata\microsoft
If you see a randomly named folder with an exe and two dlls in it, you'll need to cleanup the server before logging in.
More on Racktables...
I figured that I should say some more about Racktables. It's very useful. You can use it to manage:
IPv4 and IPv6 inventory - ditch that spreadsheet!
Server network interface IP configuration documentation, including what port maps to what switch port
Virtual host to hypervisor relationships
VLAN inventory - again, ditch that spreadsheet.
Server maintenance contracts - store a PDF copy as part of a server object
And quite a bit more.
In just a few weeks, I've found it very useful. It's definitely worth the minimal set up time.
In just a few weeks, I've found it very useful. It's definitely worth the minimal set up time.
Wednesday, May 11, 2011
Racktables on CentOS 5.6
I find Racktables to be a very useful tool. Because it requires newer versions of PHP, it's a bit of a hassle to get it running on CentOS 5.x. Here are the steps:
1. Get the CentOS testing repo (for new versions of PHP.)
cd /etc/yum.repos.d
# now we enable the new repo - at least for long enough to satisfy the dependencies
sed -i CentOS-Testing.repo -e 's/enabled=0/enabled=1/g'
2. update PHP to 5.3.x
yum -y install php53 (you may need to remove php-common, if it's installed)
2b. optional: lock down MySQL:
sudo /usr/bin/mysql_secure_installation
You'll want to assign a root password as well as delete anonymous users and disallow remote root logins.
3. Create the database and database user:
mysql -u root -p
create database racktables;
grant all on racktables.* to racktablesuser;
grant all on racktables.* to racktablesuser@localhost;
set password for racktablesuser@localhost=password('your_super_password');
flush privileges;
4. untar the racktables source and do a make && make install.
5. create entries for this host in DNS - A records and/or CNAMEs. For example, create an A record called racktables.yourdomain.local.
5b. Create a configuration entry in apache. Edit /etc/httpd/conf.d/racktables.conf:
ServerName racktables.your_domain.local
DocumentRoot /usr/local/share/RackTables/wwwroot/
Obviously, this is not running over SSL. It's not a bad idea to run Racktables over HTTPS.
5c. Restart apache (sudo /sbin/service httpd restart)
6. Connect to your host. You'll probably get this error message:
Database connection parameters are read from /usr/local/share/RackTables/wwwroot/inc/secret.php file, which cannot be found. You probably need to complete the installation procedure by following this link.
7. Step through the links till you get to the dependency page (step 2 of 6.)
8. You'll see that you are missing numerous dependencies. Go ahead and fix the dependencies:
sudo yum -y install php-mbstring
sudo yum -y install php-gd
sudo yum -y install php-snmp
sudo yum -y install php-pdo
sudo yum -y install php-mysql
9. In order to get the unicode support in php pcre
sudo yum update pcre
10. We'll leave pcntl as is for now. In the next step, you'll see a warning about the secret.php file. To fix it:
sudo touch '/usr/local/share/RackTables/wwwroot/inc/secret.php'; sudo chmod 666 '/usr/local/share/RackTables/wwwroot/inc/secret.php'
(you'll need to either configure SELinux to allow access to that file or disable SELinux altogether.
11. Enter the db name and db username and password from earlier.
12. Set an administrator password in the next step.
You should be all set.
Saturday, May 7, 2011
iSCSI Targets on Solaris 10 U9
Assuming we have a pool named pool1 and we wish to create a target for a client host named server1. Our ZFS target server has two interfaces; the interface we want to use for iSCSI has the IP address 192.168.78.20.
First, create a new volume for the iSCSI target:
zfs create -V 100g pool1/vols/iscsi1
We can share it out (this could have been done during the creation phase, of course)
zfs set shareiscsi=on pool1/vols/iscsi1
Let's bind this volume so that it's only available on the iSCSI interface:
iscsitadm create tpgt 1
iscsitadm modify tpgt -i 192.168.78.20
iscsitadm modify target -p 1 pool1/vols/iscsi1
We should set up some sort of authentication. At a minimum, a target CHAP entry.
Go ahead and create the client/initiator entry:
iscsitadm create initiator --iqn iqn.1991-05.com.microsoft:server1.mydomain.com server1
assign the CHAP username for server1 (we're calling it server1user):
iscsitadm modify initiator --chap-name server1user server1
set a CHAP password for that client:
iscsitadm modify initiator --chap-secret server1
(it must be at least 12 characters long and no more than 16 characters long.)
Bind the ACL to the target:
iscsitadm modify target --acl server1 pool1/vols/iscsi1
Now all you need to do is to connect to it from the iSCSI initiator on server1. Set the server interface IP as the portal (i.e., 192.168.78.20), look at the targets, and authenticate via CHAP using server1user as the username and whatever password you specified above as the password.
First, create a new volume for the iSCSI target:
zfs create -V 100g pool1/vols/iscsi1
We can share it out (this could have been done during the creation phase, of course)
zfs set shareiscsi=on pool1/vols/iscsi1
Let's bind this volume so that it's only available on the iSCSI interface:
iscsitadm create tpgt 1
iscsitadm modify tpgt -i 192.168.78.20
iscsitadm modify target -p 1 pool1/vols/iscsi1
We should set up some sort of authentication. At a minimum, a target CHAP entry.
Go ahead and create the client/initiator entry:
iscsitadm create initiator --iqn iqn.1991-05.com.microsoft:server1.mydomain.com server1
assign the CHAP username for server1 (we're calling it server1user):
iscsitadm modify initiator --chap-name server1user server1
set a CHAP password for that client:
iscsitadm modify initiator --chap-secret server1
(it must be at least 12 characters long and no more than 16 characters long.)
Bind the ACL to the target:
iscsitadm modify target --acl server1 pool1/vols/iscsi1
Now all you need to do is to connect to it from the iSCSI initiator on server1. Set the server interface IP as the portal (i.e., 192.168.78.20), look at the targets, and authenticate via CHAP using server1user as the username and whatever password you specified above as the password.
Subscribe to:
Posts (Atom)