Page 1 of 1
Securing an admin section
Posted: Mon Aug 27, 2007 9:31 am
by shiznatix
Ok so my company has a website and all the admin abilities such as adding news, confirming users, and basically everything is in the admin section. The admin section is basically another set of scripts that are used to manipulate the database but the thing is that the admin section is only behind a single login page and that it uses sessions to make sure that the user belongs there in the first place. Before any page is executed, it runs a check to make sure their session is set but I feel this might not be too secure. I am thinking of ways to make sure page supra secure but I need some more minds behind this one. Ideas and reasons they are not perfect that I have had are:
-Only allow access from our office IP address. Since the section is only used from our office, if I checked to make sure the IP address using this section was ours, I could make sure nobody outside our walls was trying to be sneaky. Problems with this is our IP address would not be difficult to discover and thus an attacker could spoof using our IP.
-HTTPS. This would be good because its encrypted but not really useful since we don't use wireless and so it would be super difficult to scan our network activity.
-Only allow 5 login attempts to keep out brute forcers. This is good but couldnt you just spoof a different IP address each 5 attempts to make it look like it is coming from a different place each time you get banned?
Thats basically all I got right now. If anyone can throw some ideas this way that would be grand.
Posted: Mon Aug 27, 2007 10:49 am
by jason
I'd suggest going the firewall route, but I sense this is overboard (assuming you are just working on a shared server environment). In this case, going the simple route of IP address restriction as well putting the site behind SSL (not a bad idea regardless, if the site deals with any user data). Other things you can include that are simple are:
1. Including a CAPTCHA at login.
2. Force logouts due to inactivity.
3. Internal revalidation. If someone wants to make a serious change, force them to revalidate.
4. Your limited login attempts is another good idea. Apply it on a per account basis.
5. Delay login attempts. Simply make each login take a long time, like 5 seconds.
6. If you are doing 4, this assumes they know what loging they are looking for.
7. Internal permissions. Just because you are logged in doesn't mean you should have the same access as everyone else.
Most compromises of systems are inside jobs. People that are aware of the system. The best thing you can do is limit what data people have access to via a backend. Really decide what is and what is not needed for each person with access.
Posted: Tue Aug 28, 2007 7:54 am
by shiznatix
Ok I think I have myself well strapped in for now but the only thing I have a question about is, if I use usleep for a few seconds before processing the $_POST stuff, does that really help?
Posted: Tue Aug 28, 2007 8:20 am
by VladSun
1. Spoofing IP address is not an easy thing to do ...
2. What about using VPN which IP range is the only one allowed to have access to your login page (by using Limit/Deny options in Apache configs)?
Posted: Tue Aug 28, 2007 9:46 am
by jason
shiznatix wrote:Ok I think I have myself well strapped in for now but the only thing I have a question about is, if I use usleep for a few seconds before processing the $_POST stuff, does that really help?
Sorry, maybe I should be more clear. While this isn't a security method (it's a deterrent), it's still useful. The reality is, deterrents are useful. It's like obscurity. Security through obscurity is not smart, but obscurity doesn't hurt. It just adds extra steps.
Anyways, delaying login, what I mean is, let's say you get a brute force attempt that is local (inside the IP range of approved IPs that can access the admin. You simply lock out logins for a period of time. So if your system detects 5 failed logins in the course of 5 minutes, or 10 minutes, or whatever, you stop logins unless manually overridden. You could go even further, and determine the lock out level for various infractions such as not using an existing username.
In all cases, the error message should remain the same. Each attempted login looks like the previous attempted login. It's just all ability to login is prevented, even legit ones. This is where you come in and manually override things. Check to make sure the login attempts (which you are logging) are legit.
Posted: Tue Aug 28, 2007 11:46 pm
by hongster
jason wrote:Most compromises of systems are inside jobs. People that are aware of the system. The best thing you can do is limit what data people have access to via a backend. Really decide what is and what is not needed for each person with access.
I agree with that. There are 2 parts to computer security: mechanism and policy. Policy must carefully planned and managed. Have you heard of the "
need to know principle"?
Posted: Wed Aug 29, 2007 4:42 am
by Jenk
VladSun wrote:1. Spoofing IP address is not an easy thing to do ...
1) Easier than you think
2) It can be done. "If it can, it will." is the attitude to take when considering security.
Posted: Wed Aug 29, 2007 5:01 am
by VladSun
Jenk wrote:VladSun wrote:1. Spoofing IP address is not an easy thing to do ...
1) Easier than you think
2) It can be done. "If it can, it will." is the attitude to take when considering security.
1. Where - in LAN, WAN, MAN ?
2. That's why I suggested using VPN ...
Posted: Wed Aug 29, 2007 9:34 am
by Jenk
VladSun wrote:
1. Where - in LAN, WAN, MAN ?
Anywhere.
VladSun wrote:2. That's why I suggested using VPN ...
Indeed.
Posted: Wed Aug 29, 2007 10:03 am
by VladSun
@Jenk
Well, shiznatix didn't provide enough information. I supposed that there would be 2 cases:
1) that the "our office IP addresses" are from a private subnet. If it is true, IP spoofing is not an issue, because private IPs are not routed by ISPs.
2) that the "our office IP addresses" are from a public subnet and there is a router in front of it. Proper configuration of the router will eliminate the IP spoofing issue.
My VPN suggestion was to cover cases where one should be able to access this www backend outside the office area.