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!

Myelin
  • 151
  • 2
  • 6

3 Answers3

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.

munkeyoto
  • 8,682
  • 16
  • 31
  • Nice explanation. When you say it would be dangerous to use a static IP, I assume you mean static *public* IP. – TTT Mar 10 '16 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 '16 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.

Danny K
  • 142
  • 6
  • 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 09 '16 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 09 '16 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 09 '16 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 09 '16 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 09 '16 at 20:43
  • @DannyKlatt I would suggest understanding networking a bit more before making those sorts of comments. BGP is the de-facto protocol that makes the Internet work the way it does. ALL PEERS are statically assigned, and although there are some that are dynamic, would a dynamic route from say Level3 be less secure than a static route from Level3? Aside from the route path taken (because it's irrelevant), most if not all reputable updates contain a mechanism to validate software via checksum. As for your POS "application" comment, that is the application layer, not networking. – munkeyoto Mar 09 '16 at 20:53
  • @DannyKlatt "Irrelevant" based on his initial question: "I know where it's coming from" this is as simple as cross validating it on say http://bpg.he.net if you need to be sure 8.8.8.8 truly is Google. How you and I end up there is completely irrelevant as long as we get there, and we can validate 8.8.8.8 = 8.8.8.8 – munkeyoto Mar 09 '16 at 20:54
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.

TTT
  • 9,122
  • 4
  • 19
  • 31