Ip falsification question
Moderator: General Moderators
- ColonelSandersLite
- Forum Commoner
- Posts: 35
- Joined: Sun May 09, 2010 1:32 am
Ip falsification question
I'm by no means a security *expert*, so I thought it would be best if I asked for independent confirmation of this idea.
I'm doing an ip check in the administration section of a current project. The administrator has a known static ip address which all administrative pages look for. I know that this will not protect against csrf, xss, sql injection, attacks aimed at getting shell access, etc. I believe, however, that this should be a fairly reliable method of preventing someone from just typing http://www.example.com/administration/ into the url and then brute forcing (or sniffing or whatever) the password.
Am I correct in thinking that while a cracker can potentially tunnel and such to mask his ip address, he cannot have his ip reported as whatever he wants? At least not without doing something along the lines of installing something on the machine using the specified ip address and tunneling his connection through that.
In other words, is this idea solid or not and are there any pitfalls anybody can think of?
The biggest things I can think of to watch for are:
1: As mentioned, it does not protect the site from a large number of attack types, but should instead only be treated as a *part* of the security system.
2: Considerations should be made that the ip can be changed without jumping through too many hoops in the even that it's required. I currently have a flat file in a hidden location which contains this information and is modified through ftp.
I'm doing an ip check in the administration section of a current project. The administrator has a known static ip address which all administrative pages look for. I know that this will not protect against csrf, xss, sql injection, attacks aimed at getting shell access, etc. I believe, however, that this should be a fairly reliable method of preventing someone from just typing http://www.example.com/administration/ into the url and then brute forcing (or sniffing or whatever) the password.
Am I correct in thinking that while a cracker can potentially tunnel and such to mask his ip address, he cannot have his ip reported as whatever he wants? At least not without doing something along the lines of installing something on the machine using the specified ip address and tunneling his connection through that.
In other words, is this idea solid or not and are there any pitfalls anybody can think of?
The biggest things I can think of to watch for are:
1: As mentioned, it does not protect the site from a large number of attack types, but should instead only be treated as a *part* of the security system.
2: Considerations should be made that the ip can be changed without jumping through too many hoops in the even that it's required. I currently have a flat file in a hidden location which contains this information and is modified through ftp.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Re: Ip falsification question
My main concern would be the possibility of the administrative user's IP changing. Also, I wouldn't doubt the capability of a user to fake their IP. Your server trusts the client to provide correct information, but that information is still ultimately provided by the client.
Usernames and passwords haven't failed us yet. If you are really interested in beefing up your security, I would create more hoops rather than less. Use a username and password combination with the IP address. Then if the username and password are correct and the IP is not, create a security code that only the administrator would know. Also, put a captcha on the main login for any account that hasn't been logged into after 2 or 3 failed attempts. Or, if you are a 24/7 company, lock the account and require phone confirmation from the account's main phone number.
Resorting to one means of identification is, in my opinion, lazy. Jobs ask for two forms of ID. You should ask for more than just an IP.
Usernames and passwords haven't failed us yet. If you are really interested in beefing up your security, I would create more hoops rather than less. Use a username and password combination with the IP address. Then if the username and password are correct and the IP is not, create a security code that only the administrator would know. Also, put a captcha on the main login for any account that hasn't been logged into after 2 or 3 failed attempts. Or, if you are a 24/7 company, lock the account and require phone confirmation from the account's main phone number.
Resorting to one means of identification is, in my opinion, lazy. Jobs ask for two forms of ID. You should ask for more than just an IP.
Re: Ip falsification question
superdezign is probably more expert on security than I am, but I thought I would just add that I agree that a good standard login with a stored, encrypted password that meets some standard for passwords, would provide better security than an IP address. Among other considerations, using an IP address gives you absolutely NO assurance that the PERSON is authorized. Anyone using his computer, or even possibly piggy-backing on his wi-fi, would have immediate access. I don't think I'd do it that way.
- ColonelSandersLite
- Forum Commoner
- Posts: 35
- Joined: Sun May 09, 2010 1:32 am
Re: Ip falsification question
Yes, I'm *still* doing a proper password authentication besides the ip check. I'm not sure why the you guys would assume I'm not. I don't *think* I implied that but if I did, it was not my intention.
When I coded it, I was thinking that it would be a fairly bullet proof shield as I had not ever heard of someone making their ip be whatever they want before. After a while, I started to get a little paranoid and thought I would ask here. ATM, it's at the least another security layer that at least doesn't detract from the overall security scheme. At the least it should keep any script kiddies out of the administration section I think. Mostly, I want to know if it's worthwhile to put the effort into possibly expanding upon the idea in the future (it's pretty basic right now) and/or implementing it in future projects as well.
This is actually exactly my line of thinking. Asking for a simple username/password combination *is* asking for one form of id and there are all sorts of ways around this depending on design (sql injection being a perfect example, also brute force being another). Checking the IP *before* you even ask that question is an added layer.superdezign wrote:Resorting to one means of identification is, in my opinion, lazy. Jobs ask for two forms of ID. You should ask for more than just an IP.
Given that tcp is a 2 way communication stream, can an attacker actually make his ip address into whatever he wants (let's say 123.456.789.01 for example) and *still receive information*? I know it is entirely possible to tunnel through a remote address but that's not actually picking your ip, just using what's available. If it is possible to do this, are there any countermeasures that can be taken? Let's run with the assumption that the hypothetical attacker has not managed to install some malware on the admins computer which he can then tunnel through. If this has happened, it's very likely that a password won't stop them either, at least not for long. Any further information, such as suggested reading, on how this can be done and and prevented would be greatly appreciated.superdezign wrote:Also, I wouldn't doubt the capability of a user to fake their IP. Your server trusts the client to provide correct information, but that information is still ultimately provided by the client.
When I coded it, I was thinking that it would be a fairly bullet proof shield as I had not ever heard of someone making their ip be whatever they want before. After a while, I started to get a little paranoid and thought I would ask here. ATM, it's at the least another security layer that at least doesn't detract from the overall security scheme. At the least it should keep any script kiddies out of the administration section I think. Mostly, I want to know if it's worthwhile to put the effort into possibly expanding upon the idea in the future (it's pretty basic right now) and/or implementing it in future projects as well.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Re: Ip falsification question
Well, if our only concern is the secureness of placing the IP address as the first layer of the log in process, I'd still recommend against it. Depending on their ISP or if they are sharing their connection with others, other users could have the same IP address as them. The only other way (that I'm aware of) to mimic a specific IP address is to gain access to a machine that is using that IP address. And, again, depending on their ISP, it is possible that their IP address could change.
I'm not saying that these are deal breakers or likely occurrences, but that they are possible. Again, my main concern would be their IP address changing rather than someone using their IP address. Most clients are incapable of fixing the code in the event of their IP address changing if you are unavailable to do it for them. Plus, who knows complications await us with IPv6. lol
I'm not saying that these are deal breakers or likely occurrences, but that they are possible. Again, my main concern would be their IP address changing rather than someone using their IP address. Most clients are incapable of fixing the code in the event of their IP address changing if you are unavailable to do it for them. Plus, who knows complications await us with IPv6. lol
Re: Ip falsification question
You must also be aware that using the IP address as part of your authentication requires the user to always use the same connection. That may or may not be an issue, but most people want the flexibility to use their laptop from a different physical location. I don't have knowledge of whether an IP address can be spoofed, but I would think that would not be possible, since that's where the replies must be sent, so if it were possible to spoof it, then all the return data would be sent to the spoofed address (the valid user).
- ColonelSandersLite
- Forum Commoner
- Posts: 35
- Joined: Sun May 09, 2010 1:32 am
Re: Ip falsification question
The ip changing and the issue of wanting multiple connection sites have been considered and accounted for. Accessible through ftp, there's a simple flat file which lists the ip addresses which are able to connect to the site (at one per line). example:
[text]111.111.111.111
222.222.222.222
333.333.333.333[/text]
This user is fully capable of changing this and is knowledgeable enough to understand that you don't want more ip addresses in there than you need.
In this case at least, the ISP is pretty serious about not changing a persons IP address. But sure, wanting to temporarily add an ip to the list if, for example, you're working from a hotel that night is still easily doable with the current software. Since it might be an issue in future projects, I should probably add the ability to allow for ranges and such at some point.
I also happen to know that the ISP does not share ip addresses. Even if they did however, that ip address would only happen to work with the isp's customer base, which happens to be a much smaller number than every valid ip address known to man. So if it can keep 95% (a number I pulled out of my rear admittedly, the isp surely is not serving 5% of all internet users) of all possible attackers out of that section, I just have to worry about that other 5%. Even if the ip address was shared, what are the odds that there is a hypothetical attacker who happens to have the same shared ip address, wants to break into your site, and has the know-how to actually get past the password security. I'd say that's pretty slim. The most likely scenario I can think of is someone from inside the company wanting to be malicious and that *really* narrows down the list of suspects down if it actually happens. I could also see a vindictive ex who happens to know your password and wants to be more creative than trashing your car
. I mean hey, the realities of security dictate that we're working with probability percentages weighed against the value of what we're protecting and the cost to add more protection right? In other words, I'm not going to guard my car keys with the same security the Smithsonian has on the hope diamond. Sure, I'm using proper encrypted password protection, but this was actually a just a quick and dirty method of helping make sure it stays secure.
The ipv6 mess is a very valid and concerning can of worms though. I should probably look into that and see if I can't do *something* to ensure that it will be able to work with this when the time comes. Seriously, thanks for pointing that one out as I had completely neglected to even think about it.
[text]111.111.111.111
222.222.222.222
333.333.333.333[/text]
This user is fully capable of changing this and is knowledgeable enough to understand that you don't want more ip addresses in there than you need.
In this case at least, the ISP is pretty serious about not changing a persons IP address. But sure, wanting to temporarily add an ip to the list if, for example, you're working from a hotel that night is still easily doable with the current software. Since it might be an issue in future projects, I should probably add the ability to allow for ranges and such at some point.
I also happen to know that the ISP does not share ip addresses. Even if they did however, that ip address would only happen to work with the isp's customer base, which happens to be a much smaller number than every valid ip address known to man. So if it can keep 95% (a number I pulled out of my rear admittedly, the isp surely is not serving 5% of all internet users) of all possible attackers out of that section, I just have to worry about that other 5%. Even if the ip address was shared, what are the odds that there is a hypothetical attacker who happens to have the same shared ip address, wants to break into your site, and has the know-how to actually get past the password security. I'd say that's pretty slim. The most likely scenario I can think of is someone from inside the company wanting to be malicious and that *really* narrows down the list of suspects down if it actually happens. I could also see a vindictive ex who happens to know your password and wants to be more creative than trashing your car
The ipv6 mess is a very valid and concerning can of worms though. I should probably look into that and see if I can't do *something* to ensure that it will be able to work with this when the time comes. Seriously, thanks for pointing that one out as I had completely neglected to even think about it.
califdon wrote:I would think that would not be possible, since that's where the replies must be sent, so if it were possible to spoof it, then all the return data would be sent to the spoofed address (the valid user).
This is basically the confirmation I was looking for and what I was thinking when I decided to do the check in the first place. And again, if someone has access to the admins machine (and the knowledge to use it), they probably have the keys to the castle anyways and just cannot be stopped at this security layer. Unless someone chimes in with knowledge to the contrary, I'll just run with it I guess.superdezign wrote:The only other way (that I'm aware of) to mimic a specific IP address is to gain access to a machine that is using that IP address.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Re: Ip falsification question
That's true. Although, it raises the question of why you feel that IP addresses need to be checked at all, especially with their obvious inflexibility. For usability, couldn't you go the security code route where unrecognized IPs require a security code and, upon submission of a valid code, the IP is saved as a valid one?ColonelSandersLite wrote:I mean hey, the realities of security dictate that we're working with probability percentages weighed against the value of what we're protecting and the cost to add more protection right? In other words, I'm not going to guard my car keys with the same security the Smithsonian has on the hope diamond.
Fingerprints and retina scans. I'm sure there are ActiveX objects for those by now. lolColonelSandersLite wrote:And again, if someone has access to the admins machine (and the knowledge to use it), they probably have the keys to the castle anyways and just cannot be stopped at this security layer. Unless someone chimes in with knowledge to the contrary, I'll just run with it I guess.
- ColonelSandersLite
- Forum Commoner
- Posts: 35
- Joined: Sun May 09, 2010 1:32 am
Re: Ip falsification question
Paranoia in engineering mostlysuperdezign wrote:Although, it raises the question of why you feel that IP addresses need to be checked at all
Besides, standard user accounts are be based on username/password, and I do feel to some extent that the administrative section should have some added security layer. Using a forum example, it's an issue if an attacker manages to make a post under someone else's account, but a bigger issue if the attacker gets total control through the administration section.
Still, with that line of thought, it's easy to see why I don't want to allow the software to add an IP address to the list of acceptable IPs through the web interface based on only username/password verification. If I did, the IP check would be a moot point, as all you would need is once again, to manage to break the password. The only benefit I would be getting out of the software if I modify it in that way is the fact that it is logging all IP address connection attempts. Come to think of it, I could stand to add an administrative page that will allow the admin to modify the allowed IP addresses from an authorized IP through the web interface. In practical terms though, I'm not sure how useful it would really be. I would think in practice, the administrator wouldn't know what IP needs to be added until they actually get there.
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Ip falsification question
If you can bear with the limitations, then I see no reason to not tie the system to a particular IP-address.