In previous posts relating to my LAMP server (see tags) I've described how I use PHP to write iptables rules so I can keep various ports closed when I'm not actually using them. Something else I use it for is to block IP addresses from which bad bots are operating. This technique is discussed and documented on various other sites so I'm not going to give details full details here. However, in a nutshell my scheme involves:
1. Using robots.txt to designate a directory into which bots should not go.
2. Inserting hidden links on various documents that link to a file in the above directory. Humans will not see these links (because they are invisible) and well behaved robots (that pay attention to robots.txt) will not follow them either. Thus the only things that will follow those links are bad bots.
3. My hidden links point to a PHP script which write a new iptables rule, thereby blocking the bot. An entry is also made in a database recording the time and request that blocked the bot.
4. Bots will often operate using addresses from pools that are used legitimately at other times, so it's important to release the blocked addresses after a suitable period. I have a cron job to run a script that checks the database and releases anything that has been blocked for longer than a specified period.
This has been working well for some time however more recently I've been seeing something else in my server reports that I wanted to do something about; attempts to access urls such as these:
//Admin//scripts/setup.php
//MyAdmin//scripts/setup.php
//admin//scripts/setup.php
//phpMyAdmin//scripts/setup.php
There's usually a great long list of them trying lots of variations. Something else I've seen quite a bit of is this kind of thing:
/index.php?gzip=0&file=/etc/passwd
Again, the usually attempt the same, or similar things with any .php they can find.
Now provided that all of your other security is in place then attempts such as these shouldn't be a problem however, they are clearly attempts to break into the server. As such whatever is generating them is making a nuisance of itself and should, in my humble opinion, be told to **** off at the first available opportunity. So I've added a few more lines to httpd.conf
RewriteRule scripts/setup.php /var/www/cgi-bin/ip_blocker.php
RewriteCond %{QUERY_STRING} /etc/passwd
RewriteRule ^(.+) /var/www/cgi-bin/ip_blocker.php
The first line looks for urls that contain "scripts/setup.php" and redirects them to my blocking script. Obviously if you use anything on you server where that would be part of a legitimate request you need to modify that, but I don't, so I can use it. The next two lines do a similar redirect on any request where the text "/etc/passwd" appears in the query string.
Note that because I wanted these rules to apply to all of the virtual sites on my server, I've put these rules such that they apply to the main server and told all of the virtual sites to inherit them using:
RewriteOptions inherit
Note however that despite them appearing before the virtual server directives in the httpd.conf file, the virtual server directives are processed first. Thus it is important that none of the virtual server rules end with [F] as this would result in a match there halting the processing of rewrite rules before these are run.
Enjoy, unless you're a bot. ;-)
Showing posts with label LAMP. Show all posts
Showing posts with label LAMP. Show all posts
Sunday, 21 June 2009
Tuesday, 3 July 2007
Opening Ports With PHP
In my previous post I described how I'd set up iptables. The important thing to note about that is that I set my default INPUT policy to DROP anything that isn't specifically accepted by a rule. This means that I can easily open and close ports using the iptables command to add or delete rules. For example, the following can be used to open the port for webmin:
I can then close it again by deleting the rule with:
Note that:
1. Webmin is always running, and listening, even when the port is closed, so I don't have to issue commands to start and stop it. I just need to open and close the port.
2. I don't have to leave the rule in place for the entire session as the commands above allow and disallow NEW sessions. Other rules in my iptables setup allow established sessions to continue. (Although in fact Webmin tends to stop and start the session as you use different elements of it so it's as well to leave the port open until you are done.)
3. The iptables command can only be used by root.
Now I'd like to be able to do the same thing with SSH but of course there's a catch: if I close port 22 then I can't SSH in to issue the command to open it. Don't get caught out by that one!
However, as mentioned in a previous post, my intention was to use a secret backdoor by getting one of my .php web pages to watch out for a special input and use exec() to run the iptables command. However there is a catch here also: the PHP script runs as apache but the iptables command can only be run by root.
Now there are a couple of ways around this and what I've chosen to do is to use the sudo command. This allows a user to run a command as another user however they have to be given permission in the /etc/sudoers file. I did this by adding the following line to the file (using visudo to edit it - as it tells you that you must in the file itself).
This gives apache the ability to run the iptables command without the need for a passwork. Shock! Horror! Isn't that a security problem?
Well, not really, the addition allows apache to run iptables, and that's it, nothing else. It's also important to realise that on my server, you cannot log in as apache, and in fact I am the only user allowed to log into my server at all. I am also the only person who can upload .php files to my server so I am the only person who could install a .php script that uses exec to run iptables as apache. Now even if somebody else did figure out a way to get around that, 'all' they would have achieved is the ability to open and close ports. They'd still need to crack other passwords before they could do anything useful/nasty. Furthermore, the instructions being issued to iptables are reported in my Logwatch report so I'd be made aware of it.
Of course if you don't have the luxury of being the only person who needs access to your server then you may be better to consider another approach. For example you could use your php script to create a file or change a setting in a database to act as a flag for a cron job. You would then create a cron job, which you set to run every couple of minutes, to check the flag and run the iptables command when the flag is set. The downside of course is that after setting the flag you have to wait for the cron job to run before you can get in. The upside is that apache no longer needs the ability to run the iptables command. Apache just sets the flag and the cron job (which you run as root) issues the iptables command.
Incidentally, there's a heap of info about the sudoers file available by typing 'man sudoers' at the Linux command line with loads of examples down at the bottom of the man page. Check it out and you will see that you have a heck of a lot of control over what you do and do not allow sudo to be used for. Given the various other restrictions on my server, I'm happy to allow apache to use sudo to run iptables and can therefore use the following PHP to open and close a port for SSH when I tell it to:
Note that my iptables setup (as I described a my previous post) is such that port 22 is open when my server boots, and I leave it that way.
Under normal circumstances, after rebooting the server, I would tell my PHP script to close port 22 and would then leave it closed when I'm not using it. However, I leave it so that the default after a reboot is to have it open. This means that if something should go wrong such that I can no longer access my PHP script to open the port (which I would need to do to change the PHP script), I can get it open again by requesting a reboot.
Perhaps the biggest headache that I had in setting this up was that initially I couldn't 'sudo' via exec(). I spent hours looking for the problem and it was driving me crazy because everything I found on the subject indicated that what I was doing was absolutely spot on. The breakthough came when it was suggested that I try this:
The result should be 'root' but what I got, courtesy of the bit on the end, was this: 'sudo: sorry, you must have a tty to run sudo'
A search on that told me that the issue related to a setting in /etc/sudoers which is used in Fedora Core 6 namely:
I didn't get entirely to the bottom of why it's there. Something to do with there being circumstances when the password you are entering for sudo can be visible on the screen. Apparently it's a new thing in FC6 and all the advice I saw suggested that the solution was to comment it out (which leaves me wondering if that setting will still be present in FC7). Either way, I'm using sudo in such a way that I'm not typing a password so I don't see that it's an issue.
/sbin/iptables -A INPUT -p tcp --dport 10000 -m state --state NEW -j ACCEPT
I can then close it again by deleting the rule with:
/sbin/iptables -D INPUT -p tcp --dport 10000 -m state --state NEW -j ACCEPT
Note that:
1. Webmin is always running, and listening, even when the port is closed, so I don't have to issue commands to start and stop it. I just need to open and close the port.
2. I don't have to leave the rule in place for the entire session as the commands above allow and disallow NEW sessions. Other rules in my iptables setup allow established sessions to continue. (Although in fact Webmin tends to stop and start the session as you use different elements of it so it's as well to leave the port open until you are done.)
3. The iptables command can only be used by root.
Now I'd like to be able to do the same thing with SSH but of course there's a catch: if I close port 22 then I can't SSH in to issue the command to open it. Don't get caught out by that one!
However, as mentioned in a previous post, my intention was to use a secret backdoor by getting one of my .php web pages to watch out for a special input and use exec() to run the iptables command. However there is a catch here also: the PHP script runs as apache but the iptables command can only be run by root.
Now there are a couple of ways around this and what I've chosen to do is to use the sudo command. This allows a user to run a command as another user however they have to be given permission in the /etc/sudoers file. I did this by adding the following line to the file (using visudo to edit it - as it tells you that you must in the file itself).
apache ALL = (root) NOPASSWD: /sbin/iptables
This gives apache the ability to run the iptables command without the need for a passwork. Shock! Horror! Isn't that a security problem?
Well, not really, the addition allows apache to run iptables, and that's it, nothing else. It's also important to realise that on my server, you cannot log in as apache, and in fact I am the only user allowed to log into my server at all. I am also the only person who can upload .php files to my server so I am the only person who could install a .php script that uses exec to run iptables as apache. Now even if somebody else did figure out a way to get around that, 'all' they would have achieved is the ability to open and close ports. They'd still need to crack other passwords before they could do anything useful/nasty. Furthermore, the instructions being issued to iptables are reported in my Logwatch report so I'd be made aware of it.
Of course if you don't have the luxury of being the only person who needs access to your server then you may be better to consider another approach. For example you could use your php script to create a file or change a setting in a database to act as a flag for a cron job. You would then create a cron job, which you set to run every couple of minutes, to check the flag and run the iptables command when the flag is set. The downside of course is that after setting the flag you have to wait for the cron job to run before you can get in. The upside is that apache no longer needs the ability to run the iptables command. Apache just sets the flag and the cron job (which you run as root) issues the iptables command.
Incidentally, there's a heap of info about the sudoers file available by typing 'man sudoers' at the Linux command line with loads of examples down at the bottom of the man page. Check it out and you will see that you have a heck of a lot of control over what you do and do not allow sudo to be used for. Given the various other restrictions on my server, I'm happy to allow apache to use sudo to run iptables and can therefore use the following PHP to open and close a port for SSH when I tell it to:
// create an iptables rule to allow access on port 22
exec('/usr/bin/sudo /sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT')
// delete the iptables rule to allow access on port 22
exec('/usr/bin/sudo /sbin/iptables -D INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT')
Note that my iptables setup (as I described a my previous post) is such that port 22 is open when my server boots, and I leave it that way.
Under normal circumstances, after rebooting the server, I would tell my PHP script to close port 22 and would then leave it closed when I'm not using it. However, I leave it so that the default after a reboot is to have it open. This means that if something should go wrong such that I can no longer access my PHP script to open the port (which I would need to do to change the PHP script), I can get it open again by requesting a reboot.
Watch out for this:
Perhaps the biggest headache that I had in setting this up was that initially I couldn't 'sudo' via exec(). I spent hours looking for the problem and it was driving me crazy because everything I found on the subject indicated that what I was doing was absolutely spot on. The breakthough came when it was suggested that I try this:
echo exec('/usr/bin/sudo /usr/bin/whoami 2>&1');
The result should be 'root' but what I got, courtesy of the bit on the end, was this: 'sudo: sorry, you must have a tty to run sudo'
A search on that told me that the issue related to a setting in /etc/sudoers which is used in Fedora Core 6 namely:
Defaults requiretty
I didn't get entirely to the bottom of why it's there. Something to do with there being circumstances when the password you are entering for sudo can be visible on the screen. Apparently it's a new thing in FC6 and all the advice I saw suggested that the solution was to comment it out (which leaves me wondering if that setting will still be present in FC7). Either way, I'm using sudo in such a way that I'm not typing a password so I don't see that it's an issue.
Monday, 2 July 2007
iptables
iptables is something that I've steered clear of until recently. Partly because it looks blooming complicated (and why bother when scripts such as system-config-securitylevel will set up a firewall without getting involved in the nitty-gritty), but also for fear of locking myself out of the server (which is 100+ miles away at a server farm and doesn't have a screen and keyboard attached). When I became interested in port-knocking however, it seemed that the time had come to do a little research.
The first bit of good news came when I discovered that you can 'mess' with iptables without making the changes permanent. When the server boots and iptables sets up the firewall, it loads rules from /etc/sysconfig/iptables however you can then change those rules from the linux command line using the iptables command. In fact you can create a script to delete the current rules and load a new set. The crucial thing here is that you do not edit /etc/sysconfig/iptables directly. Firstly because it's 'system generated' and secondly because if things go wrong, you can reinstate the original set of rules by rebooting the server. While I can't get physical access to my server, there's a mechanism by which I can request a reboot. Of course when you have a set of rules that work you will want the server to use them when it boots and you do this by issuing the following command causing the rules that are currently in memory to be written to the /etc/sysconfig/iptables file:
Safe in the knowledge that we can dabble, it's time to look at creating the script that will install our rules. The first three lines look like this:
Obviously the first line starts our shell. The next two lines clear out any existing iptables rules and user defined chains (of rules) that are currently in memory.
iptables works by looking at packets that are wanting to cross the firewall. These could be packets coming into the computer from the network, going from the computer out to the network, or being forwarded (if the computer is also being used as a router). Because of this it is normal for a set of iptables rules to start with a set of default policies such as:
I've seen examples sets that work on the basis of accepting anything that doesn't get blocked by a later rule, and I've seen others that block everything unless it's accepted by a later rule. I've gone for a mixture. Nothing comes in unless a later rule allows it. My server is not being used as a router so all packets for forwarding are dropped. All outgoing packets are allowed.
It might seem odd that you would want to do anything other than allow all outgoing packets however in a scenario where the computer is allowing a number of machines on a LAN to connect to a WAN, you may want to implement restrictions.
The next thing is to set up the loopback interface:
This allows local traffic such that daemons running on our computer can send packets to other daemons running on our computer via the firewall. Stricly speaking, we only need the first of the above lines in our script because our default policy for output already allows outgoing packets from our daemons.
With the default policies set up and our daemons able to talk to each other, our computer can see out, but nothing can see in. If this were a home computer being used to access the web, we could stop right here, however I'm creating rules for a web server and there's no point having a server if nothing can access it.
Before we create a few rules to open things up, it's important to understand that we can split and packets reaching the interface into one of two groups: those initiating a connection, and those that are part of an established connection. This simplifies things because we can allow packets for established connections to pass through unhindered because we already did all our checks before we allowed the initial connection.
The first line says that all new TCP connections must start with a SYN packet i.e. that they must start properly. The second line says that packets for established or related connections are allowed through. If we stop there then we will still be blocking all input because we haven't allowed anything to establish a new connection yet.
The three lines above allow new connections by accepting packets coming in on ports 22, 25, and 80 i.e. SSH, SMTP and HTTP. Note that this does not mean that anybody can connect via SSH. The still have to be on the list of allowed users and they have to know a password. The above simply means that the port it 'open' such that it is possible to connect.
We're almost done now although there are lots of other things that could be done with our rules and that you will see in other suggested iptables setup scripts. Sometimes you may need other ports open and sometimes you may want to do things like blocking traffic from IP addresses that are being a nuisance. You can also do things like locking out an IP (for a period of time) that has made more than a given number of connection attempts in a given amount of time. In a later post I'll describe describe a technique that I've implemented to greatly enhance the security of my server using iptables rules but in the meantime I want to make just one final addition:
This accepts incomming type 8 ICMP messages and allows people to ping the server. If this were a desktop computer from which I wanted to issue the traceroute command then I should also allow type 11 ICMP messages. However it isn't, so I won't, and our final script looks like this:
Of course the final steps are to save our script, make it executable, and run it as root. We then need to check that everything works as we expect. Most especially that we can still initiate new SSH connections to our server. When we are happy we use the 'system iptables save' command to write our configuration to /etc/config/iptables and we're done.
The first bit of good news came when I discovered that you can 'mess' with iptables without making the changes permanent. When the server boots and iptables sets up the firewall, it loads rules from /etc/sysconfig/iptables however you can then change those rules from the linux command line using the iptables command. In fact you can create a script to delete the current rules and load a new set. The crucial thing here is that you do not edit /etc/sysconfig/iptables directly. Firstly because it's 'system generated' and secondly because if things go wrong, you can reinstate the original set of rules by rebooting the server. While I can't get physical access to my server, there's a mechanism by which I can request a reboot. Of course when you have a set of rules that work you will want the server to use them when it boots and you do this by issuing the following command causing the rules that are currently in memory to be written to the /etc/sysconfig/iptables file:
service iptables save
Safe in the knowledge that we can dabble, it's time to look at creating the script that will install our rules. The first three lines look like this:
#!/bin/sh
/sbin/iptables --flush
/sbin/iptables --delete-chain
Obviously the first line starts our shell. The next two lines clear out any existing iptables rules and user defined chains (of rules) that are currently in memory.
iptables works by looking at packets that are wanting to cross the firewall. These could be packets coming into the computer from the network, going from the computer out to the network, or being forwarded (if the computer is also being used as a router). Because of this it is normal for a set of iptables rules to start with a set of default policies such as:
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT
I've seen examples sets that work on the basis of accepting anything that doesn't get blocked by a later rule, and I've seen others that block everything unless it's accepted by a later rule. I've gone for a mixture. Nothing comes in unless a later rule allows it. My server is not being used as a router so all packets for forwarding are dropped. All outgoing packets are allowed.
It might seem odd that you would want to do anything other than allow all outgoing packets however in a scenario where the computer is allowing a number of machines on a LAN to connect to a WAN, you may want to implement restrictions.
The next thing is to set up the loopback interface:
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
This allows local traffic such that daemons running on our computer can send packets to other daemons running on our computer via the firewall. Stricly speaking, we only need the first of the above lines in our script because our default policy for output already allows outgoing packets from our daemons.
With the default policies set up and our daemons able to talk to each other, our computer can see out, but nothing can see in. If this were a home computer being used to access the web, we could stop right here, however I'm creating rules for a web server and there's no point having a server if nothing can access it.
Before we create a few rules to open things up, it's important to understand that we can split and packets reaching the interface into one of two groups: those initiating a connection, and those that are part of an established connection. This simplifies things because we can allow packets for established connections to pass through unhindered because we already did all our checks before we allowed the initial connection.
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
The first line says that all new TCP connections must start with a SYN packet i.e. that they must start properly. The second line says that packets for established or related connections are allowed through. If we stop there then we will still be blocking all input because we haven't allowed anything to establish a new connection yet.
/sbin/iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
The three lines above allow new connections by accepting packets coming in on ports 22, 25, and 80 i.e. SSH, SMTP and HTTP. Note that this does not mean that anybody can connect via SSH. The still have to be on the list of allowed users and they have to know a password. The above simply means that the port it 'open' such that it is possible to connect.
We're almost done now although there are lots of other things that could be done with our rules and that you will see in other suggested iptables setup scripts. Sometimes you may need other ports open and sometimes you may want to do things like blocking traffic from IP addresses that are being a nuisance. You can also do things like locking out an IP (for a period of time) that has made more than a given number of connection attempts in a given amount of time. In a later post I'll describe describe a technique that I've implemented to greatly enhance the security of my server using iptables rules but in the meantime I want to make just one final addition:
/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT
This accepts incomming type 8 ICMP messages and allows people to ping the server. If this were a desktop computer from which I wanted to issue the traceroute command then I should also allow type 11 ICMP messages. However it isn't, so I won't, and our final script looks like this:
#!/bin/sh
# Flush old rules, old custom chains
/sbin/iptables --flush
/sbin/iptables --delete-chain
# Set default policies for all three default chains
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT
# Enable free use of loopback
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
# All TCP sessions should begin with SYN
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# Accept inbound TCP packets
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
# Accept inbound ICMP messages
/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT
Of course the final steps are to save our script, make it executable, and run it as root. We then need to check that everything works as we expect. Most especially that we can still initiate new SSH connections to our server. When we are happy we use the 'system iptables save' command to write our configuration to /etc/config/iptables and we're done.
Sunday, 1 July 2007
Thinking About Port Knocking
In a previous post I described how I'd tweaked my server's security with respect to SSH and Webmin however I really wanted to make it more difficult for a potential abuser to get anywhere near them. I also wanted, if possible, to rid my Logwatch reports of the hundreds (sometimes thousands) of lines reporting failed attempts to log in via SSH.
Using a non-standard port for these services is a commonly suggested 'solution' but while this may throw most of the current crop of bots off the scent, any half-serious hacker can easily do a port scan first. You can also be fairly certain that if the bots aren't currently doing a preliminary scan, it's only a matter of time before they will. Thus using a non-standard port is little more than a temporary side-stepping of the problem. Should you opt to try it, don't forget to open the new port in your firewall first or you'll lock yourself out of your server.
Secure Authentication - setting things up so that your computer authenticates itself to the server rather than logging in with a password - means you can then disable the ability to make connection by logging in with a password and this is very cool option so long as you don't find yourself away from home, needing to log into your server from another machine, and without your authentication keys on a memory stick.
Other solutions that I've seen use programs like fail2ban or denyhosts to scan logs and act upon what they find. Typically they'll scan the logs at a 20 minute intervals and block any IP address that has tried and failed to log in more than a specified number of times. As I see it, the problems with this type of approach is that you'll still see numerous attempts taking place because the IP address isn't blocked until the log scan takes place.
pam_abl, an addition to PAM, looks for repeated failures to log in and if a given IP address fails more than X times in Y seconds, it gets banned. This has a more immediate effect however the info I saw suggested that the bans were permanent and that's not what I want. Any defence mechanism that blocks IP addresses should also ensure that they are unblocked a short while later because if the attacker is logged into the web via an IP addess allocated from a pool at AOL or attacking via a hacked server, then you could end up blocking legitimate traffic when the address has been reallocated, or the server being sorted out. I guess using a cron job to unblock them would be an option.
Port knocking - a scheme by which you have to 'knock' on a number of prespecified ports in a set sequence in order to open another port - had an immediate appeal because the knock cab be carried out with something as commonly available as Telnet so getting access while away from your normal machine merely requires that you remember the port numbers. Wikipedia has a good article on port knocking with links to an article explaining how to do it using iptables (although you need to have the ipt_recent module loaded to do it).
However, while discussion port knocking over at the Fedora project forums (click here to see the topic), sej7278 suggested that you could use something on a webpage to trigger the opening an closing of a port. Further to that it occurred to me that you could use a url that was normally used for something else. For example, if the front page of my site were:
http://www.luntaticatics.com/index.php
I could use:
http://www.luntaticatics.com/index.php?open_port=22
to open SSH. All I'd need to do is to make the index.php script look for the additional parameters and use exec() to issue the command to open the port.
I'll explain how that works in a later post however for now I would just like to say to any crackers who may be reading this:
1. The front page of my site is not index.php and I'm not using a page at lunaticantics.com so you'll have to start by guessing the name an location of the .php file that I'm using. Note that there's no reason for the page to be linked into the rest of the site so you'll have to guess.
2. I wouldn't be so stupid as to use something as simple as open_port=22 and publish it here. So if you do manage to find the .php file, you'll need to guess what parameters are needed to trigger it. Note that there's no need for the parameter name and value to make any sense to anybody or anything other than myself and the .php script that's watching for it.
3. Probably your best bet for finding the above to monitor the network traffic to my server but even if you do find it, you will then need to figure out my SSH user login name, password, and root password (as described in my earlier post you can't just log in as root), and any failed attempts will be show up in my Logwatch report thus alerting me that you've found my port opener, and prompting me to change it.
Using a non-standard port for these services is a commonly suggested 'solution' but while this may throw most of the current crop of bots off the scent, any half-serious hacker can easily do a port scan first. You can also be fairly certain that if the bots aren't currently doing a preliminary scan, it's only a matter of time before they will. Thus using a non-standard port is little more than a temporary side-stepping of the problem. Should you opt to try it, don't forget to open the new port in your firewall first or you'll lock yourself out of your server.
Secure Authentication - setting things up so that your computer authenticates itself to the server rather than logging in with a password - means you can then disable the ability to make connection by logging in with a password and this is very cool option so long as you don't find yourself away from home, needing to log into your server from another machine, and without your authentication keys on a memory stick.
Other solutions that I've seen use programs like fail2ban or denyhosts to scan logs and act upon what they find. Typically they'll scan the logs at a 20 minute intervals and block any IP address that has tried and failed to log in more than a specified number of times. As I see it, the problems with this type of approach is that you'll still see numerous attempts taking place because the IP address isn't blocked until the log scan takes place.
pam_abl, an addition to PAM, looks for repeated failures to log in and if a given IP address fails more than X times in Y seconds, it gets banned. This has a more immediate effect however the info I saw suggested that the bans were permanent and that's not what I want. Any defence mechanism that blocks IP addresses should also ensure that they are unblocked a short while later because if the attacker is logged into the web via an IP addess allocated from a pool at AOL or attacking via a hacked server, then you could end up blocking legitimate traffic when the address has been reallocated, or the server being sorted out. I guess using a cron job to unblock them would be an option.
Port knocking - a scheme by which you have to 'knock' on a number of prespecified ports in a set sequence in order to open another port - had an immediate appeal because the knock cab be carried out with something as commonly available as Telnet so getting access while away from your normal machine merely requires that you remember the port numbers. Wikipedia has a good article on port knocking with links to an article explaining how to do it using iptables (although you need to have the ipt_recent module loaded to do it).
However, while discussion port knocking over at the Fedora project forums (click here to see the topic), sej7278 suggested that you could use something on a webpage to trigger the opening an closing of a port. Further to that it occurred to me that you could use a url that was normally used for something else. For example, if the front page of my site were:
http://www.luntaticatics.com/index.php
I could use:
http://www.luntaticatics.com/index.php?open_port=22
to open SSH. All I'd need to do is to make the index.php script look for the additional parameters and use exec() to issue the command to open the port.
I'll explain how that works in a later post however for now I would just like to say to any crackers who may be reading this:
1. The front page of my site is not index.php and I'm not using a page at lunaticantics.com so you'll have to start by guessing the name an location of the .php file that I'm using. Note that there's no reason for the page to be linked into the rest of the site so you'll have to guess.
2. I wouldn't be so stupid as to use something as simple as open_port=22 and publish it here. So if you do manage to find the .php file, you'll need to guess what parameters are needed to trigger it. Note that there's no need for the parameter name and value to make any sense to anybody or anything other than myself and the .php script that's watching for it.
3. Probably your best bet for finding the above to monitor the network traffic to my server but even if you do find it, you will then need to figure out my SSH user login name, password, and root password (as described in my earlier post you can't just log in as root), and any failed attempts will be show up in my Logwatch report thus alerting me that you've found my port opener, and prompting me to change it.
Tuesday, 12 June 2007
Tightening Security on SSH & Webmin
I haven't finished moving everything over to my new servers yet however I am getting a few opportunities to look into new things and today I made a couple of changes to tighten up security.
In the greater scheme of things I'm not what you'd consider to be a prime target. I'm not mega-corp and I doubt there's anybody out there who hates my guts or wants to get into my systems in the hope of finding secrets. On the other hand, the fact that I am small-fry implies that I probably won't have paid too much attention to security issues and may be an easy target for being turned into a spam relay or similar i.e. the attraction of my server to a cracker is not what they might find on it, but what they might be able to use it for if they can get in.
A few days ago for example I awoke to a Logwatch report that telling me that another server at the farm where mine lives had made 400+ attempts to log into my server using SSH. I emailed tech support and got a reply about 15 minutes later saying that they'd checked it, shut it down, and emailed the owner. Now it's hardly likely that the owner of that server had instigated the attack, however they would be left with the big pain in the ass problem of finding out how their server was hacked and dealing with it. Obviously I want to do everything I reasonably can to make sure the same thing doesn't happen to me.
I am fortunate (by design) that I'm the only person who needs to log into my server. Thus I don't need to worry about other users having inadequate passwords or installing problematic scripts/programs. I have a firewall, and have shut down any services that I don't use (like telnet and ftp), so you might think I'd be happy to sit back an relax. However, as I am the only person who needs to use SSH or Webmin, (pretty powerful tools), I figuered that there were probably a few ways that I could make it harder for anybody to abuse them.
The most important line of defence is of course to have good passwords and if you don't know what I mean by 'good passwords', you need to do some research. If you are 99% sure that you do know: that's not good enough and you still need to do some research. If you are 100% sure then you are being way too arrogant and you still ought to do some research. The things is that this stuff changes and what we thought was a good password 10 years ago is mediocre by today's standards because the knowledge and tools available to the crackers is more powerful. Unless you did it just last week, do a search and read half a dozen current documents about passwords. If you find anything in any of them that you didn't know, read half a dozen more. My own current thinking on the subject can be found here.
Starting with SSH then:
It's fairly normal for my Logwatch reports to show a few hundred (occasionally a few thousand) failed attempts to log in via SSH. These are generally split between a dozen or so IP address (that change on a daily basis so there's little point trying to block the addresses), and several dozen common names. Amongst all the toms, dicks and harrys who don't even exist on my server (but are fairly common user names generally) there are also a good number of attempts to log in as apache, root, mysql, and other names that are pretty much always present on any LAMP server.
A fairly simple but substantial increase in security therefore is to create a user with a really weird name (that looks like a password), give them an equally cryptic password, and make them the only user with access to SSH. While brute force attempts to log in via SSH will regularly try lists of common names, they are highly unlikely to try 'random' collections of characters. You've now made it just as hard for someone to guess a user name as it is for them to guess a password. Of course this also means that when you log in via SSH you have to use the weird user name and su to root before you can do anything. A small price to pay and it also means of course that anybody who did guess your weird username and the weird password now needs to guess your root password too. That's "something blooming difficult" three times in a row and probably equates to something pretty near to impossible.
Of course that doesn't stop the failed attempts from bloating my Logwatch reports (something I'm looking into and will report on later) but it does mean that I can safely ignore them.
Having now made SHH a heck of a lot more secure, my other concern was Webmin. Again, I'm the only person who needs to use it but when I do I go in as root so there's 'only' a password between me any somebody else getting in there.
I did some searching and found this document (amongst others) that had some interesting information about securing Webmin. My setup was already doing things like using it with SSL however I did opt to go into Webmin: Webmin Configuration: Authentication and change the number of failed logins required before a host is blocked and the time for which it is blocked. These were set at 5 and 60 seconds but I reckon anybody who gets their password wrong five times in a row shouldn't be allowed anywhere near a server in the first place. As we're blocking IP addresses (as opposed to users) however we don't want an attacker who's accessing the server via somewhere like Tiscali or AOL causing an IP address that's been temporarily allocated from a pool being blocked for long periods of time either. As I'm the only one who should be using Webmin on my server I changed the values to 2 and 600.
In the greater scheme of things I'm not what you'd consider to be a prime target. I'm not mega-corp and I doubt there's anybody out there who hates my guts or wants to get into my systems in the hope of finding secrets. On the other hand, the fact that I am small-fry implies that I probably won't have paid too much attention to security issues and may be an easy target for being turned into a spam relay or similar i.e. the attraction of my server to a cracker is not what they might find on it, but what they might be able to use it for if they can get in.
A few days ago for example I awoke to a Logwatch report that telling me that another server at the farm where mine lives had made 400+ attempts to log into my server using SSH. I emailed tech support and got a reply about 15 minutes later saying that they'd checked it, shut it down, and emailed the owner. Now it's hardly likely that the owner of that server had instigated the attack, however they would be left with the big pain in the ass problem of finding out how their server was hacked and dealing with it. Obviously I want to do everything I reasonably can to make sure the same thing doesn't happen to me.
I am fortunate (by design) that I'm the only person who needs to log into my server. Thus I don't need to worry about other users having inadequate passwords or installing problematic scripts/programs. I have a firewall, and have shut down any services that I don't use (like telnet and ftp), so you might think I'd be happy to sit back an relax. However, as I am the only person who needs to use SSH or Webmin, (pretty powerful tools), I figuered that there were probably a few ways that I could make it harder for anybody to abuse them.
The most important line of defence is of course to have good passwords and if you don't know what I mean by 'good passwords', you need to do some research. If you are 99% sure that you do know: that's not good enough and you still need to do some research. If you are 100% sure then you are being way too arrogant and you still ought to do some research. The things is that this stuff changes and what we thought was a good password 10 years ago is mediocre by today's standards because the knowledge and tools available to the crackers is more powerful. Unless you did it just last week, do a search and read half a dozen current documents about passwords. If you find anything in any of them that you didn't know, read half a dozen more. My own current thinking on the subject can be found here.
Starting with SSH then:
It's fairly normal for my Logwatch reports to show a few hundred (occasionally a few thousand) failed attempts to log in via SSH. These are generally split between a dozen or so IP address (that change on a daily basis so there's little point trying to block the addresses), and several dozen common names. Amongst all the toms, dicks and harrys who don't even exist on my server (but are fairly common user names generally) there are also a good number of attempts to log in as apache, root, mysql, and other names that are pretty much always present on any LAMP server.
A fairly simple but substantial increase in security therefore is to create a user with a really weird name (that looks like a password), give them an equally cryptic password, and make them the only user with access to SSH. While brute force attempts to log in via SSH will regularly try lists of common names, they are highly unlikely to try 'random' collections of characters. You've now made it just as hard for someone to guess a user name as it is for them to guess a password. Of course this also means that when you log in via SSH you have to use the weird user name and su to root before you can do anything. A small price to pay and it also means of course that anybody who did guess your weird username and the weird password now needs to guess your root password too. That's "something blooming difficult" three times in a row and probably equates to something pretty near to impossible.
Of course that doesn't stop the failed attempts from bloating my Logwatch reports (something I'm looking into and will report on later) but it does mean that I can safely ignore them.
Having now made SHH a heck of a lot more secure, my other concern was Webmin. Again, I'm the only person who needs to use it but when I do I go in as root so there's 'only' a password between me any somebody else getting in there.
I did some searching and found this document (amongst others) that had some interesting information about securing Webmin. My setup was already doing things like using it with SSL however I did opt to go into Webmin: Webmin Configuration: Authentication and change the number of failed logins required before a host is blocked and the time for which it is blocked. These were set at 5 and 60 seconds but I reckon anybody who gets their password wrong five times in a row shouldn't be allowed anywhere near a server in the first place. As we're blocking IP addresses (as opposed to users) however we don't want an attacker who's accessing the server via somewhere like Tiscali or AOL causing an IP address that's been temporarily allocated from a pool being blocked for long periods of time either. As I'm the only one who should be using Webmin on my server I changed the values to 2 and 600.
Sunday, 27 May 2007
Fedora - The Wrong Hat
I've come to realise that I've made a mistake in moving to Fedora after somebody posted on http://www.fedoraforum.org/ about the imminent release of Core 7 and I asked how people go on for upgrading/reinstalling on servers when they can't afford much down time. The bottom line is that I shouldn't be using Fedora on such a machine.
It was explained to me (heaven knows how I'd missed it) that the whole idea of Fedora is that it is where all the front line cutting edge development is taking place and that while it's great for those who want to be involved with that, it's not the right choice for somebody who want's an as stable as it's possible to be platform on which to host business websites.
I was even more surprised to find that the guys on the forum suggested that I'd be much better off using CentOS i.e. the very OS that I've just moved away from (because I've always found it difficult to get information about it). Once again however, I've been making a big mistake in that my previous server was set up with CentOS and Blue Quartz and I failed to differentiate between the two. It seems that I must have done my searching on Blue Quartz because the only resource of any significance that I was aware of was bluequartz.org which is pretty useless. Had I gone looking for CentOS instead I would have found centos.org and two minutes reading the FAQ would have told me that CentOS is almost exactly the same as Red Hat Enterprise Linux so any book on RHEL would have told me what I wanted to know IF it were not for the Blue Quartz interface. Doh! It seems therefore that what I should have done, rather than moving to Fedora, was to move to another server with CentOS but without Blue Quartz and bought myself a book on RHEL.
Now that I'm here, and tied into a 12 month lease, I guess I'll just have to live with it however this shouldn't be too much of a problem. Since moving to Fedora I've learned quite a bit about the command line and that should stand me in good stead for moving back to CentOS (or indeed any other flavour of Linux) at the end of the lease.
I have to say however that once again I find myself being a little bit miffed at the company from whom I hire the server because, given the nature of Fedora as I now understand it, I'm inclined to question whether or not it is appropriate for them to be offering it as an option.
It was explained to me (heaven knows how I'd missed it) that the whole idea of Fedora is that it is where all the front line cutting edge development is taking place and that while it's great for those who want to be involved with that, it's not the right choice for somebody who want's an as stable as it's possible to be platform on which to host business websites.
I was even more surprised to find that the guys on the forum suggested that I'd be much better off using CentOS i.e. the very OS that I've just moved away from (because I've always found it difficult to get information about it). Once again however, I've been making a big mistake in that my previous server was set up with CentOS and Blue Quartz and I failed to differentiate between the two. It seems that I must have done my searching on Blue Quartz because the only resource of any significance that I was aware of was bluequartz.org which is pretty useless. Had I gone looking for CentOS instead I would have found centos.org and two minutes reading the FAQ would have told me that CentOS is almost exactly the same as Red Hat Enterprise Linux so any book on RHEL would have told me what I wanted to know IF it were not for the Blue Quartz interface. Doh! It seems therefore that what I should have done, rather than moving to Fedora, was to move to another server with CentOS but without Blue Quartz and bought myself a book on RHEL.
Now that I'm here, and tied into a 12 month lease, I guess I'll just have to live with it however this shouldn't be too much of a problem. Since moving to Fedora I've learned quite a bit about the command line and that should stand me in good stead for moving back to CentOS (or indeed any other flavour of Linux) at the end of the lease.
I have to say however that once again I find myself being a little bit miffed at the company from whom I hire the server because, given the nature of Fedora as I now understand it, I'm inclined to question whether or not it is appropriate for them to be offering it as an option.
Wednesday, 9 May 2007
php-gd - As Easy As Tea
I remember hearing a story about a guy who went to an airport in order to have a five minute conversation with another guy who was about to board a plane. Apparently the guy boarding the plane charged the first guy a hundred quid a minute for his time. A lot of dosh, especially twenty years ago when I heard this story, but according to the story the information was worth a lot more than that to the guy doing the asking.
Alas my endeavours with Fedora are not going quite so swimmingly as I had hoped. The whole point of switching to a server with Fedora was that it appeared to be much more widely documented than the CentOS Linux on my old server (see note [1]). Unfortunately, now that I'm trying to use that information I'm find it difficult to find the bits that I actually need amongst the masses of information that's out there. If you want a run through on how to install it you can take your pick but if you want to know something about a particular issue with regard to using it...
A good example is the fun I've had with the GD Library for PHP. Some of my scripts make use of functionality from the GD Library for manipulating images and while this was already set up on my old server it was not set up on the new one. The information on how to get it working was very difficult to track down. My books had nothing to say on the subject (or at least I couldn't find it) and the relevant websites (php.net, libgd.org and fedoraproject.org) assumed that I knew things about installing and configuring that I don't and in some instances made references to files and directories that are not on my server (presumably because the information relates to a differnent version of Linux).
In the end I put in a call to tech support at the company from whom I lease the server and was told to enter the following at the command line:
yum install php-gd
/etc/init.d/httpd restart
It was as simple as that. Yum installs the package and then you restart the apache server. Pretty obvious really, but things always are when you know. It also occurred to me this morning for example that there is nothing on the box of tea bags that says to put the bag into the cup and add boiling water as opposed to tearing open the bag and tipping the tea into the cup. Pretty much anything else would require us to empty out the contents from the 'sachet', but not the ol' tea bag. Obvious WHEN you know.
It seems therefore that until I become a lot more familiar with Fedora (and I'm only going to achieve that by using it) I'm destined to spend hours of my time digging through mountains of information in order to find the snippets that I need. I'm not saying that I could justify a hundred quid a minute but I'm very grateful to tech support right now.
Notes:
[1] See this post for why I've realised that this was a mistake.
Alas my endeavours with Fedora are not going quite so swimmingly as I had hoped. The whole point of switching to a server with Fedora was that it appeared to be much more widely documented than the CentOS Linux on my old server (see note [1]). Unfortunately, now that I'm trying to use that information I'm find it difficult to find the bits that I actually need amongst the masses of information that's out there. If you want a run through on how to install it you can take your pick but if you want to know something about a particular issue with regard to using it...
A good example is the fun I've had with the GD Library for PHP. Some of my scripts make use of functionality from the GD Library for manipulating images and while this was already set up on my old server it was not set up on the new one. The information on how to get it working was very difficult to track down. My books had nothing to say on the subject (or at least I couldn't find it) and the relevant websites (php.net, libgd.org and fedoraproject.org) assumed that I knew things about installing and configuring that I don't and in some instances made references to files and directories that are not on my server (presumably because the information relates to a differnent version of Linux).
In the end I put in a call to tech support at the company from whom I lease the server and was told to enter the following at the command line:
yum install php-gd
/etc/init.d/httpd restart
It was as simple as that. Yum installs the package and then you restart the apache server. Pretty obvious really, but things always are when you know. It also occurred to me this morning for example that there is nothing on the box of tea bags that says to put the bag into the cup and add boiling water as opposed to tearing open the bag and tipping the tea into the cup. Pretty much anything else would require us to empty out the contents from the 'sachet', but not the ol' tea bag. Obvious WHEN you know.
It seems therefore that until I become a lot more familiar with Fedora (and I'm only going to achieve that by using it) I'm destined to spend hours of my time digging through mountains of information in order to find the snippets that I need. I'm not saying that I could justify a hundred quid a minute but I'm very grateful to tech support right now.
Notes:
[1] See this post for why I've realised that this was a mistake.
Monday, 30 April 2007
Fedora Core 6
Given that I haven't said much about MacBooks or Fedora recently you would be forgiven for thinking that I'd given up on them. The reality is that the good ol' MacBook (yeah, coming on for 7 months old now) is doing splendidly and my 'Fedora Project' is well underway. The Fedora thing went off in an unexpected direction though:
The plan, after buying a copy of "Run Your Own Web Server Using Linux & Apache" was to install Fedora Core 4 on an old desktop PC so I could familiarise myself with it before switching my online web server over to it. However, we then decided to move house, had a barrel of laughs when a burst pipe in the loft soaked the place (on the day we moved in), and in the meantime observed that Fedora is currently up to Core 6 with Core 7 on the horizon. Then the folks I hire my server from came up with what must be the stupidest special offer in the history of dedicated server leasing: "hire one, get one free". I mean, whose going to be able to make sensible use of an offer like that? Well, me actually.
The lease on my old server was due for renewal so I renewed it for just a couple of months and took up the special offer (so I currently have three servers). What I've done is to put three of my 'play' sites on one server while my 'important' sites are going on the other. At the moment I'm just concentrating on getting everything moved over before the contract ends on the old server but when I'm done I'll be able to use the 'play' server to try things and learn the ins and outs of the OS with no fear of accidentally taking the 'important' sites off-line if I mess up.
The reason I haven't blogged about this to date is that I don't anticipate that it would be a whole lot of use to anybody. I didn't actually have to install Core 6 because the servers were supplied with it already installed. They were locked down such that the only way in was through SSH so I've had to go in, open other ports, start httpd, sendmail, mysqld etc. Not a lot of point me documenting that here (I've made notes for my own future reference) because unless you, dear reader, were to hire exactly the same type of server from the same company the chances are you'd be looking at a (slightly) different list of things to check off your to-do list in order to get up an running.
I will be blogging about some of my endeavours with Fedora as and when I anticipate that it may be interesting and/or useful for others. For example I bought four books (two about Fedora Core 6 and two about Webmin) whose usefullness I will no doubt comment upon at some point. In the meantime I'm just quietly getting on with it.
The plan, after buying a copy of "Run Your Own Web Server Using Linux & Apache" was to install Fedora Core 4 on an old desktop PC so I could familiarise myself with it before switching my online web server over to it. However, we then decided to move house, had a barrel of laughs when a burst pipe in the loft soaked the place (on the day we moved in), and in the meantime observed that Fedora is currently up to Core 6 with Core 7 on the horizon. Then the folks I hire my server from came up with what must be the stupidest special offer in the history of dedicated server leasing: "hire one, get one free". I mean, whose going to be able to make sensible use of an offer like that? Well, me actually.
The lease on my old server was due for renewal so I renewed it for just a couple of months and took up the special offer (so I currently have three servers). What I've done is to put three of my 'play' sites on one server while my 'important' sites are going on the other. At the moment I'm just concentrating on getting everything moved over before the contract ends on the old server but when I'm done I'll be able to use the 'play' server to try things and learn the ins and outs of the OS with no fear of accidentally taking the 'important' sites off-line if I mess up.
The reason I haven't blogged about this to date is that I don't anticipate that it would be a whole lot of use to anybody. I didn't actually have to install Core 6 because the servers were supplied with it already installed. They were locked down such that the only way in was through SSH so I've had to go in, open other ports, start httpd, sendmail, mysqld etc. Not a lot of point me documenting that here (I've made notes for my own future reference) because unless you, dear reader, were to hire exactly the same type of server from the same company the chances are you'd be looking at a (slightly) different list of things to check off your to-do list in order to get up an running.
I will be blogging about some of my endeavours with Fedora as and when I anticipate that it may be interesting and/or useful for others. For example I bought four books (two about Fedora Core 6 and two about Webmin) whose usefullness I will no doubt comment upon at some point. In the meantime I'm just quietly getting on with it.
Thursday, 19 April 2007
Counting The Days
On my old Diary of a Mac Virgin Blog I implemented a 'counter' to show how long since I became a Mac user. That's kind of old hat now however, as I bought a VW Beetle yesterday, and hired a server running Fedora Core 6 about a week ago, I figured that I'd recreate the counters here (in the right hand column along with the links and stuff).
My intention to switch to Fedora and to buy a bug were a major part of the reason for my switch to this blog - because I want to document my endeavours with those in the same way I did on the old blog for my introduction to the Mac. I'll say more about both in the near future but for now I just wanted to implement the 'counters'.
My intention to switch to Fedora and to buy a bug were a major part of the reason for my switch to this blog - because I want to document my endeavours with those in the same way I did on the old blog for my introduction to the Mac. I'll say more about both in the near future but for now I just wanted to implement the 'counters'.
Subscribe to:
Posts (Atom)