Installing ManageEngine on Linux 64bit

I came across this same error the last time I tried out Manage Engine’s software when installing on a 64bit Debian installation.  So here it is for me to remember now, in case it happens again.

root@xyzzy:~# ./ManageEngine_ServiceDesk_Plus_MSP.bin
InstallShield Wizard
Initializing InstallShield Wizard...
Searching for Java(tm) Virtual Machine...
.
Preparing Java(tm) Virtual Machine...
..................................
...................................
...................................
...................................
...................................
...................................
...................................
...................................
........

It just stops there.
The solution is to install libc6-i386.

apt-get install libc6-i386

Now I can run the installation making sure to pass -console since I do not have a DE/WM.

Performance Tuning OwnCloud 6.02

I am using OwnCloud for some personal file storage and synchronizing of Contacts on my Linux server. The web interface is horribly slow with a default install. Here are some of the things I did to adjust performance and make it a bit faster.
PHP Specific

  • Increase memory_limit to 512MB
  • Installed php-apc

OwnCloud Specific

  • Installed using MySQL instead of SQLite3
  • Disabled addons that I did not need
  • Changed from AJAX Cron to Cron

Linux Server Specific

  • Nothing

I still see a request times on scan.php to be 1 second+, however, performance overall is much improved.
My System Setup

  • OwnCloud 6.02
  • MySQL 5.5.35
  • PHP FastCGI
  • Debian Linux 7.4
  • Memory – 4GB
  • CPU – 2x2GHz

 

PHP Easter Eggs

To honor Easter, I’ve decided to put this little tidbit of information up. These are PHP easter eggs.  I had no idea these existed until I was running a security scan using Detectify.  This information can be considered to be a vulnerability since it could be used to obtain specific server information/versions and use that version as a reference to look up exploits against PHP, the server, etc.
You can use these by visiting your site, or another site, and using them in the URI:

http://www.example.com/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000

PHP Credits (phpinfo):
PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
PHP Logo:
PHPE9568F34-D428-11d2-A769-00AA001ACF42
Zend Logo:
PHPE9568F35-D428-11d2-A769-00AA001ACF42
Easter Egg (animals and a guy):
PHPE9568F36-D428-11d2-A769-00AA001ACF42

Automating Heartbleed Bug Check From Cisco ASA Capture Data

In a previous post I outlined how to capture specific port traffic, in this case HTTPS, on the Cisco ASA. This post is dedicated to parsing the data from the ASCII capture and running the Heartbleed check on it.
The file looks similar to the following; here are the first few lines:

   1: 10:02:33.299819 192.168.1.35.52528 > 74.125.228.5.443: P 4164465901:41644
66282(381) ack 768563964 win 64860
   2: 10:02:33.326780 192.168.1.35.52528 > 74.125.228.5.443: P 4164466282:41644
66944(662) ack 768564010 win 64814
   3: 10:02:33.444724 192.168.1.35.52528 > 74.125.228.5.443: . ack 768566594 wi
n 64860

The easiest way for me to parse this is by using awk to give me the fifth column of data. cut wasn’t working for me (for some reason).
Parse capture file and give unique results and tidy the IP addresses up (stripping port number from end):

root@xyzzy:~# cat heartbleed.cap  | awk '{print $5}'|sort -rn | uniq | sed -e 's/.443.*//g'

Now I’m left with 4 unique IP addresses out of the 7400+ packets captured.

199.59.150.7
93.184.216.146
74.125.228.5
192.168.1.1

Now, I can run these IPs through the Heartbleed test provided by Filippo

root@xyzzy:~# /opt/go/bin/bin/Heartbleed 199.59.150.7:443
2014/04/16 10:15:01 199.59.150.7:443 - SAFE

To automate this, I can simply wrap this in a loop in a bash script:

#!/bin/bash
while read s; do
        /opt/go/bin/bin/Heartbleed $s:443
done < heartbleed.cap

Fight DoS and DDoS With Linux IPTables

Found this on my G+ stream today and thought it was worth keeping around to play with in the future at some point.

#!/bin/bash
iptables -F
iptables -X protectqueue
iptables -N protectqueue
iptables -A INPUT -p tcp --dport 80 --syn -j protectqueue
iptables -A protectqueue -m limit --limit 1000/second --limit-burst 2000 -j RETURN
iptables -A protectqueue -j LOG --log-prefix IPTABLES: DDOS ALARM!!!
iptables -A protectqueue -j DROP

This is basically a SYN flood protection rule specifically targeting HTTP traffic. It works by limiting HTTP traffic on your interface to 1000 SYN requests per second with a burst of 2000 before the packets are then dropped. Any traffic that matches protocol TCP with destination port 80 and is SYN packet will be sent to the created protectqueue table.