Should I limit my admin to a specific IP or MAC address?

[Soniccc]

I don't know if this is a security issue but all the same I wanted to ask. Would better security be provided if the admin login were locked to an IP- or MAC specific address?

[RodG]

I don't know if this is a security issue but all the same I wanted to ask. Would better security be provided if the admin login were locked to an IP- or MAC specific address?

How does both sound? Actually it depends on who you are trying to protect from.

MAC works on layer 2 (data link) of the OSI model
IP works on layer 3 (network) of the OSI model.

MAC addresses identify hosts on any given *physical* network segment (IOW, a LAN) .

IP addresses identify hosts on the Internet (IP = Internet Protocol). IOW, a WAN.

If you are trying to prevent people from accessing it via the Internet you need IP protection. If trying to protect from people on your own network (assuming you have one), then you'll need to block based on MAC.

Simple, eh?

Cheers
Rod

[Soniccc]

Is IP-Protection a feature thats really needed for ZC ?

[RodG]

Is IP-Protection a feature thats really needed for ZC ?

Simple answer. No.

On the other hand it depends on exactly what you mean by IP-Protection. Actually, the answer will still be no, but you may not be asking the right question.

Cheers
Rod

[Soniccc]

Well the reason would be to make it harder for hackers to get access to the store back-end. But perhaps it's just clever marketing by those Companies implementing these functions.

[swguy]

Is IP-Protection a feature thats really needed for ZC ?

It doesn't hurt.

Your hoster likely has a way for you to limit access to a folder by IP. Just remember that if you don't have a static IP (and you probably don't), you may have to go back to your hoster's control panel to change the rule if and when your own IP changes.

[RodG]

Well the reason would be to make it harder for hackers to get access to the store back-end.
But perhaps it's just clever marketing by those Companies implementing these functions.

This is why I asked "it depends on exactly what you mean by IP-Protection".

This has different meanings for different people.

Based on the subject title, and other comments you have made, I have been assuming you were referring to "IP-Protection" as a means of *blocking* accesses from certain IPs.

This is something that if implemented *should* be implemented by a firewall. This will prevent ALL data from the blocked addresses from ever reaching your server(s).

On the other hand, swguy has taken the more common meaning to your "IP-Protection" question and provided details of how restrict access to sections of a *web* site by implementing filters that determine whether the IP address is allowed (or not).

Both cases work on the IP address (obviously), but the rules are applied on different layers of the OSI model.

You started this thread asking about MAC addresses (layer#2).
You compared this with IP blocking (firewall/layer#3), and with swguys input, we are now discussion protection at layer#7 of the OSI model.

When discussing these things it really helps if you understand the OSI model (and I had assumed you may have had some clue, else you probably wouldn't have even asked about MAC vs IP blocking).

The biggest security risk to worry about resides on layer#8.

If you are on a hosted server then you *probably* wont be able to implement any protection lower than layer#7 (well, not without root access).

Layer#3 is where all the 'good' stuff happens to keep the real bad guys out.

Layer#7 is where where all the exploits take place, which if you seriously think about it, makes it pointless trying to use this layer to block the bad guys, any compromise at this level means game over. The bad guys have already won.

I do however agree (to some extent) with swguys's comment "It doesn't hurt", because it really doesn't hurt from a *technical* perspective. The thing I don't like about it is that it gives too many people a false sense of security.

"IP protection" (to a web server) at layer#7 will slow a couple of script kiddies down a little, but lets face it, this is still just blocking one type of access on one given port, when there are still plenty of other ports and services on the same server that are just as exploitable, and again, these are all layer#7 services, compromise any one, and its game over for all the others.

Cheers
Rod

[Soniccc]

Thank you for your comments, and for providing lengthy details on this! I will look into it!