Thursday, November 11, 2010
Ubuntu, Apache, and Other Gotchas
I have been spending the last week and half to two weeks creating a new honeypot. I had to set up a web server. With RedHat, one only edits /etc/httpd/httpd.conf to configure the Apache web server. Even the Apache Foundation's documentation only recognizes configuring httpd.conf. But when you are configuring a Debian based system, woe are you! The normal httpd.conf configuration is split up into several files even though httpd.conf is still there in the /etc/apache2 directory. There's /etc/apache2/ports.conf which sets the ports that the webserver listens on. There's /etc/apache2/conf.d/security for configuring ServerTokens and ServerSignature. There's /etc/apache2/sites-available for configuring virtual hosts. If one just edits httpd.conf, nothing happens because the other configuration files take precedence. This pain is spread out in other directories as well such as /etc/sysctl/conf.d or /etc/ufw. It's easier to configure a firewall from one script, but try to figure out what's going on between two or three different configuration scripts.
Then there's GCC 4.4. They cleaned up some include headers. When I was compiling a Qt4 program whose source I downloaded from the Internet, I got an "error: ISO C++ forbids declaration of 'uint8_t' with no type". I assumed that the problem was with missing Qt4 headers, such as QtNetwork, but adding an #include "<"QtNetwork">" header did not solve the problem. I found the solution in Debian bug report 505690. One has to add #include "<"stdint.h">" (header for the Standard C library) to the Qt4 code for it to compile.
Then there's telnet. I was trying to modify the telnet source code to evade a match with the nmap-service-probes database (e.g. grep "Linux telnetd" /usr/share/nmap/nmap-service-probes). The nmap database is matching telnet byte commands and not strings, so it's not immediately obvious how to fool nmap without delving into the telnet protocol. It turns out that you don't need to modify the telnet source code to fool nmap at all. You just need to change a variable definition in the /usr/include/arpa/telnet.h header file on the system you are compiling the source code on. Really obvious, huh! (NOT!) Once you have the binary, you can either change the definition back to what it was or install the binary on another system. What I did would result in my version of telnet being unable to fully communicate with normal versions of the program, but since nmap is matching telnet byte commands, one either has to alter a byte command's number or alter the sequence of commands. It's easier to alter the numeric code to fool nmap if you are building a honeypot. The system will be used as a trap, not for production purposes. So, if you need to run telnet on a Linux honeypot and you don't want nmap screaming "Linux" at the attacker during the enumeration phase, you need to change the X Display Location (TELOPT_XDISPLOC) byte command number in the following line
#define TELOPT_XDISPLOC 35 /* X Display Location */
Redefining TELOPT_XDISPLAYLOC will likely screw up telnet connections from a X11 display terminal, but you don't want attackers or anyone else to be using telnet anyway. It's okay for them to "try" to use it though. You'll also want to change the /etc/issue.net banner to something else or your header alteration will be for naught. By the way, always perform an apt-get build-dep source "program" before you perform the apt-get -b source "program" on a Debian based system or something is liable to break during the compile.
Then there's Java. I had to install a Java version of TightVNC on the honeypot. When I tried to connect via the Internet Explorer browser, I got this error:
load: class VncViewer.class not found.
java.lang.ClassNotFoundException: VncViewer.class
blah, blah, blah...
It's a rather common error. If you have this line:
Caused by: java.io.IOException: open HTTP connection failed, or
Caused by: java.net.ConnectException: Network is unreachable,
the cause is due to an IPv6 network setting in Linux. I first found the solution here, but the same documented workaround is detailed in bug 6342561. Unfortunately, that was not the error I got. The error I had was:
Caused by: java.io.IOException: VncViewer.class not found.
I had to copy the missing class to the root of the virtual host directory. Then the error changed to OptionsFrame.class not found. So, I copied all of the TightVNC class files (and one jar file) from /usr/share/tightvnc-java/ to the virtual host directory to be safe. Then, TightVNC worked. This was odd because if you install the TightVNC files directly from the binary archive into the virtual host directory, the class files are found in a classes subdirectory, i.e. /var/www/virtual-domain/classes. Since the default install is likely to fail with TightVNC in a virtual host directory, I wonder what the "real" default install is.
Then there's GCC 4.4. They cleaned up some include headers. When I was compiling a Qt4 program whose source I downloaded from the Internet, I got an "error: ISO C++ forbids declaration of 'uint8_t' with no type". I assumed that the problem was with missing Qt4 headers, such as QtNetwork, but adding an #include "<"QtNetwork">" header did not solve the problem. I found the solution in Debian bug report 505690. One has to add #include "<"stdint.h">" (header for the Standard C library) to the Qt4 code for it to compile.
Then there's telnet. I was trying to modify the telnet source code to evade a match with the nmap-service-probes database (e.g. grep "Linux telnetd" /usr/share/nmap/nmap-service-probes). The nmap database is matching telnet byte commands and not strings, so it's not immediately obvious how to fool nmap without delving into the telnet protocol. It turns out that you don't need to modify the telnet source code to fool nmap at all. You just need to change a variable definition in the /usr/include/arpa/telnet.h header file on the system you are compiling the source code on. Really obvious, huh! (NOT!) Once you have the binary, you can either change the definition back to what it was or install the binary on another system. What I did would result in my version of telnet being unable to fully communicate with normal versions of the program, but since nmap is matching telnet byte commands, one either has to alter a byte command's number or alter the sequence of commands. It's easier to alter the numeric code to fool nmap if you are building a honeypot. The system will be used as a trap, not for production purposes. So, if you need to run telnet on a Linux honeypot and you don't want nmap screaming "Linux" at the attacker during the enumeration phase, you need to change the X Display Location (TELOPT_XDISPLOC) byte command number in the following line
#define TELOPT_XDISPLOC 35 /* X Display Location */
Redefining TELOPT_XDISPLAYLOC will likely screw up telnet connections from a X11 display terminal, but you don't want attackers or anyone else to be using telnet anyway. It's okay for them to "try" to use it though. You'll also want to change the /etc/issue.net banner to something else or your header alteration will be for naught. By the way, always perform an apt-get build-dep source "program" before you perform the apt-get -b source "program" on a Debian based system or something is liable to break during the compile.
Then there's Java. I had to install a Java version of TightVNC on the honeypot. When I tried to connect via the Internet Explorer browser, I got this error:
load: class VncViewer.class not found.
java.lang.ClassNotFoundException: VncViewer.class
blah, blah, blah...
It's a rather common error. If you have this line:
Caused by: java.io.IOException: open HTTP connection failed, or
Caused by: java.net.ConnectException: Network is unreachable,
the cause is due to an IPv6 network setting in Linux. I first found the solution here, but the same documented workaround is detailed in bug 6342561. Unfortunately, that was not the error I got. The error I had was:
Caused by: java.io.IOException: VncViewer.class not found.
I had to copy the missing class to the root of the virtual host directory. Then the error changed to OptionsFrame.class not found. So, I copied all of the TightVNC class files (and one jar file) from /usr/share/tightvnc-java/ to the virtual host directory to be safe. Then, TightVNC worked. This was odd because if you install the TightVNC files directly from the binary archive into the virtual host directory, the class files are found in a classes subdirectory, i.e. /var/www/virtual-domain/classes. Since the default install is likely to fail with TightVNC in a virtual host directory, I wonder what the "real" default install is.
Labels: brittle software, what manual uint8_t error missing VncViewer.class error
