4

I have to maintain very old CentOS server (not patched since 2013) for a year, until new software is developed to replace it.

It holds HTTP server, mail server and many custom build apps (author gone and forgotten long time ago) with terabytes of data and spaghetti of scripts referring scripts etc. Is there anything I can do to make it less vulnerable besides patching it, because this is going to brake too many things that I can't repair in reasonable amount of time?

killgore
  • 43
  • 2

2 Answers2

2

Put a firewall in logging mode in front of it. Watch all the traffic coming in and out of it and run any reports or processes that this server should do so you make sure to capture all the types of communication the firewall rules have to allow. Create rules to allow only this traffic to pass. Once you are confident you have everything set correctly drop and log any traffic that is outside the normal traffic parameters. Make sure to alert on anything logged so it can be investigated to be added as a rule or as an intrusion attempt.

Edit: I've assumed based on the question wording that this is an internal server. Also, use the opportunity when profiling the traffic to look for indicators of existing compromise.

DarkMatter
  • 2,691
  • 2
  • 7
  • 23
  • 1
    This does not protect the server from the allowed, expected, and unpatched interactions. Let's assume that it's a public HTTP server. In normal operation, it has to allow incoming connections from around the world. In your plan, once you allow this traffic, you offer no next step, even though it might be bleeding data or allowing unauthorised connections. Your plan also permits existing compromise to continue. You are trying to use the firewall traffic as a baseline, but that's a dangerous approach for a known exposed and vulnerable asset. – schroeder Feb 20 '19 at 19:59
  • You need to have another way to enumerate what the secure and baseline state is. Existing states cannot be assumed to be safe. – schroeder Feb 20 '19 at 20:00
  • @schroeder The question does not say this is a world-facing web server it sounds more like an internal server to me. – DarkMatter Feb 20 '19 at 20:19
  • @schroeder don't let perfect be the enemy of good. During the process of creating the rules based on current traffic one should attempt to verify the traffic is legit (obviously) either way the server is in a much better place than it was. – DarkMatter Feb 20 '19 at 20:21
  • ... The same principle applies if only internal ... Just because it is the current state does not mean it is the desired state. My answer outlines how to actually baseline the desired state. And instead of inspecting an external firewall, why not run ps and lsof to see what is actually running? – schroeder Feb 20 '19 at 20:25
  • @schroeder if it is an internal server the ability to lock down traffic to a specific whitelist is very different than an external webserver so no different principles apply... – DarkMatter Feb 20 '19 at 20:26
  • Only if you trust all your insiders .... – schroeder Feb 20 '19 at 20:28
  • @schroeder again perfect isn't the enemy of good... – DarkMatter Feb 20 '19 at 20:28
  • Your plan could result in no increase in any protection or detection. Your plan is just theatre. – schroeder Feb 20 '19 at 20:29
  • @schroeder you could say that about any security control...what a worthless statement – DarkMatter Feb 20 '19 at 20:30
  • Unless you can quantify the effect of a control, which is why doing that is the first step. Throwing tech at a problem and hoping there is an effect is theatre. – schroeder Feb 20 '19 at 20:31
  • @schroeder I know exactly the effect of this control. I lock down traffic via a whitelist to only traffic I decide to allow...that is about as well quantified as you will ever get in this world. – DarkMatter Feb 20 '19 at 20:32
  • Unfortunately this is world-facing server. – killgore Feb 21 '19 at 22:34
  • @killgore "hold on to your butts" – DarkMatter Feb 22 '19 at 12:48
2

You might be surprised how common this situation is.

The short answer is, yes, there are all kinds of things that you can do. But it will require that you understand the normal operating state of the server and to start locking down those states.

As with a full company cybersecurity programme, you can break it down into steps/phases:

  1. Identify everything that is running, all ports, all admin/service accounts, all expected outbound connections, all types of data, and the risks to each of those things if something goes horribly wrong
  2. Protect those things that you have identified in proportion to the risks that exist for those things: firewalls rules that whitelist only that which is needed, configure encryption, reset admin and service account passwords, disable unused accounts
  3. Detect any anomalous activity to determine if there is a persistent threat or if you missed something in your Identify phase by setting up logging and monitoring processes
  4. Respond quickly and with pre-approval to things that will result in unacceptable risk to the company

I would also look at the patches that were not applied and see if things can be patched or if you can deploy alternate mitigations for the highest risk things.

In general, I would assume that the server has already been cracked and is used by malicious actors. I'd also assume that there are people who have inappropriate access to the server and its data. And while you might not be able to "fix" the situation, by making these assumptions, you can set expectations and set the level of effort and protection required.

schroeder
  • 129,372
  • 55
  • 299
  • 340
  • Thank you for prompt and factual answer. Can you recommend tools or guides for detecting existing breaches? I can see that server is used probably by some bots to send spam. I've reduced this by cutting whole TLDs on firewalld and postfix but it's rather band-aid then cure. I'm also planning to add some hardware-based firewall in front of this. – killgore Feb 21 '19 at 22:47