I have to open a port to a server not in DMZ..how can i minimize risk?

August 6, 2014 7:08 AM

I have to open a port to translate to 443 to a server a billing/accounting company owns on our private network. I don't have a choice. What can I do to minimize the danger to the rest of our network?

A vendor who supplies our company with billing and accounting software has servers within our network (not the DMZ). I don't have a choice in this. I am not permitted access to their servers so I can't verify anything about them other than the address. Basically I am being told "Do this."

They have developed an application on one of the servers that mobile users will need to access. The application is accessed via https. Because 443 is already reserved for our email server (webmail) in the DMZ, they will use 8043. I have always been under the impression poking holes in the firewall to the private network is a no-no.

How big of a deal is this? Can I do anything to minimize the danger to the rest of our network? There are many computers on the private network that must access this server internally as well, so I can't firewall it off from everyone else in any easy way.

posted by bellastarr to Computers & Internet (11 answers total)

poking holes in the firewall to the private network is a no-no.

The security hazard is that if someone compromises the billing/accounting software box, then they have access to your network from there. I would firewall the box inside your network.

Have it so it can only respond to requests on port 443 and not make outbound connections of its own. Then open the existing firewall to route requests from 8043 to port 443 on that box. That way if someone compromises the box all they have is your accounting box, and that risk would be there whatever happens.

I imagine this firewalling will involve putting another server/firewall in front of the accounting server, to manage its security. (of course, if you could manage the accounting box you could just do it on there, you can't, so something else has to do it)

Finally, to manage your own risk I'd contact the company responsible for the box and ask them to accept liability for the case their box gets hacked from the outside world. Whether or not they are willing will probably depend on what sort of support contract you have.
posted by ElliotH at 7:19 AM on August 6, 2014 [2 favorites]

Response by poster: - To clarify, I didn't mean "is 8043 more dangerous than 443", what I meant was how much danger is there to the rest of the network by allowing secure web traffic to that server being on our private network and not the DMZ, and, what can I do to minimize it?
posted by bellastarr at 7:20 AM on August 6, 2014

Can you put the machine into the perimeter network, and allow the people from the private network to access it, would that make you feel better about this? Can you restrict the incoming connections to the accounting software server to only the IP address of the vendor's server, or possibly their subnet?
posted by kellyblah at 7:20 AM on August 6, 2014 [2 favorites]

Response by poster: -kellyblah, I can envision, but don't know the technical implementation of, that if their server is hacked, would it not then be possible to access the rest of our network through it? Just thinking aloud here.
posted by bellastarr at 7:23 AM on August 6, 2014

Response by poster: - No that's exactly how I"m using the DMZ.
posted by bellastarr at 7:24 AM on August 6, 2014

Response by poster: ElliotH - if I block any outbound connections of the acct. box other than replies to 443 requests - I think they will still need Windows updates, web and email outbound etc../
posted by bellastarr at 7:41 AM on August 6, 2014

Get a complete rundown on the software this device is running. Operating System, applications. It's obviously running a web server. Which version? What type of software stack is running on it? Database, scripting languages, etc. You mention many applications need to access it internally. Which ones, which ports? You may not be able to firewall, but you can monitor.

It sounds like you don't have ownership of the box either. As in, admin access. Whose going to make sure this thing is monitored internally? I doubt you'll give them RDP access, so someone is going to have to ensure that Windows updates actually work, fix things when they break.

The lack of details that you don't know about the server is very troubling. I'd fix that first. Get network flows, software manifests, setup procedures, accounts created. And if you can't get that, you can't judge the risk, much less mitigate it.
posted by zabuni at 8:06 AM on August 6, 2014 [1 favorite]

The danger is simply that someone will compromise the software on the vendor's box (either their proprietary software, or the OS/web server) and then be able to jump off and compromise other machines on your network.

This seems like it is what DMZs are for.

You could run any of a variety of SSL security scanner programs against the accounting box. It WILL have red flags, it is very difficult to set up an SSL server that doesn't. You can then take that information to the vendor or your boss, I guess.
posted by miyabo at 8:07 AM on August 6, 2014

Well, then block the outbounds to what it needs to do to function. You could start by logging what it currently does, and then restrict it to that.
posted by ElliotH at 8:10 AM on August 6, 2014

There do exist firewall devices that can perform deep packet inspection upon SSL traffic. I know SonicWALL stuff does it, and googling found me this (I haven't read through it).
posted by destructive cactus at 8:48 AM on August 6, 2014

Something is missing here: why does their server need to be in your internal network rather than the DMZ?

You're saying their external connections will be for windows update, email, etc -- external services that they shouldn't need to be on the internal network to connect to.

What are they connecting to within the private network?
posted by toomuchpete at 7:17 PM on August 6, 2014