Slashdot Mirror
Web Services - More Secure or Less?
visibleman asks: "I have recently moved onto a project which is based around web services and SOAP and have, therefore, been doing some reading on those subjects. One thing which keeps coming up is that web services are claimed to be more secure than CORBA and RMI because it means drilling less holes through firewalls. If I was a firewall administrator (I am not, I am a developer) I would want to know that if I open up a port (port 80 for instance) I know what kind of requests are coming through it. Since SOAP is essentially a mechanism for sending functional requests over a port specified for web page requests this would make me nervous. My preference would be that requests for web pages go over one port and requests to run services go over another - favouring an IIOP solution. Am I off my trolley or would other Slashdotters have similar fears?"
The security or insecurity of a service has nothing to do with whether or not the request can be brokered by a webserver. All this really accomplishes is setting up the webserver as a massive single point of failure, and making it harder to audit what services a particular box is running.
When you use the paradigm that each service has an associated port, you can be sure that nobody is running any unknown services merely by blocking ports. When everything is on port 80, the firewall becomes much less useful.
I don't think it matters which you use. Allowing people to make functional requests to programs inside your firewall is just as much of a security risk either way. I actually think the function call model is an evil, misleading, broken way of thinking about messages over networks, but like several other practices, people seem bound and determined that this is the way to do things. If you must do this evil thing, it probably doesn't matter (from a security standpoint) how you do it.
The only thing you really gain by not going through port 80 is that the attacker theoretically won't be able to break into your web server software by breaking into your RPC software, but I wouldn't count on that being the case. Besides, either way, they've gotten onto your box, does it really matter how?
Holes in firewalls aren't intrinsically bad things. It's what they lead to that's the problem.
Need a Python, C++, Unix, Linux develop
Off the trolley, I'd say. It's a fundamental and unavoidable weakness of packet firewalls that they filter ports, not services. It's completely naive to believe that port 80 will always be harmless HTTP traffic. ANYTHING can run on port 80, and there's nothing you can do against it unless you have absolute control over all machines behind the firewall.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
I agree with you, the seperation of the ports is more secure due to the fact you need to do less filtering to monitor the incoming requests. However this assumes a competent administrator setting up the firewall, and your code is secure.
Forcing requests to utilize web services is an easier security model. Singular port monitoring is required and ddos, proper request structure, overflows and the like are handled by the web server, thus abstracted from your application layer and upgradable with less affect on your development. Also its assumed you are using a professional level web server (Apache, Iplanet, NES, or even IIS), meaning a greater user base resulting in problems getting found quicker and fixed faster.
$sig=$1 if($brain =~
I totally agree with the idea that separate services receive separate ports. This makes a lot of sense for security, in that you can track excatly what SOAP requests are being made to your servers and allows you to shut them off if necessary. Going over Port 80 makes it virtually impossible for a company to disable a SOAP service from the firewall without expensive packet inspection at the firewall. The drawback that I can see with not going over port 80 is trying to get the Networking group to punch a hole in the firewall for that port. A separate port also makes things more secure in that if you want to use SOAP internally to your network, you don't allow other people to easily send SOAP requests from the external network. We use CORBA at my company and we don't open the ports to the open internet, but we do keep them open on internal firewalls. If hackers knew that we had CORBA servers, they could inspect what services we had and possibly do malicious harm.
Separate but equal is what I say.
IMO you should run separate functions on separate ports. I don't think this increases or decreases security much, but it greatly improves scalability.
I could, for instance, run my setup on a single box; and then, when traffic went up and the service got popular, replace the box with a Linux firewall to an intranet. The functions could then be divided among several machines on that intranet, and having the firewall box route different ports to their dedicated machines would be a trivial task.
Hell, you could even have redundant machines for critical operations, and if a failure occurred you need only change the routing on the firewall box to get things back up.
This isn't a perfect analogy, but think of it like a building, where port 80 is the front door that comes into the foyer. The windows are miscellaneous ports, and the loading dock is some port you use for something else (maybe 22).
Let's say you have a security system hooked up to the front door, the windows, loading dock doors etc. Normally pretty much anyone is allowed to walk through the front door. You do hope nobody manages to climb in through a window, and you have strictly controlled access via the loading dock.
Now if your reception is poorly designed your only hope is that nobody who walks through the front door hacks off the head of your receptionist and proceeds to go walkabout through the building screwing with things. If your reception is well designed this will be hard to do.
You could even have it so that there's some hazard to those right there in reception but breaking out of reception is as hard as breaking in any other way. But you don't just assume it's secure because it's nicely decorated or (in this case) because so many people walk through receptions it *must* be secure.
It's just a security model. If you alter the constraints and facilities of the environment, then you've also changed the range of threats to that environment. And you tailor the prophylactic security, intrusion detection and response to the potential threats and damage of compromise.
Overall, if you want to have any security, you have to think about security. However the hell you set up your systems.
I am a mean old network admin for a software consultancy company. I can therefore understand mean old network admins.
The problem with big companies who give us big bucks to develop web apps is that the firewall/security teams are totally unresponsive to requests from development teams. A lot of firewall teams act as if nothing is ever up for discussion, and 80 and 443 are all that will ever be. System security would be a lot stronger if the security teams worked along with development teams, but instead a ton of security teams have a fortress mentality, for both system security, and their own interactions - locking themselves away from contact. As a result, everything and anything will eventually be pushed thru 80 and 443.
ostiguy
So, you're saying the security 'problem' has more
to do with the people-ware than the software.
Security people win if absolutely nothing happens.
Greater traffic == greater tendency for things to go awry.
Management, if it can be awakened, needs to step
in and restore balance between security and operational concerns.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I don't know about you, but this thing seems much more like-- Firewall Enhancement Protocol. The writers of this rfc seem to think that this is the best thing for the internet since OSPF....
Seriously-- allowing ANY sort of RPC through a firewall has some serious risks.
LedgerSMB: Open source Accounting/ERP
As long as you rely on packet filtering only, then anybody that meets the filter criteria can sneak whatever they want through the firewall on an open port.
The answer would be to build a stateful inspection engine for soap-over-insertprotocolhere, and then use that to verify the legitimacy of teh soap messages. A daunting task, since a firewall vendor is going to have trouble validating code that you are writing!
I wonder if anyone is working on this?
Steven Deering from the IETF had an interesting point about running a bunch of services on top top port 80. If you run a bunch of services on top of port 80, all you done is build a protocol stack on top of things running on port 80 and you've turned TCP into a layer 2 protocol. You haven't solved anything, and in fact, you've moved your problem up a level. This is ridiculous. We need to get back to running separate services on separate ports just as the Internet was designed to do.
So you are willing to demolish the TCP/IP protocol to spite a few paranoid admins.
If you are developing an application that Company X needs to use and it has to communicate through the firewall, a simple phone call to PA's manager would solve the problem. But the real reason you want to run SOAP on port 80 is because you don't have a legitimate reason for your application to be running inside the corporate firewall. By legitimate, I mean in the minds of management. No, a "harmless" "e-commerce" "web-app" for music/pr0n/gambling/shopping/whatever is not likely to be considered a legitimate reason.
Any admin would much rather have a program using port 12345, because then, if there is an exploit or malevolent user, it can be blocked at the packet level, instead of putting together every response and parsing the entire message using an infinite symbol list and AI that can detect the potential threat in any file sent through the only port on the only address on the only host in the network, if you can call it that anymore.
To date, there have been a large number of tools dedicated to the creation and deployment of web services, but relatively little thought has been given to relationship management between services (a subset of which is security). Only a handful of companies (e.g., the deftly-named Grand Central and Flamenco) have started to broach this issue.
I think we can expect to see a large amount of activity in the area of what it takes to connect web services in the real world (i.e., with sensitive data, in business-critical operations, etc.) in the near future. One certainly would not one's web services to be abused/cracked as easily as Microsoft's Passport "technology". It will be interesting to see how this new market evolves.
moto411.com
Don't forget that there are a lot of customers out there that can only contact sites on port 80 and 443. I have run into this time and again. You want to use a port other than 80 for admin or security reason, only to find out that your customers security practices don't allow communication to other ports.
This is true for both consumers and business customers.
So while you might want to run a service or application on another port, you might be locked into port 80.
Just something to keep in mind.
Beside, you shouldn't rely on the obscure ports for you security. You should build security into your application from the start. And you should NEVER trust any data that comes from "outside" your applications.
Cheers!
I would say that drilling open a bunch of ports on a firewall is probably safer than opening port 80 and nothing else and running all services through this port. Why do you suppose we have ports in the first place? If everything is supposed to run on just one port, than we should have just an IP address and no ports at all! But we do have ports, 64K of them.
In my opinion, every "server" program running on a computer should have its own dedicated ports which it listens on and performs operations through. For secure operation, you decide which services you need and enable only those services. Since all ports not used by these services are, well, not used, then you should block those ports in your firewall.
Want more security? Most non-computer people simply don't understand the concept of good computer maintainence. I keep telling people that just like any machine, computers need to be well maintained or their operation degrades over time. (And that means that security vulnerabilities become more likely as time goes by without proper maintainence.) This includes software and hardware maintainence. Once you have a well functional system working, you can search for big security vulnerabilities, like unnecessary programs or whatever. Once those are gone, you look for smaller things, like software configuration that might allow an intruder to get increased priveledges. Once those are gone, you can go deeper, by getting some h4x0r programs and torture testing your system (being careful not to mess up other peoples' systems in the process). Once you can't get into your own system, you can go deeper yet by examining and auditing the source code of programs you're running (if the source is available to you). I'm sure there are about 30 other steps in between these, but these four are the big tick-marks I can think of right now. Oh well.
Same goes for third-party web-based applications and services. It is VERY difficult to convince an IT group to open new ports - even if they are for established, standardized protocols.
Running on ports other than 80 is frequently a deal-breaker when trying to sell network applications into highly security-conscious environments. Most network admins equate more open ports with less security whether it is justified or not. HTTP is something they know and understand and already have set their network up to suppor - SOAP just makes sense.
Every large organization I've worked for is like that. They *will not* open new ports, but most of them pay no attention to what's going on on 80, 25 and the few other ports they do allow.
Its hardly surprising: they've all been sold on the all they need is a firewall. Then when they discover they need a policy for that firewall and for handling requests from their staff, they all choose to do "whatever everyone else does". This means HTTP, SMTP and POP bascially. (I'll refrain from commenting on how "secure" those three are.)
I was once told (at a previous job) I couldn't have CDDB because it was MP3-ish and might be used by music pirates. (In case you don't know, its a service for looking up the titles of songs, not getting the music itself. I explained this to the guy. He said "I know" but its still not happening.)
Actually the other thing that goes on is people outsource their firewall management. Every time you call you wait a week to get the person who knows their account, then they charge $$$ per hour to make a change. I think we found the real cause of my "no-CDDB" problem.
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
I think that is this article's most insightful comment so far. cf also the comment above where Bruce Schneier points this out.
Your right to not believe: Americans United for Separation of Church and
... for the SOAP protocol is that Microsoft's ActiveX services use a portmapper to get dynamic port numbers for their services. Needless to say, this is absolute hell to try to run through a firewall with anything resembling security.
Hence SOAP. You piggyback your ActiveX control onto another service (HTTP) that uses a single port. Smart admins will use something other than port 80; we know how many of *those* there are.
There is also the problem that firewall admins tend to take their job seriously -- they know that if anything nasty gets into the network, they'll get blamed for it. They tend to be *very* conservitave. Web admins don't -- most of them think that the worst that can happen if they get hacked is that they'll get pitchers of nekkid wimmen on the corporate homepage. They don't care. *Much* easier to deal with web admins than firewall admins. Lotsa places will even let you have your own web server if you promise to be nice.
As to what it can lead to, check out RFC 3093, Firewall Enhancement Protocol (FEP)
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
A firewall is the wrong approach anyway. It presumes that you can declare a sure perimeter behind which things can be "trusted."
There are so many ways around most firewalls (modems, wireless networks, unscrupulous visitors, virii on removable media and whotnot) that the firewall is really just the "front door."
End-to-end security -- defense in depth -- is the only way to be sure. Each machine has to be "strong enough" -- just like most office desks and doors are equipped with locks, though most of us don't use 'em.
Clearly we live in a world where most desktops are _completely_ insecure, so firewalls aren't completely worthless. But perhaps SOAP and the like will have some benefit through clueing in some of the clueless that there's more to security than throwing up a firewall.
Fact is that running SOAP over port 80 or not doesn't make much difference. Someone once said that IT secuirty is 20% technology and 80% policy and practice. These numbers are debatable, but I agree with the premise.
The problem is that certain things have to be open on a networked computer in order to benefit from the networking in the first place. You need layered security. You can't just secure your physical, network and transport layers and expect everything to be okay. You need to know what's going on all the way up to the application layer.
You need to use DMZs, staggered firewalls, SSL, SSH, applications that force you to login, appropriate file/directory/service security permissions. You need to know at any time what software your boxes are running, and make an effort to understand how that software works and what issues it presents. You need to patch commercial software, read the bug lists and do penetration testing.
There's obviously more that can be added to this list, but the point is that security is process not a technical specification, a device...or a choice of port.
Most organizations don't invest enough in this process because those controlling expenditure tend not to understand the importance. Also, security is one of those things you only notice when it doesn't work, so it is assumed you are doing it, and you'll never shine for doing a great job at it.
I think it will take a much more hostile Internet security environment to wake people up to the need to invest in the most critical security capital of all: talented, educated and dedicated human beings.
Yes, I, a single netadmin, am well on my way to destroying TCP/IP.
.net that is vulnerable, and all hell will break loose as http becomes the big threat (as seen on the front of Infoweek/world/land, etc). A big market will result as companies throw proxies in front of their webservers , and in front of their end users internally to protect against this self generated menace.
SOAP is being pushed as an alternative to EDI, Corba, etc, etc (this isn't my area, remember, I am the netadmin trying to destroy tcp/ip). This is because firewall/security teams are not interested in working with (their company's) vendors to establish IPSec tunnels, or SSL tunnels for various apps. Instead of quicker binary transfer within a ssl or ipsec tunnel, stuff will be kludged into https, lest the firewall team's sensibilities be offended.
There will be a huge market for near (as near as one can get) wirespeed http proxies soon as a result. Pretty soon some one will build some hack with some beta of
ostiguy
OTOH, in order for everyone inside the firewall to use soap application servers on the outside, port 80 traffic has to be allowed in both directions for all machines. Any PC could have a trojaned app installed and the firewall can do nothing about it. Likely as not, those users are less security concious than the admin of a publicly available web server.
It's not about the connection method, it's the content that traverses the corporate boundary that is the issue.
If the content shouldn't be going over the boundary, then it doesn't matter how you achieved it - you're still in the wrong. You could do it in CORBA, you could do it in simple HTTP GET and POSTs, it doesn't matter.
As a developer, I can make SOAP invisible to all firewall administrators using HTTPS or abusing their firewall's limitations (most firewalls are incredibly stupid - they don't and can't parse even basic protocols like HTTP, thus let anything that goes out on port X out if port X is allowed outbound.
As a person responsible for security, your use of any services not explicitly allowed is probably against security policy. But security policy is there to enable business, not inhibit it. This is the single biggest failing of most security people: they lose sight of why they are there!.
If it takes too long to get a content-flow approved, then that is a failing of the content-flow negotiation process, and it's not about technology at all.
Andrew van der Stock