Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Protecting Your Enterprise Network from Vendor App Servers?

Cliff posted more than 9 years ago | from the deny-the-errant-app-servers dept.

Software 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?"

cancel ×

258 comments

Sorry! There are no comments related to the filter you selected.

I want to do dirty things to Emma Watson (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10931288)

is that wrong

mnb Re:I want to do dirty things to Emma Watson (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10931440)

Yes, that is wrong.

How dare you try to weasel your way into our relationship.

(Of course, we are keeping it platonic for now, but come some 112 odd weeks - woo wee!)

Layer 7 Firewall (5, Informative)

passthecrackpipe (598773) | more than 9 years ago | (#10931298)

You need a Layer 7 Firewall, a.k.a. an application level firewall. Something like Zorp is a good start, but you probably need something with a bit more intelligence about the applications you are talking about though.

L7 Firewalls usually get a bad rap because they tend to be pretty fussy in setup, something you can't really avoind with this kind of stuff. Also, if I was in your shoes, I would learn to stop worrying and start loving tight-ass SLA's...

Re:Layer 7 Firewall (2, Interesting)

jrl (4989) | more than 9 years ago | (#10931380)

They also get a bad rap because they don't work :).

It's a pitty they don't teach this stuff in CS:
http://www.dyadsecurity.com/papers/rbac.html [dyadsecurity.com]
http://www.nsa.gov/selinux/papers/inevit-abs.cfm http://www.acm.org/classics/sep95/ rtsp://media-1.datamerica.com/blackhat/bh-usa-00/v ideo/2000_Black_Hat_Vegas_VK3-Brian_Snow-We_Need_A ssurance-video.rm http://www.radium.ncsc.mil/tpep/library/rainbow/52 00.28-STD.pdf http://hissa.ncsl.nist.gov/rbac/paper/rbac1.html

slashdot method.... (1)

pierredefermat (793876) | more than 9 years ago | (#10931402)

application level firewal....bleh...cover all ur servers with a shiny tin foil...be sure to replace them regularly.

Re:Layer 7 Firewall (1)

fimbulvetr (598306) | more than 9 years ago | (#10931493)

Nothing like a good ol' kludge to fix something that should have been done right in the first place.

I think this guy is trying to look for answers to the problem, not quick fixes.

Find a new vendor (1)

Anonymous Coward | more than 9 years ago | (#10931306)

Seriously. If they want root, tell them to fuck off.

Re:Find a new vendor (1, Funny)

Anonymous Coward | more than 9 years ago | (#10931454)

Seriously. If they want root, tell them to fuck off.

and die.

Re:Find a new vendor (1, Funny)

D'Sphitz (699604) | more than 9 years ago | (#10931720)

after they choke on their own vomitus maximus, of course.

Re:Find a new vendor (4, Insightful)

Fallen Kell (165468) | more than 9 years ago | (#10931710)

This is what we do. Seriously, we don't let ANYONE have access. If they "need" root for something, they call us up and they tell us what they need to have done and we do it.

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.

Consultancy (4, Funny)

KontinMonet (737319) | more than 9 years ago | (#10931310)

Well... don't get EDS to work on it [slashdot.org] !

Re:Consultancy (1, Interesting)

Anonymous Coward | more than 9 years ago | (#10931403)

I used to work with EDS via SBC and let's just say they are not the most stellar preformers in IT.

FYI: I worked with their Cisco Jockies and on a few occasions, their Server Admins.

Well hey, they are owned by Ross Perot.

Nuff said.

Re:Consultancy (1)

KontinMonet (737319) | more than 9 years ago | (#10931529)

He sold out some time ago. It was bought by GM, I believe and they recently sold it (as an MBO?).

Re:Consultancy (0)

Anonymous Coward | more than 9 years ago | (#10931522)

I currently work for a large bank's insurance branch that is getting a system installed by an EDS subsidiary (SolCorp), and it is amazing contrasting how restrictive and inhibiting internal network policies are for actual long term employees - even in a senior technology position it is a bitch to get anything done without layers and layers of bureaucracy and empire builders trying to stand in your way - but in comes consultant/outsourcing company and the restrictions disappear. Drop an app server right on the corporate wide network: Hey, why not?!

Tell them to screw off.. (5, Informative)

Heem (448667) | more than 9 years ago | (#10931314)

Seriously.

I built a network for vendor lab equipment that was it's own netowrk, connected to the main network via a file server with 2 nics and NO routing. Therefore, file could be transfered from the lab network to the file server, and then from there to any of the main networks, of course after they had been scanned for viruses and such, since anti virus software usually would not run on their equipment. My rules were firm and backed by higher-ups - if you couldnt get your equipment to work in the enivroment given, or with only minimal flexibility from me (for example i'd write scripts to move their files automatically to the main, backed up network or something simple like that) - then we will find another vendor to provide us a solution that fits. Period. I never had any problem with a vendor once they heard the terms. They won't make money off us if they can't make the system work in our environment.

Re:Tell them to screw off.. (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10931428)

Wow...you're a real badass nerd. I'll bet all of the other ectomorphs at the D&D parties with duct tape on their horn-rimmed glasses are afraid of you.

Re:Tell them to screw off.. (4, Insightful)

ischorr (657205) | more than 9 years ago | (#10931485)

No, he just knows how to actually do the job he's being paid for. Once you graduate high school and eventually enter the *real* world of IT, you might understand this.

Re:Tell them to screw off.. (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10931518)

Gee, I sure hope that when I graduate from high school I can enter the *real* world of IT like you and him--just think how impressed the chicks will be.

Re:Tell them to screw off.. (0)

Anonymous Coward | more than 9 years ago | (#10931444)

Something a little worse is when life has been going along well, you're employed in a good job with sensible manners, and a new bastard manager comes in and among his retarded micromanagement practices is insisting on root access to everything we have any control over. god. it's pissing me off.

The dude runs Mandrake at home, so he has a clue: but only enough of one to be enormously dangerous.

Re:Tell them to screw off.. (1)

Heem (448667) | more than 9 years ago | (#10931467)

and let me guess, the old manager took the stance of " I don't need or want to know the password, that's your job"

Yea, been there.

Re:Tell them to screw off.. (5, Insightful)

Jonathan the Nerd (98459) | more than 9 years ago | (#10931550)

"I often reflect that if 'privileges' had been called 'responsibilities' or 'duties', I would have saved thousands of hours explaining to people why they were only gonna get them over my dead body."

-- Lee K. Gleason, VMS sysadmin

Hell, yes. (1)

cduffy (652) | more than 9 years ago | (#10931954)

I'm senior deployment engineer at one of those vendors (well, not one of your vendors, but similar kind of deal). One of the things I've put the most time into is building a (OpenVPN-based [sf.net] ) administration infrastructure that'll work damn near anywhere. (If we need to, we can even tunnel over HTTP -- hasn't come to that yet, though).

Our integration components are likewise designed to be flexible and nonintrusive -- as much code as possible on our server, as little as possible on the system we're integrating with.

I'd like to think that when we start deploying to larger environments, these efforts will get noticed.

Switch vendors (5, Informative)

31415926535897 (702314) | more than 9 years ago | (#10931327)

Our vendors are notorious for demanding superuser access to the boxes that support their applications.

There are a few things you can do in this case:
1. Get a different vendor (if the application truly does require su for vendor support).
2. Reqest different support staff from the vendor (do this if the app doesn't require su but the support staff is too lazy).
3. Learn how to support the app in-house

I am very serious on these points. You do not want to give root access to people that should not need it. If they say they need it, they have an awful application.

The place I work has a vendor area fenced off from the rest of the server room, and the vendors only have access to what they need. If they need more privileges, the IT guys watch them like a hawk until they're done.

Re:Switch vendors (0)

Anonymous Coward | more than 9 years ago | (#10931432)

I have to agree, vendors shuld not have SU login at any time. I would be curious if any SOX auditors were on board here that could comment to that type of policy for a publicly traded corp.

Your corp really needs to get the skillset in-house.

Re:Switch vendors (1)

over_exposed (623791) | more than 9 years ago | (#10931739)

Isn't SOX only for the medical field?

No (1)

Safety Cap (253500) | more than 9 years ago | (#10932035)

Isn't SOX only for the medical field?

You're thinking of HIPAA.

Sox stands for Sarbanes-Oxley Act [google.com] . It applies to every publicly-traded US company.

Re:Switch vendors (3, Informative)

Eudaemonic Pie (821484) | more than 9 years ago | (#10931491)

Exactly right. Vendors never *need* root on our box. They often *want* it because it makes their job and their life easier. With properly applied permissions, there is very little a vendor cannot do just using the application owner id. The exception being if their app server binds to ports 1024 and they need a restart. Anything else, like oh adjusting permissions of files they don't own, applying OS patches, rebooting the box, killing processes they don't own, etc, etc aren't things I want my vendors doing *anyway*. Depending on the size of your shop, you may have controls or processes in place that require approvals before any of that works gets done, so why let the vendor go around your process if you can't?

Re:Switch vendors (2, Informative)

Eneff (96967) | more than 9 years ago | (#10931603)

Sure... I guess you can install ArcIMS yourself, but if my app uses ArcIMS, and I'm supposed to be installing it on Solaris, I need root access for the install.

At least, it used to... Luckily I haven't been the poor sod to do installs lately. :D

(I do remember the first time I had to install ArcIMS... what a piece of hell.)

Re:Switch vendors (5, Interesting)

ischorr (657205) | more than 9 years ago | (#10931557)

"If they need more privileges, the IT guys watch them like a hawk until they're done." ...And hopefully your staff *is* there for them when they need other access, questions about other pieces of the environment, etc.

I've worked escalation support for a large storage vendor for a number of years, and while I completely understand (and agree with!) limiting vendor access, I find that IT departments tend to be *very* unresponsive when the vendor support folks need their help.

It's not exactly efficient, for example, when I have to wait 7 hours for logs to be uploaded, 5 hours for the "network guy" to respond to a page and fix the duplex mismatch he created that's causing 50% of packets from our systems to clients to be dropped, weeks for the system admin to stop piddling around and get Sun on the phone when we have valid interoperability issues (Sun won't talk to most other vendors except through the common customer), etc.

In the meantime, in my experience, the CIO tends to lambast the vendors for "poor responsiveness" and "terrible support" - though the smart ones eventually realize that the IT staff is shooting themselves in the foot, and do something about it.

IT departments that are responsive to vendors, on the other hand, are a breeze to work with, and issues are typically resolved many times faster.

Re:Switch vendors (4, Insightful)

theonetruekeebler (60888) | more than 9 years ago | (#10931681)

Sometimes switching vendors just isn't an option. There are lots and lots of niche markets where there's that one tool that everybody has to run. For example, at a motorcycle dealerships most parts fiche CDs will only work with a specific parts/sales software tool---which runs on NT and "needs" to run as Admin, even though it is only an elaborate piece of middleware connecting a database to a few desktops running the application. It is (as of mid-2003) also a slow, buggy piece of shit.

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:Switch vendors (1)

h4rm0ny (722443) | more than 9 years ago | (#10931854)



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.

Amen. The OP said that his company had a large IT infrastructure which means they are worth the vendors business. I urge him to apply whatever pressure he can on the vendors to change their ways.

That way, little places like where I currently work might get the same benefit!

Re:Switch vendors (3, Interesting)

cduffy (652) | more than 9 years ago | (#10932030)

There's a different kind of situation:

That where the vendor's software is on a "black-box" machine that only they have administrative access to, and which runs no other software.

I'm (senior deployment engineer at) one of those vendors. Not only is our app fairly complex to administer, but every server that goes out contains a copy of the "secret sauce" -- not our application itself (which our bigger competitors could probably recreate in 9 months or less), but the data behind it (much more expensive and difficult to recreate). Consequently, our management is paranoid -- the servers are rigged to self-destruct (wipe the keys that allow them to decrypt the partition where all data is stored) in the event that any attempted tampering is detected, and can only be reenabled by the very small subset of our staff w/ access to the private keys.

Right now our app has components that run as 4 different users (to isolate breakins to the component where they occur), and includes a firewall and a VPN solution (both of which need root for obvious reasons).

Since it's our box that's running the app, and that same system does nothing else -- why restrict our access further? Absolutely, firewall us off from anything we don't need -- but restricting access to our box seems silly (and is something we'd consider only for a very large customer -- which is just as well, since the small folks we're selling to right now haven't had a problem).

In any event, I'm curious to hear how you'd respond.

make sure everyone understands what the problem is (2, Informative)

discogravy (455376) | more than 9 years ago | (#10931329)

if the app NEEDS to run, you put it on a DMZ and let the world have at it. If they want internal access....make an effort to secure it and when they say they can't do that, get it in writing -- email will do if you've already got that -- and make sure you've secured everything you can. Not much else you CAN do, unless you're the boss.

Just MHO (1)

neilb78 (557698) | more than 9 years ago | (#10932018)

but I think DMZs are overrated.

Uhmmm no! (0)

Anonymous Coward | more than 9 years ago | (#10931330)

Tell them you need root on one of their machines before you'll renew the service contract. Seriously, no competant organization should be giving 3rd parties root.

On demand and via a process (2, Insightful)

Anonymous Coward | more than 9 years ago | (#10931332)

Only give temporary access to allow agreed changes to take place. Superuser isn't required to diagnose problems, only to fix them. This also gives some stability as 3rd parties don't enter and alter things as they please.

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.

Re:On demand and via a process (2, Insightful)

44BSD (701309) | more than 9 years ago | (#10931723)

How can you say that superuser isn't required to diagnose problems?

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?

Don't let them (4, Informative)

illumin8 (148082) | more than 9 years ago | (#10931343)

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.

Simple answer: Don't let them. This is standard operating procedure in the financial services industry. Do you think that a bank would EVER let a non-employee or non-contractor access any bank system whatsoever? Especially remotely? If these companies want to do business with you, they WILL play by your rules or you'll pick one of their competitors products. In my experience, the only companies that required remote access to their systems were ones that A. Didn't have a fully working product, and B. Had to have the developer log in constantly to patch binaries with the latest bug fixes just to get a semi-working product. These are not the type of companies you want to do business with in the first place.

Speaking as a sysadmin for a smallish financial services company that processes around 1.2 million transactions a month, I would NEVER allow any vendor remote access to our network. It just wouldn't happen. Even if I did want to give them access, there are rules and regulations that strictly forbid my giving them access. If they give you a hard time, make something up about a security audit or something.

Seriously, you are asking for trouble if you let them have access. Who's going to take the blame when one of their developers logs in and wipes out all of your company's data? Chances are they'll blame it on you and you'll be in trouble for their mistake.

Re:Don't let them (2, Insightful)

TheRealFixer (552803) | more than 9 years ago | (#10931429)

I have to agree. There's very little need for a vendor with a good-working product to have to have that kind of anytime access into your network and servers. And with nebulous new legal requirements like HIPAA (for medical companies) and Sarbanes-Oxley (which the government doesn't even know what it means yet) giving such access to vendors could give you serious trouble in an audit, even with the requisite NDAs and various contracts.

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:Don't let them (2, Informative)

RobK (24783) | more than 9 years ago | (#10931495)

I agree with these guys.

1. Because you're smart enough to ask this question, you've shown that you should be capable of handling the boxes and applications (even if you don't have the time to do it)

2. The vendor should know their product well enough to give instructions or ask for debug information from you about the configuration/logs and so on.

3. Do you have the time to fix it when they screw it up?

Re:Don't let them (2)

pentalive (449155) | more than 9 years ago | (#10931525)

That's all well and good, if management backs you up. On the other hand if management says "We don't care, We need this application, just make it work".

Management has been known to say things like this even with
detailed notifacation of exactly what access the vendor is getting
to the company network.

Amen (2, Insightful)

jackb_guppy (204733) | more than 9 years ago | (#10931620)

With the internet and remote admin tools coming / have come to full potential, vendors keep coming to ask for this more and more.

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 :: Speed on Highway and Number and Color of Cars traveling in pack/line. Some great laughs later over some good wine.

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:Don't let them (0)

Anonymous Coward | more than 9 years ago | (#10931869)

Can I please work for your company, the financial services company (one of the top 5 banks in the US) blatantly disregards security and allows vendors access to anything they need to get their horribly written apps to work.

My suggestion (5, Insightful)

oexeo (816786) | more than 9 years ago | (#10931361)

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.

What can you suggest?

Find some better vendors?

Two things... (2, Interesting)

Sheetrock (152993) | more than 9 years ago | (#10931382)

First, as a security-conscious customer you should make your vendor aware of your concerns as well as places where their application violates your security standards. If there are times when their applications require root where it is clearly not necessary, it's a sign that attention may not have been paid to SDP (secure design principles) during the production of the product.

If a vendor is unsympathetic to your concerns, it's up to you to find an alternative or work around them. As you explain, the second option is not always possible when they require access to a number of services at a fundamental level. The worst cases of this occur when you have one or two vendors to pick from for a given application. My suggestion is then to design the application yourself within your security parameters and functionality requirements -- as many people do not have that capability within their own ASP (otherwise they'd do it already) you might want to use something like Sourceforge and contract a team overseas to do it cheaply, supervising the project from here and optionally open-sourcing it after it's built. Then you've got something designed to your parameters without support or upgrade costs especially if the community digs what you've built.

contract (2, Funny)

nes11 (767888) | more than 9 years ago | (#10931384)

Can you not just write a contract that holds them completely liable for all damages, losses, downtime, etc caused by that machine? Then give them the option of whether or not they need to be a superuser that badly.

Vendors are asshats (4, Interesting)

Anonymous Coward | more than 9 years ago | (#10931388)

Seriously ... . I'm a sysadmin for a medium sized accountancy company, and you wouldn't believe the number of vendors I've had to beat off. I end up talking them down to lower levels of access, all the while listening to the lusers talk down to me as if they knew more about running it on *my* network than the local sysadmin.
In the long run though, I've figured that these lusers are going to be more trouble than they're worth, and am talking the boss into replacing the NetApps and Junipers (routers) with Gentoo Linux boxen. So in short, don't protect, just reject!

Re:Vendors are asshats (1, Funny)

Anonymous Coward | more than 9 years ago | (#10931475)

you wouldn't believe the number of vendors I've had to beat off

Dude...I bet your arm is *tired*. Was it good for them?

Ewww.... (1, Offtopic)

caveat (26803) | more than 9 years ago | (#10931483)

...you wouldn't believe the number of vendors I've had to beat off.

Well, I hope you at least wash your hands after each one ;)

Re:Vendors are asshats (0)

Anonymous Coward | more than 9 years ago | (#10931489)

Replacing Junipers with Linux boxes? Uh, good luck with that one.

Re:Vendors are asshats (0)

Anonymous Coward | more than 9 years ago | (#10931594)

If you're going to replace routers, you should do so with the right tool. Like say, OpenBSD. Use the right tool for the job and all that...

Re:Vendors are asshats (0)

Anonymous Coward | more than 9 years ago | (#10931641)

*shrug*, they're both Unixes, and Gentoo boxen will be provably faster due to being compiled with optimisations for your exact architecture.

Re:Vendors are asshats (0)

Anonymous Coward | more than 9 years ago | (#10931680)

FYI, the OpenBSD packet filter (pf) is much simpler to deal with (and thus configure correctly) than iptables. And I doubt you'll really notice any difference in speed. Also OpenBSD has a new cool feature (CARP) that allows for multiple boxes to automatically monitor themselves and have one do a failover if the other dies. Could be useful if the router has hardware failure...

Simple use a Firewall (3, Insightful)

cybrchld (229583) | more than 9 years ago | (#10931390)

I have a similar configuration between two in house networks I use the firebox X700 in routing mode it allows me to open only the ports needed to be routed between the networks and also allows me to monitor all traffic to keep an eye on the test network side.

VPN (3, Informative)

Julian Morrison (5575) | more than 9 years ago | (#10931391)

Create a dedicated VPN. The misbehaving app server sees only this VPN. Everything it needs to access has a presence thereon, carefully firewalled to allow the relevant ports to open. Everything it doesn't need to access, is not even on the network.

Additionally (1)

ink (4325) | more than 9 years ago | (#10931501)

The VPN solution is great for the Vendor Company portion of the link, but I would also suggest a "vendor firewall" if you need to extend that service down to machines in the internal network (eg, stores in a grocery chain). The Vendor will *only* see their appserver from the outside, and their appserver will *only* see the vendor's devices internally. Good luck securing the actual end devices; unless you have each device behind a layer 2/3 firewall of some sort. Assume that the vendor can do anything with their devices, and try to limit/monitor their actions as much as you possibly can. The whole "root access" is a red herring, unless it's root access on one of *your* servers that they are requiring (which I would vigorously fight against); nmap, rdesktop, etc. all run without "root" privileges.

service accounts... (2, Informative)

Anonymous Coward | more than 9 years ago | (#10931396)

I'm an IT guy who does applications managment for an Air Force network and this is a problem that we have run into as well.

Exchange Service accounts, NetIQ accounts running as Domain Admins etc.

This is generally not a good idea, but for your average IT admin superuser domain level rights were the only way to have those programs function properly for the longest time. However, one simply solution that I have just recently tested with our NetIQ application managment Server is to create the local service account on say...our SMS server not as a domain admin, but just as a local admin. If I do this I can avoid giving blanket access to the entire domain to that program, and I can control which servers have that particular service account on them.

Obviously its not a total fix, although luckily for us, server 2003 has eliminated a lot of the most common "null session" issues that were such a pain to hunt down and change manually.

The only other thing I could suggest is creating a test-bed network and installing one of the suspect application servers at a time and using a sniffer capture program to see which ports have what sort of protocol activity over them. Document the information, test several application servers at a time, shut down uneeded ports and then implement it on your network. *with approval of course ;)*

I do hope that I haven't completely misunderstood your problem.

Re:service accounts... (1)

PigleT (28894) | more than 9 years ago | (#10931477)

> see which ports have what sort of protocol activity over them. Document the information,

Why not buy from vendors who list their dependencies properly?

You're a girl right? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10931400)

"Hey baby, what's your ip?"

Heh heh heh"

--the Suavest mofo on the planet

What about VPS? or UML? (1)

terminalrecluse (830632) | more than 9 years ago | (#10931411)

What about running a Linux VPS or UserModeLinux?

VPNS are handy... (4, Informative)

eldub1999 (515146) | more than 9 years ago | (#10931419)

We force the vendors to enter via VPN. we use the VPN gateway to restrict each vendor account's access to only the IP addresses of the systems they need access to. Further, we occasionally use a packet sniffer to watch certain vendors.

We disable the account by default and require them to contact us and tell us what they are doing (change control) before letting them in.

Works for us.

Doesn't solve the problem (0)

Anonymous Coward | more than 9 years ago | (#10931629)

A VPN can keep their connection to your box encrypted, but it doesn't control what they do TO your box through that connection -- and how it might affect the rest of your network.

Also, because VPN traffic is encrypted, you can't use a packet sniffer or intrusion detection system to watch it. Maybe you can position your sniffer or IDS to watch it after it emerges from the VPN link, but it does limit your network topology options.

They can screw up without root (4, Interesting)

Burdell (228580) | more than 9 years ago | (#10931426)

I work for an ISP, and we do not give anyone outside the system/network administration team root access to anything if at all possible. We have given network vendors (Redback and Ascend/Lucent) remote access to a device a couple of times (we changed the passwords on the particular device before and after), and we have one web application that we had to give the vendor root access for setup (but that was on a dedicated server).

Our antispam server is a dedicated server, but it still was screwed up once by the vendor. We were having a problem (only half our mail was actually being processed by the filters), and management directed that I go ahead and give the vendor support person access to the server (as the user the software runs under). He logged in to look at it, and within minutes the system was broke and mail was queueing up because the antispam software shut down and wouldn't restart. He had seen something unrelated to our problem that he thought didn't look right and decided to "fix" it for us. As soon as I got him to change it back, I told him to log out and removed his access (and they won't ever get it again).

After that, the only other time we considered allowing a vendor access was on a problem case that was over a year old that we had to have fixed ASAP. However, in that case, we were NOT going to allow remote access; the vendor was going to have to send somebody to us and we'd sit him down in front of the console (which would be logging) with us looking over his shoulder.

The only people that know your systems and network are your people (and you'll make enough mistakes). Vendors should not have access to change things at any point; at most they should get a "view" type account (they can look all they want but they can't touch). If something needs changing, they need to tell you and you can make the change (after evaluating it and having a back-out plan). For complex systems, you never end up installing software exactly the way the vendor specified; they are not going to know or understand changes you made for your local configuration (and how such changes affect other services and systems). Even a well-meaning "fix" can cause serious problems, and since it'll be your job to fix them, you better know what was done.

Shameless plug (1)

GomezAdams (679726) | more than 9 years ago | (#10931496)

Call IBM Strategic Outsourcing - we do that everyday for some of the largest global corporations on the planet.

Re:Shameless plug (0)

Anonymous Coward | more than 9 years ago | (#10931631)

Piss off! IBM SSO has disbanded and all but moved to Bangalore. The few remaining elements that are based in the UK and US are being moved to the Indian 'super bridge' once it's completed.

That and the sly bastards are moving a load of customers through the back-door who seriously do not want to go to India.

If you want to go via this route give Accenture a call, if you really do want IBM to look after it then make damn sure you tell them you DO NOT want to be sent to India, the IGSI's make a dump truck look smart.

-- Former IBM SSO Operator.

Re:Shameless plug (3, Funny)

jellomizer (103300) | more than 9 years ago | (#10931646)

No just threaten to call IBM global outsourcing. That usually gets the venders to play nicely. But if you Really get IBM inside your company you will reach new levels on non-productivity. Just because they manage the largest global corporations doesn't mean they are good.

Vendor Applications (1)

mnbitcrazy (561619) | more than 9 years ago | (#10931499)

Don't think of this as a small scale issue. Design "security zones" providing the requirements for the enterprise, the vendor and external connectivity. An ASP environment is a long way toward that goal. If the company you work for is serious about security, they will be willing to foot the bill for a completely independent network security zone for the vendor application(s). Contact the most appropriate vendor for your firewall (Checkpoint comes to mind) and discuss the options with the vendor. Then, make sure you log everything important in the firewall. Another completely independent network that makes sense to have available is a management network. Separate from the "data network" and definately in a different security zone. It should be a separate "security zone" from your general data network. It might also make sense to connect to it only by VPN. This network would contain all of the SNMP and console activity. This can be built on a general network using GRE tunnels (IPSec if you really desire security) and/or extended with L2TP. At the very least, you would have sufficient logging in the VPN and system to track vendors activity. I would also consider building a completely separate non-routed network for backup. Offload all backups to a network that doesn't touch any other environment. Also, if a vendor wrote a program that can only run as su -, find another vendor. Their application was written unrealistically. So, in the end state, you'll be running multiple networks. Keep it simple, separated, secure and logged.

I don't meen to be mean, but? (-1, Troll)

NetNinja (469346) | more than 9 years ago | (#10931507)

It sounds like your more of a help desk person than an IT administrator.
If your vendors are managing your servers then why are you there?
It's time to justify YOUR position at your company.
Any monkey can press the on off button.

RDBMS (1)

CaptainZapp (182233) | more than 9 years ago | (#10931519)

(Disclaimer: I was working for Sybase Professional Serives from 95-99)

You may want to have a look at a Sybase [slashdot.org] product called Replication Server [sybase.com] , which permits you to distribute your data in near real time.

Even though it is not a simple product, setting up a warm standby is fairly straight forward and relatively simple. By setting up appropriate firewall rules you can ensure that the connection is in one direction only. As an added bonus you are better set up in case of a desaster.

The RDBMS in question need not to be Sybase ASE. It works fine with just about any major RDBMS. In fact: There are Sybase customers that use Rep Server in order to replicate from Oracle to Oracle, since Oracle "Replication" just plain sucks!

Hi, I'm your vendor (1, Funny)

Anonymous Coward | more than 9 years ago | (#10931524)


I'm your vendor. I need root for about a half an hour to fix some things.

Also, I need your ATM card and pin number, I need to fix that as well.

Don't forget to give me your house keys and please have your wife put on her negligee.

I'm glad we have a meaningful working relationship.

I go through this all of the time (5, Informative)

flying_monkies (749570) | more than 9 years ago | (#10931554)

From the vender side.

First: It's amazing how many people haven't got a CLUE. "Don't give it to them or get another vender" isn't an option. When you're running a 24x7x365 system and expect sub 1 hour response time from your venders (our customers do) you're going to have to give some.

All of the boxes we hook up have phone lines into them. If security is an issue on dial-in access, we set it up as follows:

Modem is enabled dial-out only, no dial in access.
If the box dials home, we contact the administrator, identify who we are and which box has troubles and have them enable access to the server/hardware and reset the root password temporarily on the box. This occurs only if it's something we haven't already configured to work with sudo.
We then keep logs of the entire session, then email it to the customer when we're done.
When we're done, we have them reset the root password and disable dial-in on the modem again.
If we require access to a network resource from the machine, we're onsite with the customer shoulder surfing.

We do this at secure military sites, financial institutions, etc. and have yet to have an issue in 20 years.

Re:I go through this all of the time (0)

Anonymous Coward | more than 9 years ago | (#10931640)

First: It's amazing how many people haven't got a CLUE. Don't give it to them or get another vender isn't an option. When you're running a 24x7x365 system and expect sub 1 hour response time from your venders (our customers do) you're going to have to give some.

Right on! The only network most of these posers who post these 'tell the vendors to shove it' comments are administering is their clapped out Pentium II Linux box attached to their little sister's Windows ME box and their Mom's Dell with Windows XP Home in some half-assed Samba configuration.

Re:I go through this all of the time (0)

Anonymous Coward | more than 9 years ago | (#10931674)

While an "OK" solution, what's stopping you from fudging the logs you send back to the customer?

Keep a close eye (0)

Anonymous Coward | more than 9 years ago | (#10931567)

We allow them onto only a pair of servers, all vendors come in this way. Then require them to use Symark's PowerBroker or PassGo's UNIX Privledge Manager (basically the same product) to handle authentication and connection to the system their software is on. Both products perform keystroke logging and other helpful features.

You can let them have their access, and watch their session in real time.

Several different possible solutions (3, Funny)

postbigbang (761081) | more than 9 years ago | (#10931579)

1) write in to the SLA policy-- a SU agreement with liablity
2) use (as mentioned) a L7 switch (Telena has one, too)
3) give temporary access, and make sure you check for root kits everytime with a script
4) tell your management just how expensive it is to have so many vendor's spoons in the soup and how potentially destabilizing it is to do this
5) use smart token card access coupled to your own CA; Tie the proximity of the card via RFID to a pacemaker attached directly to the aorta. If they lose it, they die. Simple.
6) partition roots across servers. Get an SNMP trap when they logon to keep track of them. Set a script against cron to send an additional alarm when they're on for more than a few minutes or upload more than a few megabytes through specific ports (indicating massive changes rather than remote control screen delta)
7) ask for one of their children for hostage use

Check-out the FreeBSD jail facility (4, Informative)

Diomidis Spinellis (661697) | more than 9 years ago | (#10931623)

[I know this will cost me karma points.]

The FreeBSD operating system provides the jail(2) system call and the jail(1) command for imprisoning a process and its future decendants. The jail facility is based on the chroot(2) implementation, but prevents well-documented means to escape chroot confinement, offering partitioning of the file system, process, and networking namespaces. The facility removes all super-user privileges that would affect objects not entirely inside the jail.

For more information read:

  • Poul-Henning Kamp and Robert Watson. Jails: Confining the omnipotent root. In Proceedings, SANE 2000 Conference. NLUUG, 2000.PDF [freebsd.dk] , HTML [freebsd.org] .
  • Poul-Henning Kamp and Robert Watson. Building Systems to be Shared Securely ACM Queue vol. 2, no. 5 - July/August 2004 HTML [acmqueue.org]

Re:Check-out the FreeBSD jail facility (1)

illumin8 (148082) | more than 9 years ago | (#10931824)

The FreeBSD operating system provides the jail(2) system call and the jail(1) command for imprisoning a process and its future decendants.

This, and other type of chroot environments work great for certain applications, but there is the problem with low-numbered ports in that nobody other than root can create a listener on a port numbered lower than 1024. Many programs that require low level ports (like BIND) don't run as well in a chroot environment because of this. Then the developer has to write what is known as an egg or a function that executes with SUID privileges and "hatches" in order to allow access to the lower numbered port. This opens up another security hole because now the SUID function or egg can be exploited to allow a remote attacker to gain root or elevate privileges.

So I will agree with you that good system administration practice requires that you run a lot of processes in a chroot jail, however there are a lot of cases where this isn't possible, especially with closed-source commercial applications.

Re:Check-out the FreeBSD jail facility (0)

Anonymous Coward | more than 9 years ago | (#10931930)

> This, and other type of chroot environments work great for certain applications, but there is the problem with low-numbered ports in that nobody other than root can create a listener on a port numbered lower than 1024. Many programs that require low level ports (like BIND) don't run as well in a chroot environment because of this

This is why FreeBSD have jails. You give them root access into jails, where they can bind low ports (jails have their own IP addresses). In one word, it is exactly as if they had a box for themselves.

And even root cannot escape a jail. Read about it, it is much better than chroot and of lower cost than vmware esx, or other virtualization software.

A technique (4, Funny)

Gyorg_Lavode (520114) | more than 9 years ago | (#10931645)

A technuiqe my work employed to get people to stop requesting things is to make some simple form to fill out to get what they want. But then require 2 or 3 signatures. (Their supervisor, their company sponsor or contact and their own.) Then you take 3 or 4 weeks to process any of these forms, (purposefully). And you deny half of them.

Then you make your policy strictly exclusionary. And when they say "BUT I NEED THIS!", you say, "Ok, fill out a form 23" or whatever the form is. They'll learn quickly that they aren't going to get many of them approved and they'll start putting them in only when they really need them.

So .... (1)

gstoddart (321705) | more than 9 years ago | (#10931742)

A technuiqe my work employed to get people to stop requesting things is to make some simple form to fill out to get what they want. But then require 2 or 3 signatures. (Their supervisor, their company sponsor or contact and their own.) Then you take 3 or 4 weeks to process any of these forms, (purposefully). And you deny half of them.


You've decided to follow the mantra of the BOFH and keep your life simple.

It's a well-used policy. =)

Re:A technique (1)

JamieF (16832) | more than 9 years ago | (#10931912)

Might as well tattoo "PLEASE OUTSOURCE ME" on your forehead.

Get them before you buy the application. (1)

jellomizer (103300) | more than 9 years ago | (#10931669)

When the vender begins to sell you their app. Bring up these Issues about not allowing them to have super user access. It is just that simple. When then make them sign a contract that they will not use. And if they begin demmanding then the contract is null and void. Just that simple. Just be smart when buying products. Especially Canned apps.

Call Microsoft (1)

terminal.dk (102718) | more than 9 years ago | (#10931670)

And have them revoke the suppliers rights to sell products for Windows, since they haven't got a clue.

I am working in a big company, and if the vendor do not spend the little money to fix their broken app, we will pick another. If they haven't got a clue about security on a network, they are are too dumb to deliver software for us.

How to do it. (1)

rice_burners_suck (243660) | more than 9 years ago | (#10931678)

Dude. Run all your apps in a jail (FreeBSD), UML (Linux), virtual machine like VMware (Windows), etc. When they need to be networked, tunnel the connections over SSH. So you'll have several "layers" of network running over the same physical network.

Say you have an ERP application from one vendor, a CRM application from another, and middleware from another. On each server at your facility, run a virtual machine and run that application in the virtual machine. Connect the virtual machines through SSH tunnels that run from virtual machine on one physical machine to virtual machine on another physical machine.

This will increase processing time, necessary hardware, administration, etc., in other words, COST, but this can be considered a necessary security cost.

In the meantime, I would get a software development department, organize a SourceForge project for each application you guys need, or join an existing such project, and implement in-house free software versions of the same things. You can rest assured that other businesses have similar needs, and these free software projects will eventually replace the expensive vendor controlled versions that you run now. This will decrease costs in the long run.

Let them run under VMS (2, Interesting)

Anonymous Coward | more than 9 years ago | (#10931708)

...since VMS has a finer grained privilege system which has no such thing as "superuser" (though heavily priv'd users are possible). In addition there are third party and builtin controls available that allow things like limiting which files/directories/devices even super-priv'd users may get to, may allow certain programs to have privs without the maintenance accounts having them, hiding some storage from programs, etc. etc. Also while a program can be permitted access to kernel space, the privs to do that are distinct from those allowing filesystem access or network access. You can (and should) ask why any extra privs are needed, and can track their usage. Modern VMS runs only on Alpha or IA64, good performing processors but not x86. On the other hand the fact that the underlying instruction sets used are not x86 means that everyman's buffer overflow exploits tend not to be engineered for the machine. That programs typically never run in fully priv'd environments (but are given privs they need for legitimate use only) limits too what mischief buffer/heap overflows and the like may do.
If you need to run more safely in x86, I would suggest having a look at SELinux (from NSA) which gives some better controls than usual. Pay special attention to protections of devices, especially some of the more dangerous ones like /dev/kmem, and expect to spend a lot longer setting all that up than you would in VMS, which ships secure out of the box.

Non-technical reasons! (3, Interesting)

TheLibero (750207) | more than 9 years ago | (#10931711)

Sometimes those a$$holes ask for such things in order to get better view of your infrastructure and update their sales account with information about you. Let me use a non-technical example here. You own a super store that is specialized in Sports clothing. You have a 5-year contract with Nike to supply you with trainers. The contract is gonna expire in 6 months. Also, you have another contract with Puma to supply you with arm bands. Recently, customers have been complaining about the quality of those arm bands, so you contacted Puma (now imagine that in IT world), Puma sales would ask you if they can send a representitive over to check the stock you've got. They do that not only to check the stock, but to check what other products you've been stocking from competitors, so they can update their accounts and have better picture of the areas they have competiton in, and against what companies.

There is big marketing battle just behind you!

heh, my experience is the opposite (5, Insightful)

stratjakt (596332) | more than 9 years ago | (#10931764)

As one of those vendors for governments, I have to constantly deal with some moron admins who refuse to give me any access to the machine, yet CONSTANTLY call for support.

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.

You don't (2, Informative)

bahamat (187909) | more than 9 years ago | (#10931782)

You do NOT let outside users have access to production systems as root (or as any other user). When they ask, you tell them to stop smoking crack and make them tell you how to fix it. When they ask again, instead of root, give them the middle finger, and them make them tell you how to fix it.

You need to learn to do things on your own. Calling up the vendor and handing them root to fix your problems merely makes you vendor dependant, and in my opinion any SysAdmin who does that should be fired. If I were a manager, why would I continue to employ SysAdmins who only call the vendor every time there is a problem? I would be thinking to myself that not only am I paying this bozo a huge sallary, but I'll be paying for the support contract forever as well, and not just for one system, but for however many app servers you've got. Why not just hire someone for minimum wage to dial the vendor when there's a problem than pay someone who is suposedly highly trained but can do nothing for themselves?

I'm not a manager, but I am the lead SysAdmin for an Internet services company. We have about 40 servers and about half as many networking devices (managed switches, firewalls, load balancers, etc). Whenever we get a new type of device we do end up calling the vendor quite a bit, but we always make sure they teach us the solution and we impliment it. Over six months or so as I learn all the ins and outs and bugs of the device we no longer need to contact the vendor. I have a team of three people, and if one of them gave a vendor the root or enable password on any of our devices I'd have them fired for network security breach, and if they weren't taking proper steps to learn a new device on their own I'd have them fired for incompetence and replaced. There are too many smart people out there to keep employed dumb ones, especially for the price tag SysAdmins deserve.

A bad sign (0)

Anonymous Coward | more than 9 years ago | (#10931805)

When your vendor is wearing this t-shirt [auctionworks.com] it's a bad sign.

Of course, it could be worse [ecompanystore.com] .

As a vendor, customers are idiots (2, Interesting)

scorp1us (235526) | more than 9 years ago | (#10931829)

Let me qualify explain that statement. I support a small web-based application. It'll win on Unix or Windows (under Apache & PHP) I don't care about that stuff. But what does piss me off is when we have to port the app to every DB MS under the sun. Our support costs go through the roof just because the customer wants it their app DB.

Well, try explaining to IT (not a smart bunch, after all they dropped out of CS (or never even tried)) that their DB du jour is not up to the task of our RDBMS. True 90% SQL compliance is a good start, but there it is impossible to create a full-featured app and still be completely agnostic.

Examples: MySQL is the worst. The last insert ID is a horrible concept that is not portible. Try finding it in Informix, it is impossible to find, but exists. Thent here is the MySQL timestamp 'feature' - the first timestanp field (and only the first) when UPDATEd is updated to NOW() regardless of whether or not you include it in the updated feilds.

The only reason why they want the DB changed is because they have lazy IT departments that want to do nothing. Their IT staff does not understand the complexities of SQL DBs to them it is just an DB, and "thay're all compabible through SQL" yeah, right. "What about ODBC?" ODBC is fine for basic record operations, but the moment you try to do anyhing advanced, you're out of luck.

I used MySQL as an example, but I've worked with several other Databases, and there is no Holy Grail of DB abstraction. There's much more to databases than inserting updating, deleting and selecting rows, depsite what IT thinks.

Addendum (1)

scorp1us (235526) | more than 9 years ago | (#10932002)

I realize that my tiraid may not have been completely explained. We have no problem installing our required DBMS on whatever server or OS (customer's or provided by us), but so many times they will not install our DBMS on their production servers, so we end up with our own app server.

This is not my fault, this is theirs. They want to take no risks with disrupting other things, so the price of that is another server. They bring it on themselves.

My angst is directoed towards the ones who will not install our seotware on their servers, won't provide an app server, and demand that I MUST port it to their DB. It works for selling to large companies, but when you're talking hundreds or thousands of new isntallations a year, I just cannot port to every DBMS under the sun.

So your spp server problem is one that you can point the finger back at yourself for. You seem to know more than the company who wrote the software from the ground up. After all, we know nothing about databases, and we picked the wrong one from the start....

UML? (1)

macemoneta (154740) | more than 9 years ago | (#10931838)

Depending on the nature of the application, you can give the vendor a UML [sourceforge.net] machine and its root access. This lets them do what they want/need to, without compromising your environment.

Limit Access, Reduce Need, Monitor & Control A (1)

parr (61445) | more than 9 years ago | (#10931852)

When saying NO isn't a valid answer...

1) Limit their access to their boxes using a good VPN solution. Limit their access to your secure network components to just the specific ports needed, using both source and destination IPs with a stateful firewall and good access lists.

2) Reduce their need for access. Build the servers boxes on VMware to allow you to grow the hardware without costly reinstalls by them. Costly is defined here as your $$$ and your labor. You keep a backup of the machine before they mess it up, and it also lets then do trial upgrades using real data on a clone of the server. Restore it easily.

3) Monitor it to the max. Catch their problems before they do. Save the day. Enable SNMP within the LAN, set up thresholds and alerts. Then correctly install a real IDS solution on your network. Be Big Brother on your Network

Be Proactive, by building IPsec VPNs, VLAN's with Firewalls, Monitoring & IDS for inspection, And using VMware where possible can provide many of the solutions.

Remember it is your network, and it may be your job when it all hits the fan, and
It may also be your promotion when you save the day.

The Solution! (0)

Anonymous Coward | more than 9 years ago | (#10931863)

The solution lyes within... OpenBSD. Very clean, lean, simple and secure, yet no mess to your existing infrastructure - worth checking out - www.openbsd.org.

In other words, VLAN + PF their asses or Transparent Bridge + PF them... So many solutions to this, you just need to look at the various options provided, within.

As one who's worked on the vendor side... (4, Insightful)

Eneff (96967) | more than 9 years ago | (#10931879)

1. Smaller niche vendors usually don't have the hardware or manpower to simulate your system. You went with them because they were half the price of dealing with IBM, remember? :)

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.

two solutions (1)

blackhedd (412389) | more than 9 years ago | (#10931884)

We make an "appliance" product which is a package of applications in a locked down box. The root account is disabled and the root password is scrambled. After we ship them, NO ONE (not even us) can log in as root. There are only two user accounts, one for config and the other for upgrades. Neither one has any ability to open a "normal" shell like bash.

No one has ever complained. And we do service them 24/7/sub-1 hour.

But here's something farther out: how about contracting with someone (either the vendor or some other provider) to run the apps themselves on your behalf? How does everyone feel about that? Is there an important class of applications for which this is an acceptable option?

Why the hell?.... (1)

dacarr (562277) | more than 9 years ago | (#10931909)

For somebody who is simply selling you software to require that level of access to a server - ANY server - is illogical and a probable security hole. Might I suggest using the wheel?

Ball-Peen Hammer on each of his fingers (1)

TheHawke (237817) | more than 9 years ago | (#10931911)

I'm admin for a optical shop and when they asked for root, thats just what I told him.. I also said "That IF I EVER allow you root, it will be through remote secure desktop and I WILL be watching your every move! AND, if you do get stupid with that mouse I will pull the plug and call your boss, is that clear??"

They quickly agreed, since I got layered security in place (router, software, NAT, etc..), they'll have the devil's own time just making the attempt since it'll take me an half hour just to configure the network to allow for tunneled access.

Pure and simple. Oh, and forge a contract in stone saying that if you do allow access, you wash your hands of any fuckup that they perform, since it's their own dammed fault in the first place. And ah, if they do fuck it up, both contracts are broken, their boss gets a nice call from your attorneys, PLUS your own boss, etc, etc.... IE, Things MIGHT get a little ugly for the vendor in question.

IF they want your business, they will have to cooperate with you in order to maintain a good business relationship.

After all, it's a buyer's market right now.

What apps and what OS? (1)

Sai Babu (827212) | more than 9 years ago | (#10931915)

Just curious, having never run into the problem.

This was solved a *long* time ago.... (1)

whitroth (9367) | more than 9 years ago | (#10931926)

Back when I started, working on mainframes, the standard, everywhere, was that you had a development environment, and when you were done making your changes, you passed it over to the admins, who moved it into a test environment that replicated the production environment (often with less data, but otherwise identical), ran regression tests, and *then* put it into production.

Oh, but that's mainframes, where they run whole companies, not workstations/servers that, uh, oops... Well, maybe you could lower yourself to provide a real test environment for the vendors, and y'all from the company take responsibility for final testing and promotion to production?

mark, m'frame, *and* pc, *and*
workstation/server experience
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>