10

On some of my production systems that need to be accessible outside of the LAN I will sometimes add a firewall restriction at the edge to only permit traffic on, say, RDP from a specific origin IP address or block. Of course, the IP needs to be static (or I need to update it whenever it changes) but my question is how reliable is this as a means of preventing attackers from accessing this system? In the case of RDP (the most common) there is still username/password authentication, but is relying on these IP-based firewall restrictions a bad idea?

My thought originally was that IP spoofing is more useful in denial-of-service, when you don't really care about the packets getting back to the originator, but in terms of gaining elevated access, is it really that easy for an attacker to spoof his IP and have packets somehow routed back to his real address?

1

6 Answers 6

3

As others have said spoofing a TCP conection is not easy - but still possible. Firewalls help - but don't address the fundamental issue. Authentication is good but only if it is intrinsically secure - hence I'd suggest you consider a VPN. This solves a lot of problems over what acces you want to expose remotely (only a single port for a tunnelling vpn) via whichyou can selectively and securely expose as much as you want without having to worry about the services implementing insecure protocols.

3
  • Typically we use VPN, but sometimes our customers and partners do not want to use any VPN because it "violates their security policy." Specifically with regard to their nodes connecting to outside networks. May 23, 2012 at 2:54
  • 1
    Want to reinforce and add to this point. Something I don't see anyone else mentioning is that if the RDP server has a vulnerability, it's open for anyone on the internet to exploit. They might not need a two-way connection to do this, a simple payload inject/buffer overflow-type drive-by attack might be enough to force an outgoing connection from the RDP server back to the attacker. Okay, so this sounds a little far fetched, but the point is that you don't know what vulnerabilities might show up. Better to rely on methods of identification and authorization that are actually authenticated.
    – bab
    May 24, 2012 at 3:34
  • 1
    "violates their security policy." - erk! Then you can't provide any guarantee of security - to them or the other customers using the same machine.
    – symcbean
    May 24, 2012 at 9:07
3

Successfully launching spoofed IP attacks are quite difficult. The continued popularity of firewalls suggest its continued applicability and relevance. However, one important point I want to make is to point out the two different firewall types: stateful and stateless. Stateful firewalls generally provide more security because of its ability to keep track of sessions. Stateless firewalls, though they still provide some additional measure of control, can be more easily thwarted. The attack scenario is if there's a vulnerability with a service that can be exploited without establishing full connectivity. Such attacks are less common today, but may still exist.

The only way an attacker could launch a spoofed IP attack is if they had access to your provider's network or access to the physical network between you and your provider. In which case, the attacker can easily spoof their IP and receive return traffic. Many people overlook physical security since only the more determined and skilled attacker would carry out such an attack, but it is still possible and some organizations, especially smaller companies, are quite susceptible to it.

4
3

It's relatively hard to spoof an IP (depends on the (attackers) ISP and their filtering), and a lot harder to make even a TCP handshake with a spoofed IP.

Having a login screen with username/password is nice. But it doesn't prevent brute-force attacks, etc. It's like a door lock - with enough time and will/power, it can be broken into. Having a firewall is just another layer of protection (a very good one in this case), which doesn't allow an attacker to even start brute-forcing.

Most random-target attackers do a port-scan first, find open ports, check vulnerable services, and then attack with appropriate exploits. If your firewall drops all packets, your RDP port would appear closed to an attacker, so even if your RDP is/will be vulnerable, the attacker will not know it is running and will not try to attack it (even if he did, the firewall would block all attempts).

So I would definitely go with a firewall in your case.

Even if possible, the attacker would have to guess the right IP, and the right username/password combination. And that only if he/she could find the RDP, since it would be hidden behind the firewall.

2

Yes, it is used mostly in DOS attacks, and spoofing a real address and actually getting the replies is not that easy.

Wikipedia:

IP spoofing can also be a method of attack used by network intruders to defeat network security measures, such as authentication based on IP addresses. This method of attack on a remote system can be extremely difficult, as it involves modifying thousands of packets at a time. This type of attack is most effective where trust relationships exist between machines. For example, it is common on some corporate networks to have internal systems trust each other, so that users can log in without a username or password provided they are connecting from another machine on the internal network (and so must already be logged in). By spoofing a connection from a trusted machine, an attacker may be able to access the target machine without an authentication.

1

An attacker who is on the same subnet as the authorized IP has a variety of methods that can be used to intercept and take over traffic from the designated IP. For example, by acting as a rogue DHCP server, an attacker may re-assign IP addresses to various devices on that subnet. Similar attacks with ARP spoofing allow an attacker to take over an IP by setting up a man-in-the-middle attack between the authorized IP and the firewall.

From beyond the confines of the local subnet and router, without some sort of trusted connection between the authorized host and the attacker, IP spoofing becomes impractical.

0

What you're doing is actually a normal security best practice, so you're fine. If you have it open to the public internet, I'd suggest moving it off of the default port to something different. Consider putting any servers that need to be accessible in a DMZ (demilitarized zone) where you distrust any traffic to/from them. Then you can configure ACL's so that your lan can connect into the DMZ, but the DMZ can't initiate connections to the LAN. If you can't put the servers in a DMZ, consider putting a single server into a DMZ where you can connect in, and then allow connectivity from there into other servers on your network (where I work we refer to this as a jump box). As always, use good practices with usernames/passwords.

As for what everyone else is saying, you really can't spoof an IP. You can proxy an IP, and you can hide a point of origin relatively easily, but you can't spoof an IP. See, internet routing is done based on your IP address, so if your "from" address is fake, when the packets hit their destination and it tries to send a reply, it will send it to the from address. If it's spoofed, well, it doesn't get to you because it will get routed elsewhere. About as close as you can get is using TOR.

3
  • 1
    You can spoof an IP, you just can't easily get a response to your original packet. As I mentioned above, this might not be necessary to the exploit.
    – bab
    May 24, 2012 at 3:35
  • Ahh good point. I was thinking of trying to hide your IP when you're doing things you don't want to. In the case of a syn flood you're absolutely correct, you can use any IP you want in the from: header since you don't care about the syn/ack packets.
    – Matthew
    May 24, 2012 at 17:36
  • Not just syn flood. Also reverse shells and the like.
    – bab
    May 24, 2012 at 21:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .