firewall ip filtering overview

How does filtering an ip address over tcp with your firewall actually work? This text aims to provide some high level insight about how ip filtering over TCP can reliably secure communications between machines over the public Internet.

Consider this common situation: it's 6pm and you get a phone call from what looks like a neighbor of yours, or at least someone in your town because the caller ID shows a number with the same area code (first three digits) and the same exchange (next 3 digits in an American phone number). So you pick it up only to experience the dreaded pause followed by an eager telemarketer launching into their sales pitch.

Does the telemarketer happen to work in your town? Nope, the problem is that the national phone system allows any number to be chosen by the caller to appear in on the receiver's caller id screen. Average consumers with average phone equipment can't usually control their caller ID (like to trick their friends), but all business (VOIP) telephone software used by companies are able to set the caller ID to whatever they want--and the national phone system will happily pass it to the receiver. The telemarketer's dial-out software in the prior example was trying to get you to think the call was coming from a local person and therefore someone you might want to talk to. Can't bad guys do the same thing with IP addresses?

Let's say that you have a web server on the public Internet, but you only want to allow access to it from one specific IP address. So you set up the firewall on the web server to only allow inbound connections from IP 123.45.6.7 using its IP filtering settings. If a bad guy somehow knew that the IP address you only accept is 123.45.6.7, why can't they just spoof their IP address and then connect to your server? (Similar to how the telemarketers spoof their phone numbers.) They could also try to connect to your server with all known IP addresses or cleverly selected ranges of IP addresses to see if they might get lucky and find one that lets them in.

The answer is that TCP prevents ip spoofing with a "3-way" handshake which includes the transmission and verification of a few secret random numbers. Take a look at the sequences below:

when a legitimate connection is attempted

[Legit Client @ 123.45.6.7 on port 8458] --> [Server 99.99.9.8 on port 80]
  "Hi, I'm 123.45.6.7 on port 8458, can we talk? My secret # is 4762542."

[Server on port 80] --> [Legit Client @ 123.45.6.7 on port 8458]
  "This is 99.99.9.8 on port 80, sure we can talk, your secret # was 4762542, and my secret # is 777778."

[Legit Client @ 123.45.6.7 on port 8458] --> [Server 99.99.9.8 on port 80]
  "Ok, great, your secret # is 77778, can I have the web page at url:/site/login.html?"

when a spoofed ip connection is attempted

[Bogus Client @ 666.66.6.7 on port 666] --> [Server 99.99.9.8 on port 80]
  "Hi, I'm 123.45.6.7 on port 666, can we talk? My secret # is 3478884."

[Server on port 80] --> [Legit Client @ 123.45.6.7 on port 666]   (notice who the server sent this to)
  "This is 99.99.9.8 on port 80, sure we can talk, your secret # was 3478884, and my secret # is 888867."

**that's it, the bogus client is left in the dark**

That's it, because the server sent its reply off to the real 123.45.6.7, which may not even be on line at the time, and even if it was on line, the message would be ignored by the legit client because it wasn't expecting anything from that server. The bogus client at 666.66.6.7 simply told the server the wrong IP address, so it will never get a response. Then, even if the bogus server waits a few seconds and then just goes ahead and tries to send it's response, it will be ignored by the server because it has the wrong secret number:

[Bogus Client @ 666.66.6.7 on port 666] --> [Server 99.99.9.8 on port 80]
  "Um yea, cool, your secret # was...ummm...12345? maybe?, umm can I have a web page called login.html? please?"

Can there actually be two identical IPs on the Internet?

Nope, the IANA (Internet Assigned Numbers Authority) maintains and assigns the official list of IPs, so bad guys can't officially duplicate an IP address on the public Internet. And, as we've seen above, although bad guys can claim to be at any IP address when sending data to other machines, TCP will make it so they can't actually connect anywhere with the bogus IP.

but watch out for UDP

UDP is a different story. Since the 3-way handshake is not performed when communicating over UDP, a bad guy can send a packet to a listening UDP server and claim to be from any IP address they want. The UDP server would have no way of knowing if the IP address was real or fake. When building UDP servers, it's left to the developer to devise their own means for verifying the legitimacy of inbound data.