Protecting Your Enterprise Network from Vendor App Servers? 258
anomaly wonders: "I work for a company with a large IT infrastructure. We have lots of applications in our environment. For a number of applications, vendors provide the apps, and provide core support to those app servers. Our vendors are notorious for demanding superuser access to the boxes that support their applications. To protect our enterprise network from attacks allowed in by well-meaning but less-than-perfectly-competent vendors, we have set up a quarantined network for each vendor. This works well when the model is ASP-like and all of the components live on a single box, but fails when the application needs to be connected to one or more enterprise applications (RDBMS, smtp, they want backup, etc) or when it needs to be connected to lots of target systems inside our environment on lots of different ports. How can I restrict a vendor/application server's access to our enterprise network while still providing platforms to make the applications productive for our user community?"
"Frequently vendors can't restrict their applications to run on a limited set of ports. Most of the time they stare blankly when we want their application to run as something less than superuser.
Our biggest challenge is keeping track of all of the dependencies and managing what ports need to be allowed to which destinations. Of course, when security is tight our business-types say 'you're breaking my application.'
What can you suggest about how to provide access to applications, patch/protect the OS on the app server, and protect the enterprise network? What does your organization do?"
On demand and via a process (Score:2, Insightful)
The disadvantage is that there is an operational overhead -- but then there should be because if its a pain to change things then less gets changed.
My suggestion (Score:5, Insightful)
What can you suggest?
Find some better vendors?
Simple use a Firewall (Score:3, Insightful)
Re:Don't let them (Score:3, Insightful)
So, my advice is also to not do it. A vendor needs access to repair/upgrade a system? Arrange for a once-off remote access solution (like WebEx or something for Windows boxes) in a situation where you have control of the access and can monitor them. We had a vendor one time get real whiney about not having on-demand remote access into our system, but we put out foot down and they dealt with it. The reality is that you're the customer, and it's their job to adapt to your situation.
Re:Tell them to screw off.. (Score:4, Insightful)
Re:Tell them to screw off.. (Score:5, Insightful)
-- Lee K. Gleason, VMS sysadmin
Amen (Score:3, Insightful)
I have been a software vendor for many years. With software that is correctly build and tested, the need have access to a forgien box is about 0.
That is not say that there were not times I wished I had access. Mainly language translation, English-French with neither tech being able to speak the other and a translator that did not understand techincal terms. Think Baud Rate and Partity Bit
Even when I went on site, I generally never touched a machine. I always had the local operator or manager do the actual typing. This way, they learned the what and how along with me, and how to fix it.
But back to today's world, IF and I MEAN IF the higher levels of company force/black mail you into a corner , setup a connection PC. Vendor connects to there, and that is terminal of them in your system. Log every thing. Turn off the PC when you can not be watching what happening.
Re:Switch vendors (Score:5, Insightful)
When the only alternative to required software is working by hand (or a major reverse-engineering project), you just gotta suck it up and figure out how to protect the rest of your systems from their arrogance.
Generally speaking, it's a clear sign of laziness or incompetence on the part of a half-assed programmer to think he needs root for everything. Hell, Oracle doesn't need root to run, and it's a mighty damned complicated RDBMS suite. If you're stuck with one of these vendors, I urge you to make it clear to them that you are using their software because you are stuck with it, that given the chance you will jump ship in a heartbeat, and that the reason you'll never buy any of their other products is that their claim to "need" root is a sign of either ineptitude or a cavalier attitude towards their customers.
Re:Find a new vendor (Score:5, Insightful)
I work at for a large government contractor, where root privilage is truely guarded to only those who need to know as there is data that absolutely need to be protected. Allowing random people from random companies access is not an option. It is actually a criminal offense to let someone else use your account who does not also have an account on the system (it is still a security violation even if they do have an account and is possibly subject to disciplanary action, up to and including criminal punishment depending on what it was being used for).
Basically, the only people who have root are the actual system administrators. And that is even locked down in the sense that we are supposed to log in with our regular account first and "su" to root, or otherwise need to call up security and let them know what system you need to log into directly as root (login and audit logs are checked on a regular basis for any discrepencies).
Basically, like I said, if they need root, they go thru one of us to do something.
Re:On demand and via a process (Score:3, Insightful)
What if the problem is caused by bogosity in a config file that only root can read?
What if the logs produced by the application are only readable by root (or by adm)?
What if the process is running with root privileges and you need to trace/truss it to perform the diagnose it?
heh, my experience is the opposite (Score:5, Insightful)
I don't generally need superuser access on the machine, since generally the only thing that gets screwed up is the data in the RDBMS (you know, user error).
I had one propellerhead go around in my database deleting tables and columns he felt they didn't need. He told me on the phone "we don't use timestamps here". One of those slam your head on the desk conversations. These are civil servants with lifetime jobs, and maybe they knew all about VAX in 1970, but goddamn if they aren't dense.
They tend to think that RAID is a magical "never need to backup ever" solution. I just love it when they call me up after their second RAID-5 drive failed, and I ask them when they last did a backup - and they go "uhhhh we don't need to backup we gots RAID".
Then I explain how RAID has nothing to do with archival or backups, etc, etc.. And I pull out the backup I made last time they had a major upgrade and tell them they have to reenter every parking ticket for the last 8 months, and they threaten and bitch how it's my fault and I tell them I'm not their admin, and if they really want to go to their bosses and fess up how incompetent they are they can go ahead.
Frankly, I'd love for some more competent clients. Of all of them, I can think of one who has any clue what to do with a computer.
But then sometimes they call with a problem that requires fixing on the machine. I'm not going to sit on the phone talking them through shit, I'm not going to email them scripts or code, etc. More than once I've had to tell them that if they don't give me access it wont get fixed.
If it's a problem for you, give them superuser rights when they need it, when they're done doing maintainance, take it away.
As one who's worked on the vendor side... (Score:5, Insightful)
2. Often, those applications that require Superuser for the installation are third party applications. Install it yourself. You may have more trouble on the outset, but you'll know what's going on with your machine.
3. Often, vendors have their programmers as installers. The bad news is that you see the problems you do with the installations. The good news is that they'll know exactly why they need root - and they'll tell you what they need done. This might need to be a tag team installation, of course.
4. Remember, you can always invite them up there if you want to pay them for their time. Remote access is requested because it's cheaper. Alternatively, put in the contract that you want installation instructions. It will take more time, but you're always welcome to pay more.
Many of these vendor problems are reduced to cost-cutting measures. If you want to pay more, then vendors will be willing to oblige.
What is the big fuss? (Score:3, Insightful)
The standard practice of firewalls to restrict access, and lower priviledge accounts are all good (and important). But the proper protection should have been negotiated into the service contract in terms of access the vendor requires and liability. Durring that negotiation process the technical authority should have considered the security concerns (and added costs). If the technical authority was inept the best you can do is minimize the risks now, and use this example to raise security concerns for the next contracts.
Re:On demand and via a process (Score:3, Insightful)
Then it's written wrong. I want the config files to have permissions for a user named $vendor.
What if the logs produced by the application are only readable by root (or by adm)?
Then it's written wrong. I want the log files written to a location for a user named $vendor.
What if the process is running with root privileges and you need to trace/truss it to perform the diagnose it?
Then it's written wrong. I want the application to run in a chroot or jailed environment limited $vendor and $vendorapp.
There is *no* good reason for a vendor app to run as root/superuser/Administrator. It's poor coding, and poor design. If that's the best your 'cheaper' vendor can do, you'll end up paying more in the long run for support, security problems, and related issues. It's too easy "since you're root" to just change file permissions to make your app 'just work', instead of correcting the application to work within the system constraints.
Re:Vendors are asshats (Score:1, Insightful)
You probably need to do some serious lab testing before considering replacing a $40K+ router including lots of custom ASIC backed routing functionallity, lots of well tested protocol support, extensive measurement data, and good redundancy features with a commodity PC and some Ethernet NICs.