I have an https website that is protected by a login form (username + password). Does it add anything, protection wise, if I put this website behind a firewall that only allow certain IP address?
Yes, locking your service down by IP will prevent your service being found by the general internet population and will dramatically reduce the attack surface if managed correctly. This will make your site safer from not just brute force attacks - your whole application will be "invisible".
Despite this fact, locking down IPs should not be done in lieu of other measures such as ensuring your web application and server is secure from other vulnerabilities - if one of your "good IPs" is compromised, an attacker could use this as a pivot in order to attack your site. Also be aware that any malware running by any of your trusted users could be used by an attacker to bypass the IP restriction.
So use it as an extra layer of security, but do not let this trick you into a false sense of security where you let your guard down. Treat your web application and platform as if it was fully internet visible - regularly scan and test it for vulnerabilities, and make sure that the management of allowed IP addresses is done properly by deleting and updating and verifying on a regular basis.
An IP address whitelist at the firewall would certainly be very effective in preventing brute-force attacks against your login form, assuming that the following (fairly obvious) conditions are met:
- You are the only person who needs to access this login form.
- You have a static (not dynamic) IP address from your ISP - in other words, your ISP does not change your IP address regularly.
- You don't expect to ever have to access the login form from an unfamiliar location, or if you do, you have a way to add an IP address to the "allow" list. (Of course, having a way to add an IP address to the allow list from an address not on the allow list significantly reduces the security of the system.)
If these conditions are met, then I'd say go ahead and add an IP whitelist. If not, you risk locking yourself (or others) out of the login form.
As far as implementation goes, the easiest way to do it would probably be from the web server itself (for example, using apache .htaccess files). If you decide to do it from the firewall, you will have to find a way for the firewall to know that someone is requesting the login form and not some other page on the website, assuming that there are other pages besides the login form on this server. Since you are using HTTPS, you'd probably have to terminate SSL at the firewall.
One other benefit of IP restrictions is that it can help mitigate malicious insiders.
Consider a cloud service that hosts business critical data for its clients. Each client has a number of employees with accounts, and the intention is that the employees can only access this critical data from company workstations. In the most basic arrangement, there is no technical control to prevent an employee logging in from their home computer. Adding client-configurable IP restrictions allows the administrator of a particular client to force all their users to login from IP ranges belonging to the organisation - stopping people logging in from home.
There are more advanced techniques, in the fairly new field of "federated identity" - but IP restrictions are a simple and effective way to control this.
That depends on what you are trying to protect yourself against.
If you are just trying to prevent random attackers from browsing your site and attempting to brute-force your login your approach will reduce the visibility of your site and deter some attackers in some scenarios.
But if the attacker knows your setup and a particular vulnerability he and or she might not need to read the server responce and might be able to send crafted packages with spoofed sender IP in order to compromise your service. Without testing I suppose a shellshock attact structured like this would work. I admit this is a rather unlikely scenario and requires an attacker to have a lot of knowledge about the system, the setup and vulnerabilities. But if what you are protecting is valueable you might need to consider it.
It depends on what you mean by "restrict".
- If you mean maintain a blacklist of every "bad" IP out there, then no, it does nothing for you.
- If you mean maintaining a whitelist of the only client IPs that should be allowed to access a network service, then yes, this helps somewhat (but does not represent a genuine security measure by itself).
For some bizarre reason the former is by far the most common form of IP restriction. It follows the exact same fallacy as most "check by profile match" anti-virus software, of trying to enumerate everything bad in the world (the number of "bad" is unknowable; it is generally much easier to enumerate the "good" instead).
Note that a whitelist can be dynamic in nature. This idea makes whitelisting a much more interesting tool than it gets credit for. I expect exactly zero exploration of what this can really mean in the general security market.
Roughly half the sudden, mysterious, perplexing WAN connectivity issues I've dealt with in operations at large data centers originate from the ridiculous application of "blacklisting" -- and yet never have I encountered a situation where blacklisting actually did much good (botnets have pools of tens or hundreds of thousands of available IPs, and they shift every few minutes). Note that this is not quite the same thing as temporarily banning or throttling over a span of hours or minutes. Considering the stateless nature of many protocols that sort of throttling can be viewed more as an attempt at connection throttling (the connection attempts are all a related series of interactions) than an IP, MAC or block blacklist.