Clone HP ThinState Capture USB stick (or any other USB disk)

The ThinState USB disk is split into 2 partitions. And the second partition isn’t accessible in Windows so it was very hard to build a stick from scratch. There are a lot of Windows USB clone tools but because I had to clone the ThinState 16GB to a 8GB stick also, it was impossible to do it from my windows workstation. But when some things get more difficulty what do you do? Use Linux 🙂

The Easy way (same USB stick size or bigger):

$sudo dd if=/dev/sdb of=/dev/sdc bs=512

The “Hard” way (clone to smaller USB):

First resize the partitions with gparted to the minimum size. Then find out the last sector of the /dev/sdb2 (where sdb2 is my USB stick)

$sudo fdisk -u -l /dev/sdb


Disk /dev/sdb: 14,9 GiB, 16026435584 bytes, 31301632 sectors
Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x6a60ab98

Device     Boot   Start     End Sectors Size Id Type
/dev/sdb1 *       2048 2099199 2097152   1G b W95 FAT32
/dev/sdb2       2099200 14131199 12032000 5,8G 7 HPFS/NTFS/exFAT

Now use dd with sector 12032000 + 1.

dd if=/dev/sdb of=/home/myusername/usbimage.img count=12032001

and write the *.img file back to your new USB stick:

dd if=/home/myusername/usbimage.img of=/dev/sdb

Install chrome with Arch Linux

In Windows I like Firefox more than chrome because everything is already “Google”. But Google chrome has a nice stable and fast flash plugin built-in and so I need a chrome browser in Linux…. Because I’m testing Arch Linux (Antergos actually ) and Google don’t have arch packages I found a way to install it automatically for me with the AUR repository. $yaourt -S google-chrome More info about the yaourt (Yet AnOther User Repository Tool):

Using yaourt

You can install packages (including AUR packages) with

$ yaourt packagename


$ yaourt -Sa packagename

You can update your system including AUR packages with:

$ yaourt -Syua

Find spam script

THIS IS AN ORDINARY COPY/PAST FROM because I can’t find a source link and this is a nice article!

We have detected that this IP is NATting for, or is infected itself, with a Linux (or possibly some other Unix-like system such as FreeBSD) PHP spam mailing script. Occasionally Windows servers are infected as well.

We do not know how the malware got installed onto the machine, but we know a lot of what it does. The main thing we’ve seen it doing is sending staggering large volumes of email spam. But it can do a lot more than that, and that is the real danger.

NEW Of late some of these infections are facilitiated by a SSH Rootkit called “ebury”. See the link for more detail.

In most cases, this IP address would be that of a shared hosting environment. If you are a customer of this environment, you will almost certainly not be able to do anything about it, only the administrators of the hosting environment itself can. Please contact your administrators, and refer them to this page.

If the administrators are reluctant to do anything please try to convince them, because there is nothing you can do to fix this problem.

For the System Administrators

Your task is to find the current problem, fix it, and prevent it from happening again.

Finding the problem by network activity: Linux/FreeBSD etc

One way of finding the user that is infected and spewing spam is to use the “lsof” (list open files) utility. “lsof” is available for most versions of UNIX-like systems such as Linux as part of the official distribution, but may not be installed by default. So first, make sure you have it installed. On many systems such as Ubuntu, you can install it by:

sudo apt-get install lsof

Once lsof is installed, you can issue the following command

sudo lsof -i | grep smtp

You may see a number of lines, such as ( takes the place of your machine’s name):

sendmail- 18520 root  3u IPv4 3016693 0t0 TCP *:smtp (LISTEN)
sendmail   4401 mail 13u IPv4 8742322 0t0 TCP> (ESTABLISHED)
exim       6348 mail  3u IPv4 210565067 0t0 TCP *:smtp (LISTEN)
find       4403  foo 13u IPv4 8742322 0t0 TCP> (ESTABLISHED)

The first line, for example, is your sendmail mail software “LISTEN”ing (as userid root) for inbound email connections – this is normal. The second line is sendmail “caught” at the moment of sending an email (as userid “mail”) from your machine to a hotmail server – that is also perfectly normal. You may see similar lines with “exim” or “postfix” or “smtpd” or “qmail” instead of sendmail – all depending on what mail server you run – example – the third line is an Exim listener. The important thing that indicates that it’s normal is that the userid is “mail” or “mailman” or something like that – NOT an ordinary user.

The fourth line is a program called “find”, running under userid “foo” making a connection to an AOL server.

It’s examples like the fourth line you’re looking for – it tells you the userid of the infected user. In this case it also indicates that the infection is masquerading as the program “find”. There will often be more than one of these.

Simply killing these processes is NOT enough, because they will often restart on their own. You will need to find whether these are started by a cron job owned by that user, or, spawned through your web server, or started from a ssh login. Find and delete the program – often a PHP or Perl script. In some cases, however, the program deletes itself as soon as it starts. The “find” example above is a Linux binary executable that contains an encrypted perl script. Since this was first written, it now sometimes masquerades as “mail” or “ntpd”. Assume it could be anything. You will also need to find out how the script got installed on your machine – often through Joomla, WordPress, Cpanel or Plesk security holes, or ftp upload and secure it.

WARNING Just because you didn’t find a line like the “foo” line above doesn’t mean the machine is not infected! It just means that the machine is not sending email at the instant lsof was run. If you don’t see a line like the “foo” line, we suggest that you run the lsof command multiple times. Example:

while true
    sudo lsof -i | grep smtp
    sleep 10

Finding the problem by finding the script: Linux/FreeBSD

Try the program. It’s a relatively straight-forward Perl script that will find most of the malicious scripts that we are aware of. The beginning of the file contains instructions on how to use it. If you are not the administrator of the system, it will not work for you.

Many of these infections start themselves running, and then delete themselves from disk. Which means you won’t be able to find it. Check your ftp and SSH logs for suspicious files and logins. This is why it’s so important to prevent it happening again.

Finding the problem by network activity: Windows

The Windows environment is rather less developed for finding these things than UNIX-like systems. However, we can recommend the tcpview tool, so please see tcpview/tcpconn in our advanced section.

Finding the problem by logs: (Mostly) Linux/FreeBSD

Most of these scripts are quite good at hiding their presence. Some of them start up, and them remove the on-disk copy, so there’s nothing to see. None of them volunteer where they are, so samples don’t help. Most of these scripts bypass your mail server software, so there is nothing to see in the mail logs or queues.

However, they all do need to get on your system somehow, and that often leaves logs. If you can find those log records, often that will help you identify the infected user and find the malicious files (if they are still there).

Generally speaking, these are the ways malicious scripts get onto a system:


  • Web sites often make FTP or SSL available so their customers can upload content or log in to manage their web pages. If the customer’s computer is compromised with a keylogger, it means that the criminal can upload anything they want. You can usually see this activity in your FTP or SSL logs – look for uploads of .php or .pl files, lots of oddly named files, access from a large variety of IP addresses, etc. If you do find something like this, it’s important to get the user to change their password, and do virus scans of their computers.
  • Check your web server for large quantities of requests to the same PHP or CGI or Perl file, or POST commands, etc… This can reveal where the infection is, and often how it got there.
  • Most CMSes, in particular, Plesk, CPanel, WordPress and Joomla quite simply have severe security holes being found in them, seemingly daily, and hosted environments are often reluctant to keep up to date with their patching. You may never find a reasonable explanation of how the malicious software got there


Preventing it Happening Again


  • Make absolutely certain that ALL CMS software (Joomla, Cpanel, WordPress, Plesk etc) is kept up to date at all times. Do not let your users make any excuses for not doing so.
  • Make it impossible for such infections (and they will happen again) to spam the world by implementing the blocking of email sent direct from the machine without going through your mail server.Some of your customers may believe that they need to be allowed to do this. The best answer for them is to configure their software to relay it through the mail server software on the machine or to an external smart-host.

    For blocking: With Cpanel you can use ConfigServer Security Firewall (CSF). It’s free. CSF has the “SMTP_BLOCK” configuration option – turn it on.

    Basic Cpanel, there’s also “WHM SMTP Tweak” would should also help.

    The following is an equivalent for non-Cpanel installations – it permits local mail submission and blocks external mail submission:

    iptables -A OUTPUT -d -p tcp -m tcp --dport 25 -j ACCEPT
    iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --gid-owner mail -j ACCEPT
    iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --gid-owner mailman -j ACCEPT
    iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --uid-owner root -j ACCEPT
    iptables -A OUTPUT -p tcp -m tcp --dport 25 -j REJECT --reject-with icmp-port-unreachable

    The above permits users to send mail via a local mail server, permits local mail server software (running under userid root, or gid mail or mailman) to send email to the Internet, but prevents any ordinary user making direct SMTP connections to the Internet. You may have to adjust this for Qmail or Exim. Check which userids are used. Note that the iptables settings will probably be lost next time you reboot. The iptables commands should be installed into a system init script.

    If you’re using cPanel and APF, APF by default will wipe out iptables rules you enter manually leaving the server vulnerable. If you are using APF, you should make the above change via APF and that will take care of reissuing the commands upon reboot or reset.

  • Do you really need PHP script support? CGI support? PHP mail functions? Turn off the ones you don’t need. Some people, for example, turn off CGIs, and PHP “fsocketopen” or “exec” functions in the PHP ini files (either for the whole site, or individual environments), and manage to inhibit many infections.
  • Some of these scripts get installed into /tmp. If /tmp is a separate file system, you can stop it being used by malicious scripts by adjusting the /etc/fstab file to mount /tmp with the “noexec” and “nosuid” flags. This means that the O/S will not run programs that are in the /tmp directory nor treat them as setuid.
  • Turn off customer FTP if you don’t need it. Note that some CMS packages install FTP with anonymous FTP turned on by default. This is ALWAYS a bad idea, so make sure “anonymous login” is turned off.
  • It is necessary to force password changes on those users whose web sites have been compromised. If you can’t tell exactly which users have been compromised, it’s strongly recommended you change all passwords.


Nagios xi remove host and services

Run each of the following scripts from:
cd /usr/local/nagiosxi/scripts/
./nagiosql_delete_service.php –-config=LOC_MASShost_1
After the services have successfully been deleted, the host can be removed as well:
./nagiosql_delete_host.php –-host=LOC_MASShost_1
Once the host is removed, the new configuration can be applied and verified by running the

Zenoss reverse proxy with Pound (CentOS)

Zenoss don’t support SSL certificates out-of-the-box. If you want to use an SSL connection to your zenoss monitor server the only thing you can do is use an reverse proxy. You can use this howto to install and configure a pound reverse proxy.

Install pound with the EPEL

Install the EPEL (more info about EPEL) repository with these commands:

su -c 'rpm -Uvh'
yum update

Install pound

yum install pound

Install pound without the EPEL

rpm -ivh Pound-2.6-2.el6.x86_64.rpm

Configure Pound

I had a lot of trouble because I used a real SSL certificate immediately. The cause was I dropped the SSL cert in the wrong linux folder. Best practice is first create a selfsigned SSL, test pound and then replace the selfsigned with a real SSL certificate.

cd /etc/ssl && openssl req -x509 -newkey rsa:1024 -keyout local.server.pem -out local.server.pem -days 365 -nodes

Configure Pound

nano /etc/pound.cfg

Config file:

User "pound"
Group "pound"
Control "/var/lib/pound/pound.cfg"
Address 192.168.0.x
Port    443
Cert    "/etc/ssl/local.server.pem"
Port    8080

Now start the pound service

service pound start

Change the Zenoss config the handle the HTTPS traffic

nano /opt/zenoss/etc/zope.conf

Ad these 3 lines:


Restart zope

su - zenoss
restart zopectl

Replace the selfsigned SSL with a wildcard SSL (optional)

Create a PFX in windows. Tranfer the PFX to the Zenoss server and tranform the PFX to PEM (Linux certificate format). The command:

openssl pkcs12 -in validcertificate.pfx -out -nodes

Now change the pound cert:

nano /etc/pound.cfg
Address 192.168.0.x
Port    443
Cert    "/etc/ssl/"

Restart the service

service pound restart

Source: Enabling SSL in Zenoss 4.2 – Open Source Network Monitoring and Systems Management

Zenoss: Performance issues with too many events

When you have too many events in your zenoss environment the zenoss webinterface will be very sloooooooow. And you get all kind of errors:

  • Script don’t respond
  • Connection refused. Check zeneventserver status on deamons
  • A zenoss error has occurred

When you start top you see alot of java executables when you click on the Infrastructure zenoss button. Java sometimes take 350% CPU.

java -server -XX:+HeapDumpOnOutOfMemoryError -DZENOSS_COMMAND=zeneventserver -DZENHOME=/opt/zenoss -Djetty.home=/opt/zenoss -Djetty.logs=/opt/zenoss/log -Dlogback.configurationFile=/opt/zenoss/etc/zeneventserver/logback.xml -Xmx1024m -DZENOSS_DAEMON=y -jar /opt/zenoss/lib/jetty-start-7.5.3.v20111011.jar --config=/opt/zenoss/etc/zeneventserver/jetty/start.config --ini=/opt/zenoss/etc/zeneventserver/jetty/jetty.ini --pre=etc/zeneventserver/jetty/jetty-logging.xml

I’ve read a lot of zenoss documentation on the internet but didn’t   found a nice article to get rid of all the events. So here is an article how I fixed it.

Basic steps:

  1. Backup Zenoss
  2. Stop zenoss
  3. Create a new zeneventserver database
  4. Remove zeneventserver content
  5. Restore the zenoss backup
  6. Start zenoss
  7. Enjoy your fast zenoss 🙂

Detailed steps:

  • ssh zenoss host
  • Switch zenoss user

# su zenoss

  • Create backup:

$ /opt/zenoss/bin/zenbackup -v10

  • Stop Zenoss service

$ zenoss stop

  • edit  the zeneventserver script

nano /opt/zenoss/bin/zeneventserver-create-db

  • Search for root and add the root password


  • Run the script

$ zeneventserver-create-db --force --dbtype=mysql

  • Clear the zeneventserver folder

rm -rf $ZENHOME/var/zeneventserver/*

Now some tricky part. Zenoss change some MySQL passwords when you do a restore.  This result in a access denied for user [email protected] during a restore. There is a fix for this problem. Reset the [email protected]’localhost’ and [email protected]’%’ MySQL passwords before you do a restore.

First get the current mysql from the global.conf file (yellow). This password is the password you need for the restore.

$nano /opt/zenoss/etc/global.conf


Tip: Too check the password (encrypted). You can do the same after you change the password:

$ mysql -uroot -p
mysql> select * from mysql.user;


Now reset the password

SET PASSWORD FOR 'zenoss'@'localhost' = PASSWORD('BEagPxxxxxxxxxxxxxxx');
SET PASSWORD FOR 'zenoss'@'%' = PASSWORD('BEagPxxxxxxxxxxxxxxx');

When you check the permissions now you see another encryption:

$ mysql -uroot -p
mysql> select * from mysql.user;

(I don’t have an image example because this is an production enviroment)

Optional: To check the zenoss user permissions:

mysql> SELECT user, host, db, select_priv, insert_priv, grant_priv FROM mysql.db;


Optional: When you still have errors or the above rights ain’t good try these two MySQL scripts:

mysql> CREATE USER 'zenoss'@'%' IDENTIFIED BY 'some_pass';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'zenoss'@'localhost'

mysql> CREATE USER 'zenoss'@'%' IDENTIFIED BY 'some_pass';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'zenoss'@'localhost'

Ok, now everting is set do a restore. The -v stands for verbose and with the no-eventsdb you don’t restore all the events. That’s exactly what we want

zenrestore --file=/opt/zenoss/backups/zenbackup_2014013 -v --no-eventsdb

Now start zenoss

$zenoss start

That’s it.  Enjoy the performance and set some parameters that your events ain’t that big any more in the future.


IPtables howto

I copy/paste this howto from the debian wiki @ and add this to my blog to for fast finding the best iptables article on the net.

Iptables provides packet filtering, network address translation (NAT) and other packet mangling.

Two of the most common uses of iptables is to provide firewall support and NAT.

Configuring iptables manually is challenging for the uninitiated. Fortunately, there are many configuration tools (wizards) available to assist: e.g., fwbuilder, bastille, ferm (wiki page), ufw (Uncomplicated Firewall, from Ubuntu).

Viewing current configuration

See what rules are already configured. Issue this command:

 iptables -L

The output will be similar to this:

 Chain INPUT (policy ACCEPT)
 target     prot opt source               destination

 Chain FORWARD (policy ACCEPT)
 target     prot opt source               destination

 Chain OUTPUT (policy ACCEPT)
 target     prot opt source               destination

This allows anyone access to anything from anywhere.

Storing iptables rules in a file

Note: there is a package designed to help with this: iptables-persistent

Let’s tighten that up a bit by creating a test iptables file:

 nano /etc/iptables.test.rules

In this file enter some basic rules:


# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d -j REJECT

# Accepts all established inbound connections

# Allows all outbound traffic
# You could modify this to only allow certain traffic

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allows SSH connections 
-A INPUT -p tcp -m state --state NEW --dport 30000 -j ACCEPT

# Now you should read up on iptables rules and consider whether ssh access 
# for everyone is really desired. Most likely you will only allow access from certain IPs.

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls (access via 'dmesg' command)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Reject all other inbound - default deny unless explicitly allowed policy:


That may look complicated, but look at each section at a time. You will see that it simply shuts all ports except the ones we have allowed – which in this case are ports 80 and 443 (the standard web browser ports) and the SSH port defined earlier.

Activate these new rules:

 iptables-restore < /etc/iptables.test.rules

And see the difference:

 iptables -L

Now the output tells us that only the ports defined above are open. All the others are closed.

Once you are happy, save the new rules to the master iptables file:

 iptables-save > /etc/iptables.up.rules

To make sure the iptables rules are started on a reboot we’ll create a new file:

 nano /etc/network/if-pre-up.d/iptables

or in the the if-up.d if the if-pre-up.d not work

nano /etc/network/if-up.d/iptables

Add these lines to it:

 /sbin/iptables-restore < /etc/iptables.up.rules

The file needs to be executable so change the permissions:

 chmod +x /etc/network/if-pre-up.d/iptables

Show spam script on linux webserver

Sometimes a website on a shared server is compromised by a hacker. Most of the time they use the website to spam the WWW around. It can be hard to find the specific script who is responsible for the spam. Here I will describe a method you can use to find and eliminate the script.

First stop postfix to stop the mail flood

# service stop postfix

Now get the mailque and write down the message id (yellow)

# mailq


Get the message header

# postcat -vq A9CC9182699 |more

message header

Now see the yellow text above. You have find the culprit. Now find the file location:

# find /var/www/web/ -name *addwp.php*

Eliminate the process and patch the website.

Delete the queue (USE THIS WITH CAUTION!!!!)

# postsuper -d ALL

And start postfix

# service start postfix

To find and kill a spamming perl script try this:

Find the process:

lsof -i :25
readlink -f /proc/{PID of process}/exe
kill PID

Check and delete the (sendmail) QUEUE:

cd /var/spool/mqueue/
nano queue file
rm -f *

It can be very difficult to find a specific perl spam script because the path is not always visible. To find the script do a locate and isolate/rename the files.

locate *.pl |grep /var/www/

For more commands see my blog article:

I found another nice tool to find suspicious scripts:

Zenoss Backups

Create a zenoss user cron

sudo crontab -u zenoss -e

Use this lines to backup every day 10 AM.

30 10 * * * /opt/zenoss/bin/zenbackup -v10

Note: When I not put the variables to the cron I get this error:
ERROR: $ZENHOME is not set.
This is usually caused by executing this command as root rather than as the zenoss user. Either define $ZENHOME or run this command as a different user.

Because I can’t find a nice solution on the internet I fix it to add the SET lines to the cron.

Create a cleanup job

sudo crontab -e

Use this line to cleanup the backups every sunday 12 AM

00 12 * * 7 root /usr/bin/find /opt/zenoss/backups -mtime +30 -type f -exec rm \{\} \;