Add comments to IPTables firewall rules

Instead of just documenting the IPTables configuration file eg: /etc/sysconfig/iptables with comments (#’s) you can also input comments as part of the ruleset itself. So when you perform iptables -L -v -n you get the following output:

root@server070:[~]: iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  64M 4727M ACCEPT     all  --  *      *             state RELATED,ESTABLISHED
    5   474 ACCEPT     icmp --  *      *  
 202K   27M ACCEPT     all  --  lo     *  
   16   880 ACCEPT     tcp  --  *      *             state NEW tcp dpt:22
 137M   38G ACCEPT     udp  --  *      *             udp dpt:514 /* Syslog traffic */
   28  1664 ACCEPT     tcp  --  *      *             tcp dpt:514 /* Syslog traffic */
41067 2050K ACCEPT     tcp  --  *      *             tcp dpt:9997 /* Universal Forwarder traffic */
    0     0 ACCEPT     tcp  --  *      *             tcp dpt:8089 /* Splunk SSL traffic */
   47  2564 ACCEPT     tcp  --  *      *             tcp dpt:8000 /* Splunk web interface */
14135 1313K LOG        all  --  *      *             limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables denied: '
 218K   21M REJECT     all  --  *      *             reject-with icmp-host-prohibited

All that you need to do use the following example in your configuration file:

root@server070:[~]: cat /etc/sysconfig/iptables
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --dport 514 -m comment --comment "Syslog traffic" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 514 -m comment --comment "Syslog traffic" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9997 -m comment --comment "Universal Forwarder traffic" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8089 -m comment --comment "Splunk SSL traffic" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8000 -m comment --comment "Splunk web interface" -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Happy commenting!

Configure UTM 220 LCD panel under Linux

I had the task of rebuilding an Astaro UTM 220 with CentOS and the LCD panel looked so lifeless, So I decided to restore it to some version of functional! From my research I can see that the display is LCM-162 and utilises the lcd driver HD44780.

In a nut shell here is what I did:

  • Download LCDproc (
  • Modify: lcdproc-0.5.6/server/drivers/hd44780-ext8bit.c


#define RS  STRB
#define RW  LF
#define EN1 INIT 


#define RS  SEL
#define RW  INIT
#define EN1 LF 
  • compile it with option: ‘./configure –enable-drivers=hd44780′
  • make && make install
  • Modify: /usr/local/etc/LCDd.conf


  • Line 53: Driver=hd44780
  • Line 502: ConnectionType=8bit
  • Line 509: Device=/dev/parport0
  • Line 544: Size=16×2

Test it:

LCDd -f -r 4 -c /usr/local/etc/LCDd.conf &
lcdproc -f -s localhost -p 13666 C M L

If it works its just a matter of copying: scripts/init-LCDd.rpm and scripts/init-lcdproc.rpm to /etc/init.d and configuring chkconfig properly.

Hopefully that helps.

SSH Forced commands from Web Page

Are you a paranoid nerd, who’s business requirements are very strict about IT security? No, well you may as well stop reading here.

Perhaps you have a business requirement to perform some random function on a server that only allows SSH access, but the rest of the business requires simple press button access to perform those functions?

Well with SSH force command wrappers, SSH keys and PHP you too can have simple click button access for the rest of the business!

Basically with a Linux apache server with PHP use the following code:
[Read More…]

Squid ICAP Syntax with F-Secure Internet Gate Keeper (IGK)

*** UPDATE September 2015 - This article has been updated with the correct syntax and confirmed working on Squid 3.3.8 ***

The doco for IGK is some what lacking for the ICAP settings but it does mention ” Refer to the documentation of the proxy for information on how to set it up”. That’s not very helpful so I contacted F-Secure technical support and asked them. This is the reply:

You will need to add these lines to Squid config file:

icap_enable on
icap_send_client_ip on
icap_service service_req reqmod_precache bypass=1 icap://[IP address of IGK]:1344/request
adaptation_access service_req allow all
icap_service service_resp respmod_precache bypass=0 icap://[IP address of IGK]:1344/response
adaptation_access service_resp allow all

Unfortunately that still doesn’t work for some unknown reason and I am only getting the error:


I don’t have anymore time to spend on this, I guess I’ll just use the F-Secure HTTP proxy as a parent proxy for squid.

Import signed certificate for VDI-in-a-Box - Java keystore

You’d think it would be easy to perform what should be a common task. Purchase a SSL certificate from an Issuer and install it your Citrix VDI-in-a-Box server. As anyone who has performed the same with Apache it is a fairly trivial task.
But because ViaB is some sort of black magic it is rather difficult, well that and the fact the java ‘keytool’ is fu%#*ing pain the a$$!

A lot of documentation reports that ‘The cerificate must be installed to the same keystore that was used to generate the CSR. If you try to install it to a different keystore it will not work.’
Even the stupid Citrix documentation doesn’t even tell you how to do it. What they do tell you to do is to generate the CSR on ViaB server and then get that signed! This doesn’t help the 99.99% of the world who have corporate certificates created another way!

But fear not - IT CAN BE DONE! It took me fair too long to work it out but no you can do it with ease! Please follow the directions to the letter. Please type the passwords on the command line, omitting them seems to make it not work. In my example I used DigiCert who supply four certificates in the chain of trust. If you received less that OK but make sure the order you do things in (PEM generation) is the same!

# Import all the damn certs in the chain into a PEM file:

cat >> all-certs.pem
cat DigiCertCA.crt >> all-certs.pem 
cat DigiCertCA2.crt >> all-certs.pem
cat TrustedRoot.crt >> all-certs.pem

# Import the private key and create a PKCS12 file (that contains the full chain + private key)
openssl pkcs12 -export -in all-certs.pem -inkey -out all-certs.p12

# Now create a java keystore based on the PKCS12 file

keytool -importkeystore -deststorepass PASSWORD-GOES-HERE -destkeystore all-certs.jks \
-srckeystore all-certs.p12 -srcstoretype PKCS12 -srcstorepass PASSWORD-GOES-HERE

# Check the output (although you can't really tell if it's going to work until you try it...)
keytool -list -keystore all-certs.jks 

# Output should be similar to: 
Enter keystore password:                                                                                                                                     
Keystore type: JKS                                                                                                                                           
Keystore provider: SUN                                                                                                                                       
Your keystore contains 1 entry                                                                                                                               
1, 15-Jun-2013, PrivateKeyEntry,                                                                                                                             
Certificate fingerprint (SHA1): xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx 

# Check the full certificate chain
keytool -list -v -keystore all-certs.jks 

# (DigiCert supplies four certifcates in this example)
# Check the order, it should be your, the Issuing CA, Issuing CA's Root, TrustedRoot Cert.

# Update the cert on the VDI server: 
ssh to vdi server as kvm
cd /home/kvm/kvm/install/servlet_container/conf
Backup the default keystore file:
mv .keystore old.keystore
Copy (SCP?) the new keystore file to the conf directory:
cp /home/kvm/kvm/install/servlet_container/conf/all-certs.p12 .keystore
Verify that the .keystore and old.keystore files exist:
ls –al

# Update the SSL Password in the configuration file:

Edit the server.xml file using the vi editor:
Find the clientAuth line by searching: /clientAuth=
Verify the keystorePass=”password” entry does not already exist in entire Define a SSL HTTP/1.1 Connector
 on port 8443 section. Add the following line, replacing “password” with your keystore password:
If keystorePass=”changeit” already exists in the section, simply replace the “changeit” with your
 keystore password.

# Note: Having two keystorePassword lines in the server.xml file may cause tomcat to fail when starting. 
Ensure there is only one instance of the keystorePassword.
Save and exit 

# Restart Tomcat Services
(as the kvm user)
tc_stop && tc_start