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
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
I wonder if anyone is working on this?
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
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.
... 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.
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
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