Archive for the ‘Computer’ Category
‘./NS/IN’ denied?
The world of server maintenance has drawn me in yet again. It seems as though my server has been rebooting itself for no apparent reason.
While trying to track this down I noticed something odd in /etc/log/syslog. There seems to be an interesting DNS request from a single IP address every second or so.
Mar 2 20:09:27 neaz named[4701]: client 62.109.4.89#32136: query (cache) ‘./NS/IN’ denied
Mar 2 20:09:28 neaz named[4701]: client 62.109.4.89#50634: query (cache) ‘./NS/IN’ denied
Mar 2 20:09:30 neaz named[4701]: client 62.109.4.89#14324: query (cache) ‘./NS/IN’ denied
Mar 2 20:09:32 neaz named[4701]: client 62.109.4.89#19968: query (cache) ‘./NS/IN’ denied
Mar 2 20:09:33 neaz named[4701]: client 62.109.4.89#35100: query (cache) ‘./NS/IN’ denied
Mar 2 20:09:34 neaz named[4701]: client 62.109.4.89#18747: query (cache) ‘./NS/IN’ denied
I seems that this is a possible DDOS. Roughly speaking someone is sending small packets to my machine and it’s replying to the IP address specified. The problem is that the IP address my server is responding to *may not be the one actually asking* - this is done through IP spoofing.
So to solve this problem I initially just banned the IP address from connecting.
sudo iptables -I INPUT -s 62.109.4.89 -j DROP
This seems to have stopped the DNS problem - but it has a nasty side effect - this IP address can’t actually connect to my server for anything (mail, web, etc). Not necessarily a big deal. What is a big deal is that if someone else’s IP address is spoofed. I’d then have to run the iptables command again, and again, and again.
Now the good thing is that Tom Hayward’s seen this problem and has a slightly better solution.
sudo iptables -I INPUT -p udp --dport 53 -m length --length 45 -j DROP
He’s gone to the trouble of sniffing the length of the packet and applying that to the iptables rule. This rule basically stops all udp traffic on port 53 (DNS) that’s 45 bytes long from being process by the server.
You can test this out if you have a shell open.
dig . NS @localhost
Or you can head over to the SANS Internet Storm Center who’ve been monitoring this problem and use their webtool
Lastly, make sure you save any changes to your iptables or they’ll disappear on a reboot. (thanks DA)
sudo iptables-save > /etc/iptables.rules
sudo echo "#!/bin/sh" > /etc/network/if-up.d/iptables
sudo echo "iptables-restore < /etc/iptables.rules" >> /etc/network/if-up.d/iptables
sudo chmod +x /etc/network/if-up.d/iptables
Wordpress 2.6 to 2.7.1 Upgrade
This post is short and sweet - just like the wordpress upgrade I just did. I went through the “hassle” of doing the svn checkout during my last upgrade (to 2.6) which if I recall correctly wasn’t too difficult - just a little time consuming. Well it just paid off. I ran the upgrade in two minutes. I SSH’d into the server. Went to the wordpress root and ran svn sw http://svn.automattic.com/wordpress/tags/2.7.1/.
The site stayed up and running and I only had to click on one button in the admin to upgrade the database. Thank you wordpress - you guys rock!
Oh, and just for reference - here’s the svn upgrade url.
Single Sign on with Tomcat
I’ve been asked by a client to take a look at integrating two of their applications to use single signon. They currently have a “members” area which contains secure webpages for individual clients to see. Typically, each client has their own secure area that no one else can access. This is implemented using BasicAuth in an .htaccess file.
The web application is a Java based (Struts) content management system which uses tomcat’s j_security_check for authentication.
The way that I’ve tried to integrate these two is to convert the apache security over to tomcat. This was easy to do. I just basically created a new context and moved the content into the appropriate directory. The only thing I needed to do was create the WEB-INF/web.xml directory/file. I needed to tweek the web.xml to restrict files the way I wanted it to. Basically, if someone goes to http://www.example.com/members/ the are forced to login (Basic authentication for now). There’s an index.jsp file that check the user name and redirects the client to http://www.example.com/members/”username”/.
Integrating the two webapps was also fairly easy. I needed to move the realm from each of the contexts and move them into the host portion of the server.xml file. Basically, this forces all of the contexts in the host to use the same authentication module and thus they can share sessions. The only other thing was to add this…
<Valve className="org.apache.catalina.authenticator.SingleSignOn" debug="0"/>
…inside of the host portion as well.
There’s a whole lot more that can be done, but this is great for a start since it only took a few hours to figure out and fix any problems I encountered.