3

I understand that you can implement a firewall to only allow access to a server from specific IP addresses, but can't people fake the source IP address in a TCP packet? How does this actually stop unscrupulous people from accessing your server?

4

What Dude said is the answer you seek.

I think what you are thinking is this:

SERVER.......................CLIENT
............[FIREWALL].........|
..|............................|
..|_>___[CHECK FOR AUTHORITY]_<_|

This diagram assumes that both the server and the client have firewalls (usually they do).

If the Authority fails the call to the Server/Client is ignored.

So if the Server ip is xxx.xxx.xxx.1 and the client is xxx.xxx.xxx.2 and the client tries to access the server by sending a command without authorization.. Your server log would be like this xxx.xxx.xxx.2 [Authorization failed - IGNORE]

If xxx.xxx.xxx.2 Cloaked his ip as xxx.xxx.xxx.3 which is authorized to access the server then this would happen.. xxx.xxx.xxx.3 -> Send command packet to xxx.xxx.xxx.1 xxx.xxx.xxx.1 -> Respond to command and send packet to xxx.xxx.xxx.3

So xxx.xxx.xxx.1 would never get the retrieved command.


Now what your probably thinking is HOW iS THAT SECURE?

Well most servers actually work like this..

SERVER..............................CLIENT
..|______________[CONNECT]___________<_|
............|
...[TEST AUTHORIZATION]
...........|
......[PASSED]
..........|
...........[SEND CONNECTED RESPONSE]...|

So if the client is authorized and makes a call to the server the server will respond with a connected response to send back to the client if the client gets this response the server knows that this is the correct client.

2
  • Nice explained, +1 from me! Oct 26 '14 at 18:16
  • Gloo, I see you asked, "That makes sense. But I'm curious, can a malicious user not do any harm with a one-way connection?" The answer is conditional. If the server is set up to authenticate like i described above then no the hacker can not do any damage (except maybe flood your server), if the server is set up to not authenticate and just run the command then YES the hacker can do some SERIOUS damage. You should always authenticate and use Asymmetric Encryption when establishing the connection. Oct 26 '14 at 19:51
5

Surely can someone fake his IP address for SEND the TCP/IP packets but he will never get any RESPONSE because it will go to the fake IP address he used! So this way is useless for someone who want establish two-way communication!

3
  • 2
    Yes, and that is needed to establish the connection before any data is sent or received, as explained here - inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml
    – paradroid
    Oct 26 '14 at 16:48
  • That makes sense. But I'm curious, can a malicious user not do any harm with a one-way connection?
    – gloo
    Oct 26 '14 at 19:25
  • @gloo Yes they can in some cases. UDP is a stateless protocol (as opposed to TCP), so malicious users can do funky stuff like NTP amplification.
    – ntoskrnl
    Oct 26 '14 at 21:53
1

It has been noted that faking the sender is not enough, you will also want to get the answer back to do much/anything useful. So you would need to do a full man in the middle then.

However, firewalls usually won't "allow" much simply based on the source IP.

Firewalls are mostly used for blocking, but not for authorization.

I.e. an untrusted IP won't even know there is a VPN, not will it be able to connect to the VPN service. Or attack it easily, for that matter. But the main security feature is the VPN itself.

Since IP based filtering is cheap, it makes a great first line of defense. Rejecting any packet at the firewall means that the services behind will have to deal with much less "attacks" (and other noise). Running a DDoS against a firewall is harder than running a DDoS against an actual service, because you need to fill up the internet connection, not the CPU of the server handling the requests.

1

It is indeed possible to cause harm with one-way connections (e.g. with stateless protocols like UDP) but then this boils down to avoiding IP-based (unsafe) authentication.

TCP

TCP is generally not affected, since connection establishment requires sending back a packet to the originating host. Here is how it goes:

Alice is in the list of authorized hosts.

  • Alice sends a SYN packet to Bob.
  • Bob returns SYN-ACK to Alice to signal that she may proceed
  • Alice proceeds with an ACK packet, and continues with the intended payload.

Charlie tries to connect to the service.

  • Charlie sends a SYN packet to Bob.
  • Firewall blocks the packet, Bob receives nothing (or a warning in the logs that Charlie tried to connect to him.
  • Charlie might or might not know that his request was rejected (depending on the firewall configuration, either the request times out or Bob explicitly sends an ICMP rejected/unreachable packet)

Charlie somehow knows that Alice can access the service.

  • Charlie sends a SYN packet to Bob, prentending he is Alice.
  • Packet goes through Firewall, Bob returns SYN-ACK to Alice.
  • Alice replies RST-ACK (reset acknowledgement) or ICMP Unreachable, since she was not expecting something from Bob.
  • Charlie will never know if the request even went through.

Now, what if the connection is already established? This is what sequence numbers are for: they cannot (should not) be predicted by others, and both parties expect sequences to always increment by one.

  • When connection is established, both parties select a preferably random sequence number.
  • On each packet they send, the sequence number should be incremented by one. This allows the receiving end to reject packets with wrong sequence numbers and reorder those that are within the accepted window.

Now Charlie has no way of "injecting" packets into an existing connection between Alice and Bob, as he cannot predict the sequence number, and his packets will be rejected by Bob, along with maybe a warning or notice in the logs.

UDP

If the protocol is UDP, it is strongly susceptible to spoofing, as much as peers are able to inject spoofed packets on the Internet, therefore you have to add an authentication or encryption mechanism at the application layer instead of transport.

Mitigation

ISPs will add measures to prevent IP address spoofing. It could be as simple as rejecting all packets that do not match their own netblocks from going out the router, and packets that match their netblocks from going in their network.

In a local network it is often very easy to do spoofing as there are not a lot of mechanisms to prevent someone from doing so.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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