I am dealing with an application that is protected by a firewall and only allows access from certain IP-Addresses (which are application webservers).
Its a bit delicate and it would be much hassle to introduce another authentication/protection layer.
My understanding of networking is not great because its not my subject, but in my Head I made up the following scenario:
Someone knows the IP-Address of one of our application servers and wants to fake it to get access to the other application which he knows the listening socket and protocol of.
So he alters the Header of his IP packets to have the Webserver IP as transmitter.
What happens next?
A: His ISP rejects the packet and says "Hey, that is not the IP address you were assigned from me." - Problema Solved
B: The ISP passes the packet on to the next level (his up-link...)
Lets assume the ISP has been compromised or the packet is passed on without inspection (I don't know whether that's the case)
What happens next?
A: The carrier rejects the Packet and says "Hey, that IP is not in the range of IP we agreed you are operating on!" - Now if my webserver isnt operated by the same ISP that my attacker compromised - Problema solved
B: The ISP doesn't inspect the packet or is compromised and forwards it to his up-link.
Now I am quite sure that IP addresses ARE inspected and filtered when passing a router. Otherwise it would be total anarchy.
So to put this straight: An Attacker that wants to fake my IP-Address needs to compromise the VERY same ISP that is in charge of the IP-Range my Webserver operates in - or this ISP does not do packet inspection.
Is this correct?
Okay now I imagine my server is located in an office and its ISP is a regional cable company.
What would be the steps necessary to send packets from my IP address to another internet IP?
(Of course I am only asking to get aware of the risks and choose proper protection!)
I imagine locating the routing station which is often in some small container at the side of the street that is only protected by a lock. Going in there. Swapping cables or plugging yourself into.
Will this most likely work if you know what you are doing or is there some encrypted handshake with keys stored on the real offices modem that is required to built an authenticated connection?
I am talking about today's standards in cable internet.
Last thought: So if my origin server is not some household ISP that has its stations vulnerable on the street i should be pretty safe, right?
I remember that NFS servers relies on IP authentication ONLY as a default. Because this is pretty common - are there any examples where NFS servers got hacked by faking IP addresses?
I realise that this question is put very very vagly. This is because I am not sure about anything I am saying here. I just wanted to give some input where I think the cave-eats could be, so they can be confirmed or eliminated.
Overall I am grateful for any comment and your personal thoughts about that subject!
Now I am quite sure that IP addresses ARE inspected and filtered when passing a router.
This assumption is incorrect, despite your level of sureness. "Egress filtering", which is the name of this, is generally not done.
The major protection against widespread spoofing of IP addresses is that the attacker would not recieve any response packets - they would all be routed back to the host that is legitmately using the IP address being spoofed. This kind of attack is known as "blind spoofing", because the attacker is working blind.
In order to send data on a TCP connection, you must be able to finish the TCP "three-way handshake". This requires knowing the initial sequence number used by the opposite end - and since TCP initial sequence numbers are chosen reasonably randomly1, this prevents a blind spoofing attack from being able to do this. (Note also that this does not apply to UDP - without some kind of application layer preventative, UDP is at significant risk from blind spoofing).
If the attacker can see the replies coming back (say, because he is sniffing the uplink or the local network of your server), then this also doesn't apply - spoofing TCP connections in this case is not just possible but trivial.
1. These days, anyway - this wasn't always the case.
Inside a LAN it depends on how your routers/switches/hubs are configured. But I think spoofing should be possible quite often.
I don't think the IP address is inspected. Thus you can send UDP packets with forged sender IP. But you won't receive the answer since the server will send it to the real owner of that IP.
This means you can't simply fake an IP in TCP since establishing the connection needs a handshake.
You can forge the IP of somebody if the response will go through your router. So a network admin can fake all IPs inside his LAN, an ISP all IPs inside his net, and a carrier can fake IPs on many international connections, provided they get routed through him.
Finally there is the possibility of abusing BGP to modify the routes for that IP to go through your computer. But not everybody has access to BGP, you probably need to become an ISP to get it. And then the manipulation will probably be detected because BGP route changes are monitored.
Related
Some applications are providing security only by accepting requests from certain IPs. Is this a good way of making that app secure. Is there any way to manipulate this referrer IP during request period?
getRemoteAddr, getRemoteHost and getRemotePort
Is there any way to set the values above when making the request?
Yes, it is possible to "spoof" the source IP of packets to make the request appear to be from a different IP address than it really is. However, this is not a concern because the three-way handshake of TCP will not complete if the IP address has been spoofed, with a few exceptions (such as the attacker sniffing packets and generating a response when the packet passes on the wire). Generally speaking though, it is very hard to do.
This is not good security practice, however, even though it is typically reliable. The reason is that IP addresses can be assumed by anyone, and they are frequently changed in packets due to techniques like NAT and fire-walling.
Consider that if you have two users on the same private network using NAT, and they both make requests to your server at the same time, your server will see the IP addresses as the same, with different source ports. The differentiating factor that allows routing to happen properly is the source port, not the IP address. To make this even less reliable, the source port will change on every new request, which can happen dozens of times during a single HTTP session.
That being said, there is some benefit to IP filtering. You can make it much harder for someone from a certain country or area to connect by filtering by IP. This should not be your only security, but it can help because it is usually non-trivial to obtain a valid IP address from a a different range. Some organizations will block all non-US based IPs by default, for example. This is used in conjunction with user accounts. This makes it much more difficult for non-local attackers to reach the server.
If it were possible to retrieve the remote IP from a packet received by my Apache2 server (through a custom plugin perhaps), would it always be guaranteed to be accurate? Or is this value as easy to spoof as the referrer header?
My intended use case is to rate-limit unauthenticated API calls.
If it's a TCP packet, then it'll be accurate as to the sending host. IPs in TCP packets cannot be spoofed unless you've got control of the routers involved. With spoofed source packets, only the initial SYN packet will come back, and then the SYN+ACK response from the server will go to the spoofed address, not wherever the forgery came from - e.g. you cannot do the full 3-way handshake unless you can control packet routing from the targetted machine.
UDP packets, on the other hand, can be trivially forged and you cannot trust anything about them.
As well, even simple things like proxy servers and NAT gateways can cloak the 'real' ip from where the packet originated. You'll get an IP, but it'll be the IP of the gateway/proxy, not the original machine.
It is not reliable. Not only because it can be spoofed, but also because a network element can make your server see a different IP address.
For example, it is very typical in a company to access the Internet through a proxy. Depending on the configuration, from your server point of view, all the different users come from the same IP address.
In any case is a filter you can use in many scenarios. For example, show a captcha when you detect too many login requests from the same IP address.
If your intention is to rate-limit invalid API calls you might want to consider using a service like spamhaus. They list IP's that are likely bots and probes. There are other companies and lists as well. But if your intention is to ever ID the 'bad guy' the source IP is very unlikely to be correct.
If IP addresses can be spoofed by creating false or manipulated http headers, and therefore it should not be relied upon in validating the incoming request in our PHP/ASP pages, how come servers take that and rely on it? For example, denying IPs or allowing them are all based on IP.
do servers get the IP information some other ( and more reliable ) way than say PHP/ASP gets it thru server variables?
Servers are typically willing to rely upon the IP address of a connection for low-risk traffic because setting up a TCP session requires a three-way handshake. This handshake can only succeed if the IP address in the packets is routable and some machine is prepared to handle the connection. A rogue router could fake IP addresses but in general, it is more difficult to fake connections the further away from either endpoint the router is, so most people are prepared to rely on it for low-risk uses. (DNS spoofing is far more likely way to misrepresent a connection endpoint, for example.)
Higher-risk users must use something more like TLS, IPsec, or CIPSO (rare) to validate the connection end-point, or build user authentication onto the lower layers to authenticate specific connections (OpenSSH).
But the actual contents of the TCP session can be anything and everything -- and a server should not rely upon the contents of the TCP session (such as HTTP headers) to faithfully report IP addresses or anything else vital.
IP addresses cannot be spoofed. The address is needed for the server to send a reply.
PHP gets the IP address for its $_SERVER global from the server (hence the variable name!), which determines the address from lower in the protocol stack.
EDIT:
sarnold makes a good point that, in principle, one could corrupt routing tables to misdirect traffic. (Indeed, I believe there was an incident of this in a Tier 1 router in Asia a couple years ago.) So I should clarify that my comment that "IP addresses cannot be spoofed" was narrowly tailored to point out that the server variables will always faithfully reflect the destination IP. What goes on beyond the the server's borders is another matter altogether.
so suppose I detect a user's ip using some code to perform restrictions....
is there a way for a user to circumvent this by arbitrarily setting their ip to any ip they want anytime they want (eg. via proxy server or something) hence allowing them to choose a specific ip to be displayed when I detect it
There are several tunneling and proxy-based techniques that will effectively present a different IP address for any HTTP requests than the one belonging to the originating computer. I have mentioned several methods in this answer, as well as here. In many cases it is actually impossible to tell apart a relayed connection from the real thing...
In general you cannot forge the source of a TCP connection on the Internet to be an arbitrary address for a number of reasons, some of which are:
TCP is a stateful protocol and packets go back and forth even in order to establish the connection. Forging an IP source address means that you cannot get any packets back.
Some ISPs will drop packets generated within their own network that do not have a source IP within the proper subnet. This is usually done at the client connection level to protect the ISP network and prevent random packets from leaking client information to the Internet due to simple misconfiguration issues client-side.
ISP filters will also prevent users from just setting an arbitrary IP - if not for any other reason, then just because ISPs sell connections with static IP addresses at significantly higher prices and having users set their own IPs would spoil that. Not to mention the mess that would result if there could be IP conflicts among the clients of an ISP...
So in general you cannot just spoof the source of a TCP connection. You have to use an intermediate computer to relay the connection.
Keep in mind, however, that motivated and experienced attackers may have at their disposal botnets that consist of millions of compromised computers belonging to innocent users. Each and every one of those computers could theoretically be used as a connection relay, thus allowing a potential attacker quite a wide variety of IP addresses to chose from.
The bottom line is that simple IP-based checks and filters cannot in any form ensure the legitimacy of a connection. You should be using additional methods to protect your service:
HTTPS and proper user accounts.
Extensive logging and monitoring of your service.
Intrusion detection systems and automatic attack responders (be careful with those - make sure you don't lock yourself out!).
We cannot really provide a more concrete answer unless you tell us what service you are providing, what restrictions you want to apply and what kind of attacks you are so worried about...
Sort of - as you mentioned, proxies are a risk, however it makes life a wee bit harder for the attacker so it is still worth using IP bans.
Monitor your logs, automate alerts and if attacks come from another IP - ban it too. If you make life hard enough for an attacker they may give up.
I'm developing an application that accepts connections from clients over the internet. All these clients are on fixed IP addresses and will establish a non-encrypted TCP connection.
The current plan is for the server to check which IP the connections come from and allow only client connections from a list of know IPs?
How safe is that against IP spoofing?
My reasoning is that since this is a TCP connection, an attacker couldn't just fake its sender IP (which is easy), but would have to assure that the packets travel back to him and thus he would have to hack all routers on the path, which seems rather hard.
I know I could use encryption, like SSH, but lets stick with the question of how safe the plain TCP connection would be.
Restricting connections by IP address is generally a good practice when practical, as it greatly reduces the attack surface and makes the complexity of an attack much higher. As stated in other answers, you would now have to do something like IP spoofing, or attacking the network itself (false BGP routes, etc).
That said, IP address restriction should be used as one layer of a defense-in-depth approach. Could you encrypt the TCP stream without too much rework? Maybe SSL? If you can't modify the program, how about the network? Site ti site IPSEC VPN tunnels are not difficult to establish, as almost any commercial firewall supports them. Even some soho routers can be modified to support IPSEC (with OpenWrt plus OpenSwan, for example).
Lastly, could you require the client and server to mutually authenticate?
Not safe. BGP gateways are not immune to attack, and with that, false routes can be advertised and IPs can be spoofed.
First of all, using the IP you are not identifying the client, but just some numbers. Even if the IP is right, there still can be a troyan on user's computer, authenticating in place of the user itself (as I don't know what kind of service you provide, I assume that this might make sense).
Now, if one has access to one of the routers via which the packets between the client and the server go, then he can do almost anything - he can send and receive packets in the name of the client or he can modify them (as the data goes unencrypted). Moreover, the attacker doesn't need to hack all or one of routers - he just needs to have access (including legitimate one) to the channel where the data goes, be it the router itself or the cable (which can be cut and the router can be inserted).
So to summarize, IP can be used as one of the component that hardens spoofing to some extent, but it can't be the main security measure.