PHP Developers Network

Hi, I have it on my 87 long security list to look at this so I finally did. I was looking through the /var/log/httpd/error_log file and I noticed hacker attacks on the database (or just generally). After setting up fail2ban to block IP addresses related to SSH access and also seeing all these other IP addresses trying to go after the Apache database (or whatever they are doing) it finally occurred to me that except for (direct logging in to my database via my website PHP software) there is only one valid IP address (my home public ip address). Considering this, logically can I not set up iptables to block every single ip address other than my home IP address? Related to this can I not do this for every single software that I might in the future consider using that is not considered public access such as my website (or maybe in the future postfix email but for now I am only using outgoing email)?

Thanks,
John

If you do actually know what you're talking about, you're using very much the wrong terminology.

You could use iptables to restrict access, yes, but what happens if your IP address changes? You'll be locked out.

Use keys for SSH access, make sure you've disabled password login too, and check for vulnerabilities. Otherwise, personally, I would ignore it. fail2ban helps but having a machine connected to the internet means it will be probed and the only way to avoid that is to not have it on the internet.

Hi requinix, you are correct. I am learning this stuff. I am on a very low end VPS and have a database out there that has test data (not too worried yet). It is a learning stage. I am not marketing my website yet. It can't even be found on Google - LOL and I am glad about that. Once I am confident that website is secure I will start the marketing. This much is well thought out.

Yes I saw this. I was noticing that the probs from one specific IP address took place over a few weeks and they managed to kick out errors which has actual names of the MySql database fields. This is the error messages that got me very interested in blocking this IP address. I would like to know exactlly how they did this and exactly how I can block this and if they can see the names of these database fields.

It did occur to me that I could get locked out since I was reading that the service provider can change your ip address. So it then occurred to me that this may be the reason that they sell static IP addresses and maybe it would be just a lot simpler a lot faster and a lot more effective and a lot faster for the machine to get a static IP address and block every other IP address. I am asking about this because when I issue the "iptables -L" command the fail2ban ip addresses that have been blocked come up incredibly slow. Right now because of restarts they get flushed and there are not hundreds or thousands yet. So I am thinking if buying a static IP address for $5.00 a month would allow me to put in my IP address it could create a very fast solution that would buy me time to learn to put in more security measures (from my list of 87). At the same time if this technique works and render's all other (or most) techniques obsolete why bother.

Regarding the keys. I am aware of this technique and it is in my list of 87 techniques that I have read about (an overview read). It will be a little while before I get to that one (I was hoping later this week actually) and it does no real harm (even if life is very short) to learn this stuff (if I must). So that leads to a very good question. Is there a sorted list of all techniques for security with reasons why they are in the order they are in. Maybe no one knows this much about it. It is an interesting question. I would love to read such a document and as part of reading it I would love to know if buying a static IP address and blocking all other IP addresses is at the top of this list and why and if it is not at the top then why not. So I assume on this list a dynamic IP address would be at the bottom of the list (or not even on it - LOL) and a static IP address might be near the top of the list.

The other thing I am trying to learn is if a hacker can get database field info (a hack in my mind since I don't want them to know this) without being able to get root power to take over the machine and if this static IP address idea I have would stop this? I hope to know this by today if I can (or by this week at least).

Look at your access logs at that time to see what URLs they were hitting. If they POSTed data you won't be able to see what, but at least you'll know what pages they were submitting to. (They generally don't bother with POSTs though.)

For the errors, you may have "...or die(mysql_error())" type code lying around. Get rid of that: besides the poor user experience, it reveals error information as you've seen. On a related note, make sure you have your display_errors php.ini setting turned off.
Better would be to log the problematic query somewhere, be that through PHP's error log (like using trigger_error or error_log) or something else, then have your code try to recover however possible; for really bad errors it's forgivable to "or die('Internal error')" - the same pattern as before but at least you're not exposing important information. Well, forgivable for the short term, really should have proper error recovery.


You could use a static address that way, yes. They tend to be used more for websites because there must* be a static IP address as the DNS entry for the very top-most domain name.
But if you ask me it's not worth the added cost. What if you discover that you're away from home (eg, work, vacation) and you need immediate access? You're stuck. Believe me: fail2ban watching the Apache and SSH logs will go a long way.


As a temporary thing? Eh, alright.


Not anywhere I've ever heard of. There's just too much stuff with too many exceptions and they aren't all applicable in every situation.

There is no magic bullet, let alone instructions on how to create a magic bullet.


It's the kind of thing you gather and learn over time, not download and memorize.


Because there are very few cases where you want a server on the internet granting access to only a few people and those people are able to get static IP addresses. It's simple for allowing just you but it can rapidly become a burden if the situation ever changes.


Hardly.


1. Database field information is easy to guess just by looking at a site for a while. The field containing the name of the user will be "user" or "username", the column containing the password (plaintext or not) will probably be "password", the table containing user information will probably be "user" or "users", and so on. And that's assuming you're not using some open-source software.
2. Knowing the database structure is undesirable but it doesn't do them much good unless they can put that information to use via SQL injection or with database access or another way.
3. Root access is only available if someone can SSH into your machine. And if they can SSH at all, even just as an underprivileged user, assume they know of an exploit which will give them root access.
4. A static IP address will not make a difference to any of this.


* Basically.

Thanks for responding. That was quick. I will have to study it more thoroughly today after eating.

I wll go back to the error logs to look for what you suggest. I searched for a sorted list of security techniques just for the heck of it. As expected I did not find it but I found a very interesting pdf on log file hacker attacks. The person appears to have credentials. Here is the link just in case it is useful.
http://www.sans.org/reading-room/whitep ... files-2074


Yes, I changed my PHP code to call an error routine (pulled it directly from a google search example on error reporting best practices from a New York PHP website or something). It works great. I was thinking of doing this but finding the same idea was even better since they knew how to get a dump into the email which I could never have done. They suggested I give the user a special page. I decided to give them critical info and allow them to contact me if they wish since sometimes knowing what they were doing is critical to figuring out the bug (been programming 34+ years and I know this well). So they do not see any details as to the error. I did turn error reporting off (as the people suggested). I think it is set up properly but I noticed I don't have a PHP log file even though it is turned on and there is a path to it. I need to figure this out yet (lots to do). So in a sense have a bit of security here.

Regarding the Static IP Address Idea, I could get in to the website from 3 other locations and I am gathering their IP addresses now. I tend to be around (not much of a traveler at this point at least). So if I got locked out at one I could within 20 minutes get in from another one and fix the situation (I am a sneaky bugger - LOL - and ideas flow like water with me which is why I have a clipboard beside the bed at all times and I am constantly having to replace the supply of paper). But again as you point out using this alone may not be wise. Ironically, if I use it and it if completely block hacks on the MySql database but for reasons as you suggest I decide to stop using it them I loose the opportunity to learn about these hacks when I currently have the time to do so.

Time to eat properly.

Thanks again for your suggestions,
John

To be clear, that's setting display_errors=off. Leave the error_reporting setting where it is.


By default PHP will pass its log messages up to Apache, so they'll end up in Apache's error log.


Would have been worth pointing out earlier: MySQL should not be accessible externally. At all. It should only be listening for local connections (either a Unix socket for best performance, or TCP/IP listening on 127.0.0.1:3306) and the user configuration should only allow people "@localhost".

Hi requinix, Now that you mention that the php errors end up in the Apache error_log file, I remember seeing some of them labeled as PHP yesterday in that file. I guess it is better to have them all in one place since they work hand in hand. My settings are below and the last entry is what made me think they should be going in that file.


My webpage errors are clearly coming to me in the email and the user only sees the special error page. Here is the web page I got my error handler from. http://nyphp.org/PHundamentals/7_PHP-Error-Handling
It works flawlessly and a huge improvement over what I was doing before. So I did a big upgrade pass through all my web pages to put it in (4 hours, not a problem).


Regarding:
I have to laugh at myself - LOL. Don't laugh too hard. I just figured out who this hacker was. It was me! It took me long enough to figure this out - LOL. I switched service providers in march 11th (exactly the time this hacker stopped hacking - LOL - go figure -). In other words my public IP address changed that day. So all the errors were my trying to get pages to work and the errors were going to the Apache error_log file. Most were caused by xampp being very loose about upper/lower case when I was programming on local host where as Linux has no tolerance for this. So I am now officially the worlds worst hacker - LOL - couldn't hurt a fly if I tried However, on second thought, in my defense I probably would have caught on quicker if the PHP errors were going to the PHP error log file as they did with xampp on local host.

These are the types of errors that are not from me that are appearing in the Apache_log file.


Regarding:

I sort of understand what you mean but do not understand the details (I have been a very sheltered programmer for 34+ years with no need to know unix sys admin or networking until I undertook this website project - although I did go on a Linux bash/sed/awk learning tangent 14 years ago and learned it well). So (being the worlds worst hacker - LOL) my question is this? Do the above six client IP requests (in the quote) represent an attempt to hack? I did open up my permissions in /var/www/html/ due to a problem I was having. I realize is a security risk and I need to set them back. I am reading this page to learn to do this.
http://serverfault.com/questions/357108 ... -webserver
I don't actually understand how hackers can get at these files directly if they can't get in as a Linux bash user via SSH. So put another way, (although turning off passwords and using a key is what everyone says to do) in the mean time until I learn to do this, are you saying there is no real point in changing fail2ban to track the Apache log file to ban IP addresses in the iptables?

For the favicon.ico and robots.txt, you should create those files. For the others, they will just happen. You can deny from IP address in you configuration file, but only if you get scanned by the same IPs all the time.

For SSH, you might want to thing of changing the port it listens on to some random high number port. Then the default port will not respond. That way if you IP changes, you can still login -- unless you forget the port.

_________________
(#10850)

Thanks Christopher. I will have a look at your suggestions tomorrow. I am trying to split my days between security and updating data on my database hoping when I get the data up to date I will have enough security in place to go ahead and draw attention to the website from potential normal users. John.

First, Apache is logging those messages. So that should be a clue that it has something to do with requests to your web server. Apache is logging what the URLs translated to as files, since it has to actually figure out files for each request, and then reporting that it couldn't find the file as requested. No one is directly accessing files.

As Chris said, you should have a favicon.ico and a robots.txt. Those are normal things every site should have. The other requests are probing your site, but as you can see the IP address changes a lot so there's not much point to blacklisting specific addresses.

Thanks guys. I don't totally understand everything but I will use Google searches to fill in the holes (I like to respect people's time and minimize my questions). Earlier today I looked up the favicon.ico file and learned it is for the icon in your browser's location bar. This website explains how to create it. http://www.thesitewizard.com/archive/favicon.shtml I put it on my todo list for later since My website seems to be working (meaning I can drag the icon and get an icon on the desktop that does lead to my website). It is not fancy but it works. I will look up the other files Tomorrow.

I fully intended on not making this website a pretty or fancy website. I mainly want the pages to come up fast and I mention that up front in the home page (a marketing approach). I can say one thing. The home page pops up faster than most others I see these days. I got into this way of thinking because some of my pages do way more processing that most and I worry about those pages if this website gets busy. Part of making it fast is making sure it does not get hacked (making sure it is not used to send out spam etc). I just need to know enough to know I don't need to do any more. I am not storing credit card information on purpose for example as a way to reduce the amount I need to know.

Thanks again,
John

A bit more because I got curious. I just did this search
cat error_log | grep 'favicon.ico'

After doing the search I have found that when I open my home page I too get this error. However I noticed/realized that it is not in fact an error. It simply states that this file does not exist. So it is implying that it is not an error and it is also not even a warning. It is a notice only. So the person who programmed Apache is thinking (exactly as I am thinking) that it is not really that important but you might want to consider having an icon for your website (for pretty marketing reasons if that is important to you that is). I personally think the Apache programmer would have been better to take it even lower and just ignore the fact that this file does not exist and let those who care about this stuff take the time to figure out how to have such an icon on their web page. But it is not a big deal. When I set up the system to limit the size of the logs properly (again a focus on efficiency since reducing space available for swap could slow things down) this will not be much of a problem if any. It seems that people are in fact discovering my website by accident (not hackers at all). Now I am really curious as to what these other files are for (lets hope google has the answer). This is all good. It means I need not panic about being hacked except for on the SSH side. The adventure continues - LOL - lots of fun.

I think you misunderstand. No "Apache programmer" made a decision here. This is information you can log or not log. The logs can be completely customized. It is up to you. It is just information. The fact that web browsers all check for favicon.ico so they can put a little icon image next to the title of the website has nothing to do with Apache. All Apache is reporting is that a requested file is missing. It cannot know which missing file is of interest (or not) to you.

Keep learning. And when you come upon things like this, remember that that "Apache programmer" or Linux, PHP, Javascript, etc. developer, was much more knowledgeable that you. So there is probably a good reason, even if you can see it right now.

_________________
(#10850)

Thanks Christopher. It just occurred to me when I woke up that is is a good idea to have it since (if it creates an icon on the desktop that stands out as different and associated with your website) then it will in fact speed the user up. I will check into the other missing files. Anyway, back to bed to get more sleep before starting another day. John.

I did a few things.
**I set up a secure user (one with a long random user name and with a long random password)
**I disabled root access
**I set up the SSH key authentication
**I set PasswordAuthentication no

It is working (I can get in with Putty and with WinSCP using the SSH private key pass phrase).

I have a few questions.
**Will I see anything in the log files with these brute force attempts? (not seeing many now since the fail2ban is blocking their IP addresses).
**Is there any real need for fail2ban now? Currently brute force attempts are down to about 1 every 2 hours due to the iptable entries created by fail2ban.
**Would anyone be interested in seeing my full security list which has my priority settings (I will clean it up a bit if I post it). I have no idea if the priorities are correct (just a guess).
It might open up an interesting discussion (probably mostly over my head - LOL). I could post the spread sheet that it is from which shows the location of the info.

Thanks John.