Josh Wieder

As part of my consulting business I have a number of web servers I take care of. This morning, I woke up to receive a particularly crappy message related to one of those servers: possible DoS attack Awesome, right? Ever notice how you never get these sorts of messages between the hours of 9 AM and 5 PM, Monday through Friday? So I tried to SSH into the target server, and was pleased to find I was able to connect. Relieved that this was likely a false alarm, I found this in the Apache logs: 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500] "GET /robots.txt HTTP/1.1" 200 146 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500] "GET /robots.txt HTTP/1.1" 200 146 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500] "GET /robots.txt HTTP/1.1" 200 146 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500] "GET /robots.txt HTTP/1.1" 403 5 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500] "GET /robots.txt HTTP/1.1" 403 5 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500

Recently I have started coming across somewhat unusual entries in the access and error logs for a few of the Apache web servers that I am responsible for maintaining. The entries look like this: 95.156.251.10 - - [03/Nov/2015:13:56:23 -0500] "\x16\x03\x02\x01o\x01" 400 226 "-" "-" Here is another example: 184.105.139.68 - - [03/Nov/2015:23:48:54 -0500] "\x16\x03\x01" 400 226 "-" "-" These errors will be generated on a website configured to use SSL - and in fact, error messages similar to these can be generated by misconfiguring SSL for your website. This error message, for instance, can indicate an attempt to access Apache through SSL while the OpenSSL engine is either disabled or misconfigured: Invalid method in request \x80g\x01\x03 Connections that generate that error would not be successful. This post, however, assumes that your website is working normally when used normally. So what gives? The error indicates

Some time ago I wrote a post about the dismaying history of US government attempts to regulate encryption out of existence . I had to omit quite a bit; it was a post and not a book after all. One of the details left out of the story was the DHE_EXPORT cipher suites. During the 90's, developers were forced by the US government to us deliberately insecure ciphers when communicating with entities in foreign countries (readers will remember from the last post that law makers were convinced that encryption should fall under the same rules as weapons technology, and thus could not be shared with anyone outside the Father Land). These insecure ciphers became DHE_EXPORT. The DH stands for Diffie-Hellman; the key exchange system that bears their name was first published in 1976. Along with the cipher suite was a mechanism to force a normal encrypted transaction to downshift to a lower-bit DHE_EXPORT cipher. As so many short-sighted technology regulations have done in the past, this silly

I recently came across this question on ServerFault: " I've subsonic application running of [sic] tomcat. Everything else works on apache. I don't want to write port number everytime [sic] so I'd like to set-up [sic] a simple directory where subsonic will be accessible. So, I'm trying to make virtualhost file [sic] inside apache dir. [...] I tried many variations, but cannot make anything work. " The poor chap than [sic - ha!] provided an example of his latest go at the problem, an excerpt from his httpd.conf file: <VirtualHost *:80> DocumentRoot /var/www/streamer ProxyPass / http://mini.local:4040/ ProxyPassReverse / http://mini.local:4040/ </VirtualHost>   Not sure a bad go of it, all thing considered. Still, it wasn't providing him with the sort of results he was looking for. Naturally I had encountered similar issues not long ago myself, with the implementation of a Ghost blogging soft

Looking for an apache log visualization program recently, I came across logstalgia. It turns your log files into a game of Pong between your web server and the internet, with each new request being the ball going back and forth! So cool.

Upon restarting Apache, you may receive errors like this: # service httpd restart Stopping httpd: [FAILED] Starting httpd: httpd: apr_sockaddr_info_get() failed for webserver-sb-1 httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName In order to resolve this issue and successfully start Apache, you will need to ensure that there is a resolvable hostname assigned to your server. This hostname does not need to be a fully qualified domain name (FQDN), it just needs to resolve. Here is how to get around it.  #echo yourhostname.extension > /etc/hostname #/bin/hostname -F /etc/hostname Finally, confirm that the assigned domain name is resolvable using the host command #host yourhostname.extension localhost If not, check the following settings: -does /etc/resolv.conf have the correct DNS servers listed to allow for resolution? -If your hostname is not an FQDN, lis