bowlesj wrote: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.
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 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.
bowlesj wrote: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.
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.
bowlesj wrote: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.
As a temporary thing? Eh, alright.
bowlesj wrote: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.
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.
bowlesj wrote:Maybe no one knows this much about it.
It's the kind of thing you gather and learn over time, not download and memorize.
bowlesj wrote: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.
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.
bowlesj wrote: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.
bowlesj wrote: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?
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