0

If I were to configure a server that would be configured to only be accessible (HTTP) from a single IP address via a port, is it safe from unauthorized access?

4
  • 1
    It's not clear what you mean by 'safe', but in addition to the answers below - if the server is accessible from the single IP address by HTTP (not HTTPS), then an attacker between the user and the server can listen-in on messages between the user and the server and/or change these messages. – mti2935 Feb 26 at 17:56
  • If the single IP address is 127.0.0.1 then it is pretty safe. – Esa Jokinen Feb 26 at 18:05
  • You need to define what you mean by "safe". Safe from what? – schroeder Feb 26 at 18:10
  • By safe I mean, it is only people who have access to the IP address are able to access the data on the server. I’m not taking insiders into account as I know that is harder to detect. For Esa’s answer it is a single public IP address. – Gundam Gundam Feb 26 at 18:13
1

Access from a single address does not make it magically safe if the attacker can use this IP address. This can be done directly if the attacker has compromised this specific system. It can be done indirectly if the attacker can cause a HTTP request from this IP address, for example by sending a mail with a link to the user on this system or by including some link (might be automatically submitted) inside a web page which the user on this IP visits. See also CSRF and XSS attacks and similar.

Apart from that an attacker might reside in the path of the connection. Thus even if the data seem to originate at the specific IP they could be modified or newly generated by some man in the middle (proper HTTPS protects against this though).

2
  • Would somebody be able to perform a tcp dump from another IP outside of the source IP which in this scenario is only accessible to me? – Gundam Gundam Feb 26 at 20:46
  • @GundamGundam: I cannot see any relation to your original question. But packets can be captured (i.e. tcpdump and similar) at any system in the path of the communication, not only at the endpoints. And an attacker might also enforce a path they can control using ARP or DHCP spoofing. – Steffen Ullrich Feb 26 at 21:56
0

Not entirely sure what you mean by safe. Nothing is safe on the internet, but if you configured it that way I suppose it “could be safer”.

There are still many many different ways to attack an http server configured in that way. MITM, spoofing, DoS etc.

1
  • What if the user accessing the server is in a secured network or wifi? – Gundam Gundam Feb 26 at 16:46
0

We cannot say "It is safe". But you are trying to reduce attack surface. But http and your server is still unsafe. There are many attacking vectors are available to attack your server.

You are going to achieve security by obscurity. It can be successful rarely but it is not recommended or standard way to protect your resources.

If you really want to protect your server, Use standard security mechanism based on your security requirement.

4
  • Quick clarification on when you said “successful rarely” are you saying the hacker would be rarely successful in compromising the server with the configuration I mentioned above but its still possible using other ways such as actually gaining to the IP address? – Gundam Gundam Feb 26 at 18:09
  • Security by obscurity can successful rarely. That mean, hacker will be won in many attempts. Simple answer for your statement is yes. There are many possible ways to attack your server. – Infra Feb 26 at 18:12
  • Sorry, “hackers will be won in many attempts” means they will be successful majority of the time? You answered Yes to my question so I’m kinda confused. – Gundam Gundam Feb 26 at 18:20
  • Simply prison is secured place and only limited peoples can access including relations of prisoners and security guard of it. But still i can shoot person inside a prison using these option. You simply try reduce number of relation who can access to prison. But still i can purchase him, threatening him or purchase security guard to shoot him. Best thing to do keep that particular prisoner in protected area or provide him to security equipment like arm guard, helmet....etc. Do you got my point? – Infra Feb 27 at 10:00
0

You can use IP restrictions as part of a defense in depth approach to reduce the likelihood of attack or compromise, but they are not a substitute for standard security measures such as TLS or other securely encrypted protocols.

When you use TLS properly, it provides confidentiality, authenticity, and integrity. Without TLS or a similar protocol (e.g., SSH), you don't have any of those things. Anyone who can sit in the middle of the connection can view and tamper with the connection at will. It is well known that many providers do this; for example, Verizon tampers with HTTP connections to insert advertising identifiers and Southwest has inserted text into all HTTP connections showing you how long your Wi-Fi connection will last. Neither of these will work with TLS.

If you used HTTPS, an IP restriction might be sufficient to prevent unauthorized access, but it depends. For example, if the IP address is your corporate NAT address and the site is a set of corporate policies, then that is probably sufficient to protect the information given the fact that your corporate policies, while private and sensitive, are probably similar to most other corporate policies and would likely not result in the company going out of business if exposed.

However, if your data is more important, you might want to institute a random shared password (e.g., stored in a shared password manager vault) in addition to HTTPS, or even add a full set of normal authentication mechanisms (username and password, 2FA, or SAML). Without knowing what the information is you want to protect and how important it is to you, it's hard to advise on how much security should be used. That being said, using TLS or another secure protocol is the baseline level of acceptable security these days, so you should definitely implement that.

Not the answer you're looking for? Browse other questions tagged or ask your own question.