4

Sort of a basic question, but if we have an internal server and want it to talk externally, for example to get new packages. This environment normally does not have access to the internet. I've heard it's "dangerous" to open access from that server to even a specific IP on the internet (let's say where ever it needs to get its updates from). The point is- we know what the IP on the other side is and I would assume we trust it.

Realistically, what is the risk when it can only talk with that IP it will get new packages from?

Not a security person here- just trying to understand!

3 Answers 3

3

It is no more dangerous than allowing a desktop to access an IP when they are browsing the Internet. It would be dangerous to assign a static IP, have insecure services exposed. Two separate issues. When you connect to the Internet from a business or a home network, or any network for the most part, chances are you will have a firewall somewhere in the loop. Whether it is a dedicated firewall, or minimalist fw like rules applied on a router. That router is your egress point to the world. So this is what occurs when you connect, and how the world sees you:

Router - 10.10.10.1 (internal address) / 33.33.33.33 (external address)
Laptop1 - 10.10.10.2
Workstation1 - 10.10.10.4
DBServer2 - 10.10.10.10

Let's say a user on Laptop1 goes to get an update at say: mysoftware.com, this is what occurs very basic terms:

Laptop1 --> need to go to mysoftware.com (DNS lookup) --> router

Your router creates a tuple (NAT/PAT) to pass it to the world which may look something like this:

10.10.10.2:65432 --> mysoftware.com --> router (I need to remember this)
router --> 10.10.10.1:44555 / 33.33.33.33:554433 --> mysoftware.com "Hey I need this"

Imagine if two people at the same exact time went to mysoftware.com how would data know which machine is which? This is done by the tuple so on the way back this occurs:

mysoftware.com --> here is your update --> 33.33.33.33:554433

Your router/firewall now maps back that tuple:

554433 = 44555 which I have mapped to 10.10.10.2:65432

That is how connections work in a nutshell. Now, under the same ASCII explanation... The outside world can NEVER randomly see what is behind a firewall (unless the fw is misconfigured, and someone does some really good firewalking). So what is perceived will occur by allowing this system to access the Internet? Remember, there is a difference between assigning that machine a STATIC IP where the world can see it, to just giving it access.

So let's assume this is a MySQL server:

Workstation1 - 10.10.10.4 3306 is opened for LOCAL connections (within the LAN)

An attacker? They won't know the 10.10.10.4 address exists. In the world, all they know/see is 33.33.33.33 they can send data to 33.33.33.33 port 3306 but it will end up nowhere.

2
  • Nice explanation. When you say it would be dangerous to use a static IP, I assume you mean static public IP.
    – TTT
    Mar 10, 2016 at 15:30
  • @TTT Yes I should have been clear. Static non RFC1918 address. But even then (using a static address) you will possibly be protected by firewall rules if you statically assigned it via the firewall, as you'd ALSO need to specify which ports are accessible along with the static IP.
    – munkeyoto
    Mar 10, 2016 at 18:43
0

Let's take a look at updates. We download an update from what we believe to be a trusted source and then it travels across the internet to your server. How does the package travel to your location?

If we take a look at how traffic travels across the internet we can see that is has multiple "hops" (travelling from one network device to another).

If you were to ping 8.8.8.8 you would see that the TTL would be something not equal to your systems default. In my case, my system has a default TTL (time-to-live) of 64. The ping result gives me 54 which means whatever information I sent went over 10 different network devices, only 2 of which are owned by my organization, 8 devices that I know nothing about.

What could these 8 devices be doing? I don't know anything about them. They could be manipulating the payload of my packets or could be intercepting my request and providing me with a different file than I downloaded. Having the server on the internet is not necessarily bad (depending on the server). A web server is generally wide open to the internet, a domain controller is generally isolated to a private network.

As for the part of the question about a specific IP, IP addresses can be spoofed. If your server is expecting payload from only a single server and does not do any verification (something such as UDP), the traffic from the spoofed address will be allowed to freely flow in.

This is a fairly broad question and there are a lot of answers. Hopefully this helps to clear up a few of the basic things.

7
  • Thank you for the answer- that is already helpful. My question was broad, but it was somewhat intentional as I was look for some "large concepts" to help me wrap my head around before thinking specifics. To get more specific- the internal host in question is basically just an internal application- not a web server or something super critical like a domain controller, but this server does have access to the rest of our environment.
    – Myelin
    Mar 9, 2016 at 20:23
  • @Myelin If you are going to have it externally, just make sure that only the ports it needs to communicate on are open in your firewall. Not only the firewall on the machine, but also configure your firewall device (ASA/SOPHOS/etc) to only allow those IPs and ports as well. This brings up a whole new concept of application security as well. Have you sanitized your inputs? Is there a SQL server? Are those ports accounted for? Have the service run as an account that only has access to what it needs and is denied from the rest of the system.
    – Danny K
    Mar 9, 2016 at 20:26
  • @DannyKlatt Sorry to tell you but your answer is boggling. On the way up or down the path, 95% will be routers. If you think networking companies are going to randomly "peer" with unknown/untrusted providers you are wrong. Hops along the path have little to do with anything unless someone state sponsored hijacks an entire ASN which would be detected worldwide quickly
    – munkeyoto
    Mar 9, 2016 at 20:37
  • @DannyKlatt Further, as far as UDP goes, irrelevant whether it is UDP or TCP. What would matter most would be an update having a checksum to validate you're getting what you asked for. Further on the route situation, routes change based on preferred paths, and metrics, so your answer makes even less sense to me re-reading it
    – munkeyoto
    Mar 9, 2016 at 20:38
  • @munkeyoto I don't disagree with much of that. The transaction of TCP/UDP with checksums seems normal, but it isn't always the case. Some of the POS systems I have worked with just blindly send the information and it is up to the application to interpret that data. As far as the networking portion goes, a variety of things are possible. How do we know the routing protocol at each state isn't just a static route? We aren't guaranteed to be using BGP at each state externally (I don't know how the insides of ISPs work). My answer is based on the fact that we can't make assumptions with security.
    – Danny K
    Mar 9, 2016 at 20:43
0

Based on this statement:

The point is- we know what the IP on the other side is and I would assume we trust it.

You can sleep easily at night if you:

  1. Lock down your firewall to only allow traffic in from that IP.
  2. Use SSL to communicate with that IP.
  3. Store the trusted certificate the site issues you, and stop communication when the certificate changes.

Whenever the certificate changes, assuming you still trust the site, you can manually store the new cert.

You must log in to answer this question.

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