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.
Whatever you do you can virtually guarantee that
M$ will come out with blurb about "rich" programmer
experiences or "Meeting todays challenges" or some
other marketdroid BS and will promptly throw some
"features" into SOAP that no one really needs
that will be a virus writers dream. No I don't
know what these might be but I'm just going by
their previous track record on security.
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
you don't have to run SOAP over TCP-80...the protocol is based on HTTP, that isn't to say that it is HTTTP. You should be able to work out with other sites what port numbers you'll be using.
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.
It's kind of a false security feeling, since you could just encapsulate whatever request you want within HTTP -- for example, one system I know of does exactly that (name supplied upon request) by encapsulating all the objects it passes in XML inside of the HTTP request.
I am the Lorvax, I speak for the machines.
Having software that talks on a specific port is not too hard to deal with -- port 80, 8080, 1234123, whatever...
I've worked with stuff that required a range of ports (like thousands of them), which is what makes your IP people freak. Far more common than one would think.
+++ UGUCAUCGUAUUUCU
You don't have to use port 80 for SOAP requests. You can use other protocols, eg. FTP. You can make your own protocol if you like, and add whatever security you need.
Hi,
SOAP is transport independant. That's one of its (theoretical) virtues. You can implement SOAP over SMTP, HTTP, whatever.
Practically, it does seem fair to say that HTTP is what an awful lot of SOAP tools are going to be expecting, and given that SOAP is still quite bleeding edge, I wouldn't want to try using another transport protocol unless I could afford time and skill to do a lot of fixing up.
However, HTTP doesn't have to run on port 80. Furthermore, most SOAP implementations will be (well, claim to be) happy on HTTPS too, so that's an easy way to do encryption.
As for the 'web page vs functional' thing, well that's not so simple. A request for a page produced by a CGI script is a functional request coming from strangers over the web. SOAP need not be different.
At the moment, if I want to make an XML version of my content available to folks, I might tell them to use HTTP GET with a URL that invokes a CGI program that returns some XML.
In the future, I might want to make the same XML available via the getXML method my Website class, and then SOAP enable my Website class.
The differences isn't that great.
-----
My experience has been that those that configure firewalls are more likely to introduce security issues that more they are required to configure, so establishing port 80 as the common gateway through which this type of traffic flows reduces that opportunity for this type of mistake. It does put the burdon on the developer to ensure that the code is functionally secure, but I'd rather have that burdon be on myself than the firewall admins.
Microsoft was blamed for not using it's own port for DCOM, now, that they are using SOAP, your complaining.
:)
Go figure
Of course, with the recent spate of attacks on Microsoft IIS and its penchance for being cracked, I would say that for now it would be a great security risk.
I haven't heard a lot of new vulnerabilities in Apache, though
OK, the person who posted this nonsense 15 times in a row is officially a knob. WRT the question posed, I agree completely, having specific ports that perform functional requests are far superior. Just look at the problems that MS had recently with providing print services over HTTP. Knowing precisely what functionality is provided via a specific port is the only way to effectively filter and block potentially malicious traffic. Nowadays it seems people want to be able to start and stop their dishwasher via HTTP/XML, it's lunacy IMHO, but then I'm very old-school. Still, I've never been cracked or infected so maybe I'm doing something right.
----
Slán leat agus go n'eirí an bóthar leat
We are currently using SOAP-like mechanisms, and there are a number of security precautions that can be implemented that in my opinion balance the threat of accepting such messages.
Possibly the most secure precaution is using SSL for the requests. You can require a client certificate to access the service and your site certificate will reassure your partners that they have connected to the correct server. In addition, you can build in custom username/password fields into the app, or have each message PGP signed.
Another option is to move your application to a different IP address and use the firewall to restrict access to it. This method is good if your partners are known ahead of time.
Hope this helps.
It shouldn't matter what ports you open up on your firewall - what you are interested in is what will be receiving these requests.
We've all seen that access to port 80 can cause problems with incorectly configured IIS machines anyway.
Basically as a person responsible for security and firewall configuration you don't just enable access on a port just because someone asks for it - you check out what is going to be used and make a decision AND warnings to those involved.
Matt Thompson - Actuality - Insert product here.
You can use any port you choose. A bit "security through obscurity" this one, but no harm there>
You don't really need a full web server. All you're going to get is an HTTP request with a SOAP envelope thingy inside. If it doesn't match the WSDL (or whatever) schema thingy you've published, then just ignore it. You only need give the information to people who are going to be legitimately calling your service. Of course you're still vulnerable to normal DoS, but then isn't everyone.
It is quite possible to digitally sign SOAP requests. Just ignore anything not signed/not signed by a recognized customer.
If you are only exepcting SOAP requests from a few other servers, then consider client-side SSL. Since only a few servers will be calling you, then you'll only need a few client certs.
... well ... you get what you ask for. Signatures on SOAP requests aren't (easily) supported by everything yet - but then SOAP implementations differ (eg MS SOAP has no types, IBM SOAP does). This isn't a major issue as it's pretty easy to roll your own request - it's only XML after all.
Like everything, it's as secure as you make it. If you expose "FuckMyOS" as a SOAP method and publish it through UDDI or something then
PS I have no opinion on Vladinator's website.
This sig made only from recycled ASCII
The real reason HTTP and port 80 is seen as neat is that it is probably already open, so you don't have to deal with that mean old network admin who just wants to spoil your fun.
You don't have to answer difficult questions about how your service is secured, how it might be exploited to reach other resources within the firewall, etc. You ride the coattails of the "harmless" web server traffic.
"Rub her feet." -- L.L.
The reason people use them over port 80 is to get around the firewall. The whole point of blocking the other ports is to prevent people from calling functions over http!
Say your software automatically generates service stubs for you, a clueless developer may deploy the whole thing as a service without giving it a second thought!
IIOP supports mature encription/authentication and can be proxied through a firewall (while losing performance/functionality) when you add all of the features of security to SOAP it ends up more complex than Corba.
SOAP is good for very particular small markets (i.e. sending SMS, Checking weather/stocks etc...) its useless for real world enterprise communications.
The "do everything with XML" motto is just plain stupid, while XML is excellent for many things its performance/security will be considerably lower than IIOP. Plus you will lose the readability and simplicity of the XML standard. Sadly this fad has gone too far, it will go the way of "push technology" in no time.
People fear what they do not understand.
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.
You could run IIOP through your firewall, no problem. I've used CORBA implementations that require the client to talk to a broker daemon on a known port.
But if you start using transient IORs, then you have a problem. This occurs when the service broker (on your known port) starts up a service on another port, and then gives you back that IOR. You now have to access the CORBA service through that second, dynamically allocated port number.
This port will be in a known range, but that range could be in the hundreds/thousands. This is where your firewall gets in the way. Consequently the easiest thing to do is use persistent IORs.
The security advantage of SOAP isn't that it goes over the same port as HTTP but that it's capable of using the same security features as HTTP, such as SSL (which is port 443 anyway.)
My real concern about tunneling everything through a single port or protocol is that it makes network auditing much more difficult. If there is a security problem, or just a general network problem, the fact that everything looks like HTTP doesn't help track down the problem.
However, there is a flip side to this. I have been in the position of trying to convince large companies to change their firewall configurations. It would be easier to make lead in to gold than to get a large company to allow communications through a new port on their firewall.
This basically means that putting everything through port 80 serves two purposes. It give people the perception of security, and it lets the project actually happen. It is the case that not having to change your network configuration is a powerful marketing tool, but it doesn't make anything more secure. All of these issues are addressed in just about every networking book out there.
Portals are nice, from a security perspective. You can run all your applications behind a front-end webserver, only accessible via port 80. Some nice firewalls, like Checkpoint, have an HTTP security server which does bounds checking and similar to HTTP requests. Couple this with a good, reliable webserver (apache or netscape), and any applications running behind the portal are less susceptable to an overflow attack since the only machine that can access these applications is the webserver, which means an attacker would have to compromise the web server first.
Also by doing portals in this way, you can force users to authenticate an HTTPS session before accessing the portal site, and the services behind the portal. Of course, how you do authentication can be anything from login/pass to securid or X.509 certificates. Once the users authenticate themselves, then accessing the applications "through port 80" is more secure.
However, setting up multiple DMZs is the way to go. In my example above, where the webserver accesses the services behind the portal, you'd set up those applications in their own DMZ (seperate from the webserver DMZ). Access to this DMZ wouldn't be allowed directly from the outside (restricted by FW), which again would require a compromise of the web server. The other advantage is, if an attacker were to compromise the application *somehow* without a webserver compromise, then this would restrict them to only boxes in this second DMZ and therefore would not compromise the webserver ALSO. Setting up a DMZ correctly means a lot. You can set up a DMZ to accept incoming connections but not to allow anything outbound (except for state traffic). This would prevent an attacker, who has compromised services in the DMZ, from attacking anything else from that point into the rest of your network.
accessing a web service is no different to a remote human accessing a dynamic web page.
Sure, you need to consider the security aspects of your borders, but you must concentrate your security efforts on what goes on inside.
I think.
This is definatly a valid question, and I think, personally, the answer would be yes, the entire notion of web services have some serious security reprocusions. In the past, web traffic was web traffic. Now that HTTP is being used to essentially tunnel an RPC call into your servers, it means that that same servers that have, time after time, been compromised, are now the same servers providing vital access to critical data systems.
Now, this does NOT mean that web services are bad, simply that web services have to be written with the understanding that they ARE more open then normal simple RPC calls. Greater use of this design means greater risk in general, since now access to functions that may be suseptable to buffer overflows, denial or service attacks, etc, are basically sitting out there in the open. I've never heard of a denial of service attack targeted at an RPC mechanism, but with little or NO modification, this type of attack could be deployed 'out of the box'.
New security measures will have to be created in order to thwart this greater risk that will now be exposed.
-- I'm the root of all that's evil, but you can call me cookie..
This kind of setup will only be as secure as:
1. The web server software(glares at IIS)
2. The programming of the individual web service itself.
Apache has been checked over and over for security problems, its much more likely to be secure than some corba/rmi/etc server that much fewer people use.
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.
Port 80 is not necessarily an open door. While it's true that there will be a multitude of SOAP calls running through port 80, the idea is to have the applications control the security. Your application that you develop should have enough control to accept only those calls that you want to go through and throw out anything that is invalid.
Control your infrastructure and control your applications and you will be much better off.
Hmmm...
It's a new trend, run everything on port 80 so your network admin has less to worry about, but that whole concept is a steaming pile of shit.
So true.
It's taken many years to build up the many layers of network security we have. One of the main reason SOAP is so easy to use is that it drills a hole right through all those layers. In other words, SOAP is easy because it encourages you to ignore everything that makes remote applications hard -- like security.
As an example of just how wacky the everything-on-port-80 idea is, and how dangerous, consider this idea I heard from Bruce Schneier: implement IP over SOAP: have a SOAP service listening at two endpoints for IP packets, and forward those packets over SOAP to the other endpoint. Then make one of those endpoints the default gateway for packets into the otherwise-secure network at the other end....
Just ponder that.
I am an admin, and I would just love it if everything came over port 80...make my job tending the firewalls much easier :)
'Course, I'd have to be sure to do all the security updates so I could blame problems on the software vendor--but we already have to do that with Microsoft anyway!
I saw a RFP for IP over HTTP, it would solve all firewall problems forever, for everything. I think it came out the begining of April a couple years ago ...
http://www.isi.edu/in-notes/rfc3093.txt
Different ports for different services? Different directories for different files? Wouldn't it be easier to look for a file in one directory? Yes, putting all in one directory/shoving all services through one port, would be easier - much less to keep track of. However, I like to know that my conf files are in /etc, system binaries in /usr/sbin, and so forth. And I like to know what services are accessing what port. Port 21? Oh, someone's hitting ftp. Port 80? Http. Port 23? Telnet. Yes, services can be run on any port. And one can look at the traffic to verify that's really what's passing through. But starting a trend of using one port for more than one purpose is non-sense - perhaps just making it easier for less knowlegable people to 'administer' a network. Maybe easier, but not better, and certainly not more secure.
After posting my last reply, I thought of something that is a GOOD thing regarding SOAP over HTTP that deserves mentioning. By directing and detecting all web traffic, you now have a transactional log off all RPC calls being made into your system. So while yes, you are possibly exposing things, you have a much better logging mechanism in a central location then you would have by having any given application tunneling thru its own socket, making calls to its hearts content. All calls cal now be logged, filter, redirected, etc..
Now of course, this does apply only to SOAP over HTTP, and possibly not SMTP/POP3, Raw socket, MSMQ, etc..etc..
-- I'm the root of all that's evil, but you can call me cookie..
Having worked on a large SOAP app that utilises Perl/SOAP/mod_perl and Delphi/XMetal, I can honestly say that it's no big deal having the SOAP requests served through the same machine, running on the same port.
At the end of the day, it's not the port that makes transfers secure, it's encryption.
SOAP is easily tunnelled over SSL, and obviously you can take full advantage of Apache's (mod_ssl) SSL support, with client certificates etc.
Security is about keeping information secure, not how many holes you've got in your firewall.
Bruce Schneier covered this more than a year ago in the 15.06.2000 cryptogram. Anyone who has read Schneier's newsletter long enough begins to realize that he is the Cassandra of the Internet...
Years ago we tried to set up client Internet access via odd port numbers. Resistance every step of the way from client networking people, client management, and even our own ISP (who controlled our firewall, in those days). I can't even imagine trying it now that web based everything is even more entrenched.
SOAP has merely subscribed to the common perception - the Internet is the WWW. I think it's probably the only way it would have caught on as much as it has.
Full disclosure: our web apps create "bitty windows" to exchange data. I apologize to anyone who feels dirty after hearing that.
Let's not stir that bag of worms...
In the future, I might want to make the same XML available via the getXML method my Website class, and then SOAP enable my Website class.
Right. Why stop at serving bulky data, when you can wrap the bulky data in more bulky data.
I've been looking at XML-RPC a bit lately, and apart from the security issues (which for me would be solved by having some sort of broker/proxy outside the firewall and SSL), the sheer inefficiency of the thing bothers me a lot.
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
SOAP has actually gone well out of its way to allow server admins to filter requests. It makes use of the "Mandatory Header" aspects of the HTTP protocol such that every soap request must come with an HTTP header specifying which function is being called. Since it's in the header, a server doesn't need to know SOAP to filter, it justs needs to know HTTP, and the server can simply turn away anything that doesn't provide such a header.
I agree there is still a major lack of support for this type of filtering, and even the standard leaves something to be desired in this respect, but the SOAP designers definitely did think that this was a big enough problem to provide facilities for future closing of these holes.
It's a bit of a pain to administer, but it definitely *can* be done.
You're talking about security.
My experience has been that those that configure firewalls are more likely to introduce security issues
Then the firewall admin is incompetant.
A real firewall admin will understand the protocols involved, and will have a hell of a lot better understanding of security issues than a programmer.
Saying you'd trust a developer to make better security decisions than a firewall admin is like saying you think a secretary would be better at fighting crime than a police officer.
from my experience using .NET, each service is a virtual directory within an http server.
on a virtual directory you can implement ACL's based not only on IP origin, but windows users/active directory/whatever.
so what's the problem? just because now its not in your gauntlet ruleset doesn't make it any less secure or auditable.
This is a non-issue. You can run any protocol over any port. If you thwart your own firewalls by running all services through the same port that's your own damn fault (or your clients' fault).
It's 10 PM. Do you know if you're un-American?
SOAP is essentially a mechanism for sending functional requests over a port specified for web page requests this would make me nervous.
No, it's not insecure. It's just that you're an idiot. Go fuck yourself./P.
> 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.
An open port is as secure as the service behind it accepting connections. If your implementation of CORBA/RMI is tight and there aren't any vulnerabilities, it's equally secure to going through a web server.
I think one reason people like using port 80 + app/web server, in addition to the fact that it's probably open on the client's end, is the fact that there's a LOT of security work being done on Apache. It's a nice feeling to run Apache as nobody, have it hit your little app, and not worry as much because it's relatively tried n' tested.
I have heard it said that saying "SOAP is a firewall friendly protocol!" is like saying "They're armed with head-friendly bullets!"
I'd be wary of *any* protocol capable of passing non-web traffic over open ports through a firewall...
"Of course I'm wrong... That's how I get to 'right'." - Gil Grissom
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
We're of the opinion, that if you want total data security, you'd be wise to keep IT (the data) off a 'pubic' web server. That could/should/will? change, but NOT by some perpetuation of total BS, lack of disclosure to save face, crud.
Check out our web address giveaway. includes a year's free hosting. In case you need somewhere to hang your hack (see also: VA Larry lays cullame to EVERYBODY's work), whilst the GNU millennium kicks in. We have some other options for any who are interested.
A packet-filtering firewall looks at headers -- source and destination address, port, flags, etc.
This is cheap, quick, and failure-prone (since the mapping of headers to applications is mostly by mutual consensus, and an attacker, or a developer with a deadline looking to bypass the foot-dragging firewall admin, can be assumed to not be "playing fair"). You have no little or no control over packet data/payload. This translates, at a higher layer, to no control over what service runs on a particular TCP port.
OTOH, a proxy firewall "knows" something about your service protocol. It inspects packet payloads and makes decisions (drop, pass, rewrite) based on the content. This is expensive, slow, and failure-prone (hey, the proxy has to correctly parse the service protocol AND be configured correctly!).
Net result -- if you use a packet-filtering firewall and make the assumption that "port 80 means HTTP", sooner or later you're going to be wrong. You need to move up the protocol stack and make filtering decisions based on payload (e.g. is this request, whether HTTP or SOAP, one that I wish to act on?). That's the job of the proxy firewall (or your web/app server -- the line can get blurry).
Shhhhhhh!
The market depends on people eschewing simple
solutions using existing resources.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
As always, strong authentication (along with a fine appreciation of the remaining risks) is the obligatory path, whatever the service is. The next step is clever partitioning : if your front end server gets compromised, try to reduce the possibilities of spreading through your network, using physical separation, filtering devices, DMZs ... And of course, take care of your server software and audit the app's code. Evnetually, you may add an app level filtering proxy, but I don't know if there is such a beast for SOAP requests.
It is true however that multiplexing every app protocol on the planet through a single HTTP canal may make HTTP look like NetBios (damn "three ports fit all" paradigm). Handle with care !
Do you agree ?
gdon
IIOP isn't bidirectional across all firewalls if NAT is employed. Specifically with Checkpoint firewalls, you basically can only go one way (due to embedded IP addrs and such).
Poof.
Hi,
there already exists at least one secure SOAP implementation (using HTTPS) I know about and you may download it free for development purposes.
The best of this implementation is the NetBeans (Forte) module for developers. IMHO those guys have made a really good work.
Firewall/Security administrators are concerned with _what_ data goes in and out of the network and not _how many_ holes have to be put in a firewall. If all the companies secrets are being sent out of port 80 then the network is not secure and the firewall is useless. A good firewall administrator can manage a firewall with one hole or many holes and understands what is going in and out of the network. This not to say that web services is totally insecure, it is to say that security is not something that stops at the firewall, it goes down to all data in, out and on the network and included the content of that data.
Michael Marschall
- Professional XML Web Services
expands on this topic quite a bit. Both are available at www.markrichman.comApp securing and propagation of security context/credential is the key, microsoft "passport" is aimed at that, by adding proprietary protocols to propagate credentials and implement security in a way that will be MS specific.
For more interoperability there, check J2EE that does specify security propagation at the wire leve with RMI/IIOP. And I am going to plug a project I work on (had to ;-) for the J2EE reference implementation with JAAS so that you can plug in your legacy stuff in there as well. Then we DO offer a WSDL/UDDI port to web-services to communicate with EJB so you leverage that model of security and VOILA, secured webservices.
HTTP has supported extremely simple transactions/services support for years through CGI. Essentially your entire question is moot.
Yes, another port would be simpler to secure. Without that, firewall administrators will simply go higher in the stack and look at layer 7. In other words, the firewall will have to pick out the URL and apply rules to that. Of course, this also implies the firewall is tracking connections, etc. It can no longer be just a dumb packet filter, but no serious firewall is.
In the end, the lack of a port as a service differentiator isn't a big deal. What is important is that you have something wich differentiates the service. A URL can do that, it just costs a little more CPU.
As a sysadmin, I prefer to have each service running on a separate port and if it is a soap based service, just add the port number to the request.
This means that I can control what is being accessed by whom at the firewall, machine and application level.
The big problem with this is that many corporate firewalls prevent outgoing connections to non-standard ports. So if I want my developers apps to be open to the world, I often have to go against my first choice and run the services on port 80.
Just my 2p
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?
Having done sys admin work, it's much easier and less work to go through port 80. That's one less port to keep track of and allows me to build expertise on securing HTTP. Learning to secure a lot of different ports isn't hard though time consuming. Teaching it to new staff and making sure they understand all of it isn't. That's one reason for the adoption of SOAP and other XML/HTTP protocols.
From a developer perspective, would you rather build in IPSec to your IIOP, CORBA application, or setup HTTPS and go through a well tested system? Rolling your own security on top of IIOP and CORBA isn't a trivial task. You could build your own encryption wrapper for IIOP or CORBA, but you would have to handle all the key storage, key management, encryp/decrypt, secure sessions, and authentication to create robust, reliable security.
If your application really needs greater than 128bit SSL, then going through a web server on port 80 doesn't do anything 4 U. To my knowledge RMI can make HTTP connections via java.rmi.server.RMISocketFactory. There are existing Java libs to handle both SSL and key management, so going with port 80 is really a administration choice.
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.
;)
Hmmm.... Not only can XLM-RPC and SOAP also run on port 80, but that HTTP traffic can be mighty harmfull... Thinking of Nimda, Code Red, and CRII.... The problem is that any "protocol" is fundamentally used to exchange instructions and these instructions can be used for all sorts of stuff.... So filter based on services, but please keep the services in your DMZ
Basically, this means--
filter based on IP address and port number. only allow those things to pass through the firewall that you absolutely need (possible exception of outgoing TCP connections, at your discression) and keep it all inventoried.
LedgerSMB: Open source Accounting/ERP
Two cases:
doSomethingRemote() # RPC that may take 100 ms and may throw an exception because of network failures
and
doSomethingRemote2() # local call that formats information into a message to send to a socket, then waits for the response, possibly taking 100 ms and possibly throwing an exception because of network failures
What is the primary difference? The amount of programmer effort required to implement #2.
If you're going to use remote functionality, you're going to pay the price whether you do it in a standardized, automated way, or in a custom, manual way. Yes, you need to be aware of the performance implications, but you need to be aware of the performance implications of _ANY_ function you call - the function may do database accesses, may open files, may consume huge amounts of memory, may sleep for 10 minutes, etc. These concerns are not unique to RPC.
Right. Why stop at serving bulky data, when you can wrap the bulky data in more bulky data.
Why? Ask anyone who writes tools that piggyback off of Ebay if they wish Ebay supplied XML representation of auction data. They will pee themselves, then scream out loud with joy. XML provides a way to exchange data that is human and machine readable. It also responds well to compression, due to redundancy.
If you fall off a building, go real limp, because maybe you'll look like a dummy and people will be like hey, free dummy
Why can't you use HTTPS? I'm not sure what the implementation in VB/VC++ would be like, but doing it in Java is quite easy (go grab the Sun JSSE libs and look at the examples). Just setup the authentication and you are good to go. I built an internal relay inside our network. It listens on port XXXX and then sends the request to port 443 on the remote machine. I wrote the connector in Java but was talking to an MS ASP box. Even though we were not using true SOAP encapsulation it was a cutomized XML RPC type call so it is pretty close. I had to write a relay because the internal request was coming from a C program and the C programmer didn't know how to handle HTTPS authentication/verification. This was for some e-commerce type stuff. The managers here seem to think that is enough.
As a side note, the relay is actually faster than individual, direct connections since in Java it takes a while to generate the KeyStore.
-J
This is very disconcerting to me.
/var/log except for 'messages', then we've got all our logs conveniently in one location.
How many posts have I seen talking about how much easier running multiple services over port 80 would make their firewall administration? WTF???
How many of you out there are real administrators? Running multiple services over a single port does not make anything easier, it makes it more difficult, because you've just eliminated your first line of defense against getting cracked; the port-blocking mechanism.
If these are services that you use on your network, then fine, but there are many people out there that will end up with a default installation on their server that includes a bunch of shit they don't even use or know about.
And another thing... a couple posts mentioned how great this is because now you can log stuff right into your http logs. GREAT! That's the most jacked opinion I've ever heard. Nothing like clogging up a service log with other services' information. Perhaps us linux users should just eliminate everything in
Seriously, though, I'm sure that SOAP is wonderful when used appropriately... It's just that most of you are not fully understanding the issue at hand: bozo here who made the intial post doesn't realize that he doesn't have to do things this way. Since when does any back-end shit he writes have to be done over port 80???
Can we please start seeing some real questions being posted, please?
---- Please flame below this line ----
I asked pretty much the same thing of Microsoft when they first announced .NET (which is closely tied to SOAP) For anyone who's curious, I asked a couple people, so I don't really remember WHO I talked to, but I do know that Scott Gu was one of the people.
Their response?
Developers are tired of being hampered by netadmins, trying to open up unsecure ports just so that DCOM will work. Basically, SOAP is a way to do it where you don't have to open up esoteric and undocumented ports and protocols...
As far as security goes... it's up to the implementors. SOAP does have one advantage over some other forms of RPC, in that it has a few built in forms of authentication and is explicit as opposed to implicit. That means you can't just randomly activate bits of code just because you can log onto a server.
Another advantage of SOAP is that a decent XML coder can write his own parser for the protocol, so you don't have to use the vendor's, and you can customize your parser to only pass safe requests.
Of course, some of the MS people indicated that they felt I should use the MS parser at this point. I haven't seen anything bad with it, but I wouldn't have any qualms about writing my own if the business needs dictated it...
I am disrespectful to dirt! Can you see that I am serious?!
I was contracting at company X a few years ago. I needed to use some piece of software for my project, and the demo site for said software ran on port 8081.
..."
Which was blocked by the company firewall.
So I go ask the admin why it's blocked. I mean, WTF, blocking random _incoming_ ports I can understand, but outgoing ports? When there's already port 80 and 21 wide open? Not to mention DNS[1].
"We don't open it because it's more secure that way", he said. "But it's not more secure!" "YES it is!" "Why?" ".... BECAUSE!"
"Ok but look I could just make an SSH tunnel on port 80 with pppd and I can bypass all that stuff
He replied: "well if you do that, you'll get in a LOT of trouble, and the company is going to sue you! And I warn you because I have logs of everything!"
Now what's really interesting is that I had been running this particular setup (pppd through ssh on port 80) for a couple months already, and nobody noticed.
[1] You think you've secured everything and that no info can get through your highly secure firewall? But have you thought about the DNS?
$ host the.root.password.is.iluvmom.crackersite.net
SOAP was developed specifically so companies (such as Microsoft) can execute arbitrary code through otherwise secure firewalls where all they have to do is get the user to download a simple client program that wraps the commands in an XML format and sends it as an innocent looking HTTP response. It was designed to *solve* the problem of corporate users wanting to run network applications that are verboten or otherwize blocked by their network administrators.
SOAP is designed with security in mind. Security circumvention.
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.
Bruce Schneier had an interesting statement on security and SOAP:
. html#SOAP">CryptoGram Newsletter on 2001-June-15:SOAP</a>
<a href="http://www.counterpane.com/crypto-gram-0006
IIOP is so rife with problems and can so easily crash an ORB server you'd be crazy to let it through the firewall. Show me a single public IIOP address (IOR) and I'll show you a system that is never up.
I work for an ASP, and we basically have to build full web applications that function like Office tools, and believe me, port 80 is a necessity.
.jar files being executed. Some of them just don't want to allow anything but port 80.
We need to fire up a java applet on the client machine that maintains a session with the server. We also need to allow chat.
I can't begin to tell you how many million sof dollars we've lost as a company because of large corporations that refuse to adjust their firewall settings to accomodate web applications.
Some of them don't want
If we're only allowed traffic on port 80, which is the case when dealing with 90% of corporate environments, your choice is either a) get the services running over port 80 or b) give up on maintaining your business.
Opening a CORBA/IIOP port to the Internet is an invitation to say "hack me". There are a million ways in which to bring any ORB to its knees. CORBA only works in a trusted environment. No CORBA vendors can agree on security standards anyway - so most shops don't have any CORBA security, so you might as well avoid CORBA altogether.
He wasn't trolling. I've spent upto 6 months trying to get a port opened, only to be refused. Work for a bung company owned by another big company that says "You will not open a port", and you have 12 levels of management to go through to even ASK
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
LOTS of bugs and security exploits there. Should have used VB running in XP to get bulletproof performance and lightning fast response.
Always remember that less is more. Less web security can lead to more of it because when you look at the absolute picture you can see that the more will eventually be overtaken by the lesser in small amounts. Hence, more cannot be the lesser of the two but less can be greater than the more.
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
If you're using SOAP, make sure you have a validation schema that you run all incoming messages through and drop anything that doesn't pass it. If you're running anything else, I dunno. Re-examine your code and make sure you don't have any obvious buffer overflows waiting to happen.
As with most of the Ask Slashdot questions, I'll beg the question: was a Google search and a little common sense really so scary that you needed the hand-holding and warm fuzzies that a few nodding heads who may not have any idea what you're talking about will provide you?
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
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!
one of the biggest disadvantage of one service one port concept is that it exposes internal resources to outside world. ports are finite resources and part of OS. If you have one port one service, you would run out of services soon. so there needs to be a mechanism to share ports. the most open ports nowadays is 80. so people are devising a way to share this port for multiple things. there is nothing wrong with this. SOAP is a way to share http protocol for things other than web page download. What is wrong with that?
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.
Yes, SSL is a *huge* hole in the idea that a firewall can statefully inspect everything going through and place strong limits on what can be send. To allow SSL, you have to allow arbitrary binary data on port 443.
;-)
The only way to stop it is to block SSL / HTTPS. Ah, that's a fantastic way to increase security
As other people have pointed out, CGI scripts etc are probably more inherently secure compared to SOAP. With SOAP, one can look at a particular HTTP header to find out which service or method is being called and weather user has permissions to access it (one such opens source Apache module that does this is available here. This will alow you to selectively open SOAP services on per-user (or per-group) basis where users are authenticated by specifying a password or XML Signature.
From adminstration point of view, it is definitly far more convinient to watch just one port even when you are not a lazy administrator and watch, log and manually scan each suspicious packet going inside your network. and that is why SOAP is plus-plus. I do not see how just using IIOP instead of HTTP increases the security.
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 wrote "Web RPCs Considered Harmful" that briefly addresses the security issue.
Summary (and using more recent terminology): Web services that expose more new and unique code are more likely to expose bugs. RPCs, SOAP, and CGIs all encourage developers to write more exposed code by making that style easier to do.
One better alternative is to be more data-driven (some would say "functional", as in "functional programming"), so that you only expose data (via a standard server which would typically be more mature, heavily reviewed code).
Alas, that's an entirely different way of thinking that most people are not used to, since it flies in the face of "normal procedural or OO programming" that happens on the desktop. Some examples, though, are Linda Systems (TupleSpaces), REST (the traditional WWW architecture), and even P2P to a large extent.
Agreed. I've working in the financial industry for many years, and now I'm working for a subsidiary of a subsidiary of a multinational publishing company. I can't even ask to get a DNS entry added, 'cause the people I have to ask don't want the red tape from the people they have to ask, who don't want ...
The most common response I've gotten to trying to open a port (for inbound SSH, restricted by incoming IP) is that "policy is not to open up any ports". At a previous employer, a request to change the policy was refused on the grounds that it would violate the policy whose change is being requested!
And don't forget that delaying and refusing requests from other divisions/departments in a large corporation is a prime tool for a manager to show importance and hold onto his/her "turf"... In times of layoffs, every manager's inner control-freak comes out.
It's really quite impossible to get a reasonable request through the layers of cluelessness that exists between you and the network admin who can make the change, and then only if (s)he can convince the PHBs above of its necessity. Violating the spirit of the rules, but not their letter, is often the only way to get an essential network service in large organizations.
And, yes, if XML-RPC/SOAP gets blocked, then certainly it's going to get base-64 encoded in an HTML "PUT" in order to get it through. Sucks, but that's corporate reality.
Bzzzt - try again. Firewalls are built to protect from threats, internal or external. This RFC is the steaming pile of shit.
I especially like this one: bypassing the IT manager in charge of the Firewall ... no need to waste time involving any managers for approval.
Here's the other thing that drives me crazy about this:
The overhead of all of the layers required to do RPC over HTTP (yes, I know it doesn't have to be HTTP, but that's what we're discussing here) is huge compared to the performance on raw sockets.
Secondly, the protocols in question are brand new. As are all the implementations. They haven't been audited, field tested or generally kicked around enough. Certainly not as much as the 30 year old ones, or even HTTP - and HTTP is very very simple - these are full function calling systems!
Sure, there's probably some benefit in that the modern protocols were designed with security in mind, and the older ones usually didn't consider it, but that won't protect us from design flaws or implementation bugs that there hasn't been time for the community to find.
So all in all I think all we did was bow to ignorance and introduce a lot of redundant overhead which is *less* proven secure than the older stuff.
Its funny, its so obviously the classic tradeoff between security and convenience. It seems people want these services, but they were insecure. So now they're still wanted, but just tunnelled through something to give everyone a *very probably false* sense of security.
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
Joe
Joe Batt Solid Design
I can understand not enabling CDDB under the "Why should I lift a finger so that you can fuck around instead of working" policy that most admins operate under.
A web service running on port 80 is no more or less secure than a CGI or Servlet running there. You can view the url as a commandline interface just as the web-rpc uses the XML interface.. for example? pa ram0=patentPipeline
http://somehost/KickMe?function=giveAwaySecrets
could return an XML document full of company secrets and what not just as easily as a "web service" could.
Clearly its the same idea, just not wrapped in the latest and greatest XML technologies.
Web Services are no big deal security-wise, if you look at things this way.
People, soap is in no way tied to port 80. You can just as easily make soap requests over port 25 via smtp.
Oh dear, soap requests going to a web server!
someone explain to me how this is any more of a risk than a form posting to a cgi program? Both are transmited via http, but you're freaking out because one method of data transfer is called SOAP and the other is CGI? Filter out all M-POST requests. Write secure applications. Dont allow world access to that specific CGI. What the hell are you freaking out about? Think SOAP == Agreed upon cross language standard.
I know, how bout you secure your application? Yeah! Wouldnt that be great! I know you think Having A Firewall will make your dick larger and your network failure proof, but that just isnt the case. For gods sake this is the best 'I do not understand and fear the unknown'. YOu're all a bunch of hyporcrites. IF you got this attitude from your boss about linux you'd all be flaming him. Look at yourselves. Go read the OPEN STANDARD. I can tell by the comments that most of you have no idea what the hell you're talking about.
Why use soap over http? Because then there is only ONE port open and ONE application to audit and secure. If you really understood the protocol this wouldnt be an issue.
Besides, the soap server doesnt have to be world accessible. In fact, why dont you restrict access to the soap server(cgi) in your web server?
Write a soap.cgi and use Soap::Lite, add apache rule to restrict access.
Oh look! You dont have to wait 2 weeks for your change request to filter through the 80 departments of IT! You can get WORK DONE!
Or, you could implement the same functionality with plain old CGI. Except it'd be more work and harder to make work cross-language. I know you idiots like to reinvent the wheel, but this is the most asinine 'the sky is falling' discussion I've seen here to date.
One problem with firewalls (especially packet filters) is that it's hard to know exactly what data is flowing through. You can really tunnel any protocol over any other - you just need to know how to encapsulate and decapsulate it. Distinguishing whether data is regular data or encapsulated data of another type is hard to do. So I suspect that security people are going to have a hard time, unless we can convince the developers that they *need* firewalls and to stop tunneling holes through.
Software sucks. Open Source sucks less.
Or Death of a Sales Engineer. I worked for a place that learned that the hard way -- never try a customer demo on anything that doesn't run over port 80. The nutzoid places even block 8080 and 443 and sometimes even block JAR and CAB files.
Unfortunately our app wasn't that flexible, so they ended up hauling 3 laptops and a minihub out to the customer site.
I will now summarize this entire article into two opposing viewpoints:
I tend to agree with the second argument, but until we have powerful stateful protocol filters for all protocols that could go through port 80 or wherever, there's no real difference between opening 50 separate holes or one big one. Even then, bad stuff can get in and out over https, etc. So SOAP doesn't really make things much worse, it just points out security issues that we've been ignoring all along.
Your right to not believe: Americans United for Separation of Church and
As other people have pointed out, CGI/PHP/JSP scripts servlets etc are almost always more inherently insecure compared to SOAP. With SOAP, one can look at a particular HTTP header to find out which service or method is being called and if user has permissions to access it (one such opens source Apache module that does this is available here. (This module will alow you to selectively open SOAP services on per-user (or per-group) basis where users are authenticated by specifying a password or XML Signature.)
From adminstration point of view, it is definitly far more convinient to keep tab on just one port even when you are not a lazy administrator and watch, log and manually scan each suspicious packet going inside your network. and that is why SOAP is plus-plus. Also, I do not see how just using IIOP instead of HTTP increases security of a service accessed.
... 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.
Mindterm looks interesting, but the GNU httptunnel application (here is another link) mentioned in another post will do roughly the same thing, and you can easily use ssh over httptunnel to tunnel other protocols.
Better yet, unlike Mindbright's applet, httptunnel is free software (GPL). Mindbright's applet does sound like it has some nice bell's and whistles, though. Probably worth paying for if you were going to roll SSS over HTTP out as a solution to a larger group of users. (using ssh over httptunnel works great, but it can be a little confusing to set up the first time.) Otherwise, try httptunnel instead.
BlueCollarTech.com
** The opinions expressed here are my own, and do not reflect those of my employers - past, present, or future**
Heh, well I knew an admin at a 30 year old company (no .domb this one) who setup an mp3 jukebox with html interface for streaming to the whole office. YMMV :)
Besides, I can actually listen to music and work at the same time you know...
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
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.
The issue with SOAP is not one of security - what port you run on is neither here nor there - but the fact that most technologies based on XML are a load of old rubbish.
XML may be a "standard" but so are technologies such as Java serialisation and they work just fine over HTTP. This works automatically and leads to fewer programming errors due to "impedance mismatch", surely the chief source of any security holes and other bugs.
I don't buy the argument that an XML schema is any more future-proof than a Java class spec. Java handles class changes etc. quite elegantly. And I don't buy the "XML is language-independent" line either - it's just hard to read XML in any language. So you have to use that awful Xerces stuff that changes every 2 months, with little backward compatibility between versions.
Don't be fooled - there is simply nothing that uses XML that can't be done more elegantly some other way. XML is not a technology - it, along with SOAP, is a completely pointless standard.
bring your jacket liner to work. or use google. Your company doesn't need to buy more hardware and hire more techs just so you can remember which track is "Hit Me Baby One More Time"
We run into the same problems with our clients. We've got milestones to meet to make the suites happy, but the IT guys are totally unresponsive when it comes to opening up the firewall. Thus we aim for 80.
My company produces a client/server product that communicates via our custom message based protocol over a persistent TCP/IP socket. Because our product is designed to work from any computer, we have to consider that there is potentially many firewalls that we simply could never hope to have opened up for our service.
For that reason, the application server runs on ports 80 and 443. The traffic between the client and the server is very much *not* HTTP, or HTTPS, so we do run into problems with firewalls that can inspect and identify HTTP packets, but aside from those rare instances, this is an elegant solution to the firewall problem.
Is there something inherently wrong or evil with this solution?
That's right, genius boy. You need to hire more people and buy additional hardware to open a port or to download a few song titles. Not. Wakeup call - we had a flat rate T1. They didn't care if we ran high bandwidth stuff like streaming audio - and we could, because real audio tunnels on port 80.
Anyway, its called "an example".
As in, an example of how stupid it is that people can stream audio or use dangerous RPC like services or whatever, so long as its port 80, but something *completely innocuous* and *low bandwidth* is blocked purely because its on a different port.
Both you, and that company, need hitting with a cluestick...
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
A couple of rebuttals if I may.
Many people claim that one can run services on any port they choose, so port filtering is not the same thing as service filtering. True, but if people ran anything on any port we would have no concept of well-known-services at specific ports. Moving web traffic from port 80 makes almost no sense because that's where everyone is going to look for it by default. There is a high probability, then, that filtering on specific ports will filter specific services.
Network administrators, by default, are highly suspicious and paranoid people. They don't even trust the people they work with, and for good reason. If they could force everyone to use pine or mutt for e-mail reading, I'm sure they would since it is less succeptible to Outlook-born viruses. If development teams would communicate with and seek advice from the security team when developing applications I'm sure there wouldn't be as much hostility to opening a port as there is when approached with "We just wrote an application. Can we have a free port?"[1]. In the latter case, the security team has no idea what the application does or how it was developed and is certainly not inclined to open a port to untrusted software.
Finally, on to the subject of my article, Apache (or whatever server you're running) is the inetd of the future. Look at the facts:
- both listen on one or more ports for requests
- when a request comes in it is dispatched to the correct subsystem
- most security (ssl, https, tcpwrappers) is handled by the daemon before it gets to the service handler
- the service handler can perform further accouting or security checks
- the daemon handles all the networking details on behalf of the subsystem
Add to this the fact that this is all multiplexed on a single port, and configuring your firewall should be a breeze. Virtually anything you can do with inetd you can do with a good web server.Paradoxically, network admins appear less paranoid about their web servers than other inetd-based or standalone services. Some guy codes up a web app and, with little fuss, gets it deployed on the server. No code review, no hassle, no problem! There are only two reasons I can think of for this behavior: 1) The administrator inherently trusts the web server, or 2) the web server box is in a DMZ. I would be suspicious of administrators in the former case.
Despite the security advantages of a DMZ, it is still necessary for application developers to communicate with security people. Say, for example, that a web application is deployed on server in a DMZ and that the machine is later compromized. If the application had a configuration file with passwords for a database, the database should now be considered compromized. Damage can be reduced or prevented by correct configuration of the database (providing write access only to a specific table rather than the whole database), but you should check with the security people before actual deployment.[2]
[1] The standard answer to this question is "No". Note that the administrator only answers the question asked. If you want to be more successful in the future, present a full document detailing what the software does, how it works, and maybe provide the admin with a code review, THEN ask for a port. I know this is a lot of work, but it is necessary to maintain the security of the network. You may not take security seriously, but your administrator does.
[2] Yes, I know that there are moron security people out there. My comment assumes you have good to excellent security people working in your company.
I too have been in your situation many times. Anybody who claims that the private industry is somehow more efficient or clueful then the govt needs to read your post.
War is necrophilia.
I agree. I've seen many, many organizations where it is a flat out policy not to open ports other than 80/443.
I've always assumed that firewall administrators would soon block non-HTML traffic to eliminate these remote SOAP RPC calls.
That's when I'll make my fortune by patenting the idea of making RPC calls via Steganography. In order to execute a web service, you'll encrypt your SOAP message with gpgp, hide it in a JPG, and post it to a predetermined Ebay auction.
host address and protocol?
As most of the forum here says, security doesn't start at the port level. It comes from that application itself. If you SOAP transport accepts data from whoever send it, that is bad (just restricting IP's is stupid as well as it is brainless to spoof that). I would suggest running an authentication method on all trafic coming and going.
This can be done in any number of ways. Signing all the XML data with a GPG key to verify ownership of the data or the cheesy secret key method. Read up on how SSH works and key based authentication will seem like a viable option
Hire me...
I've been the guy blocking open port requests for months on end.
I'm afraid it's a necessary evil. Without the bureaucracy to prevent quick firewall changes, it would be more difficult to conduct a security review before the port has been opened. Of course, once a port is open and services are running, turning it off becomes a near impossibility.
You'd be amazed how little some software vendors seem to understand firewalls and the Internet. I've seen requests to open up a half-dozen ports through the firewall, including incoming ports to provide data that could be retrieved from the inside, were the software to allow it.
If your firewall is in the right hands, all those bureaucratic hurdles are a force for good, not evil. Unfortunately, that's a fairly large caveat.
I think you're dead on that what's missing is intelligent human beings who can look at a particular instance and correctly apply security procedures, including but not limited to policies, to protect assets to the degree warranted by business needs.
>> It also responds well to compression, due to redundancy. This isn't really a good thing about XML, so much as a description of how to lessen the impact of one of the bad things about XML.
The subject is all I wanted to say...
"Communism is like having one [local] phone company " - Lenny Bruce
You're right. Although many other means of transferring data do not compress well due to their "efficiency". XML responds well to data compression algorythms for several reasons. Unicode text always compresses pretty well. The redundancy is just one aspect.
If you fall off a building, go real limp, because maybe you'll look like a dummy and people will be like hey, free dummy
The problem with IIOP and DRPC is that they encode the communication enpoints as a hard IP address and port in the requests on the wire.
This makes these products virtually incompatable with network address translation (NAT) out of the box. Basically, the NAT boxes will translate a local, non-routable IP address into the IP address of the NAT box with a made-up port number. The problem is they don't modify the IP address and port numbers imbedded into the IIOP message.
There are products that will do this but you have a choice: 1) Teach your admins about another product and install the product both at your site and the client site or 2) teach them how to secure web services using the existing firewalls, load balancers, and SSL that they already understand -- no client site modifications required.
Securing web services properly (IMHO) requires that you have a layer 7 device that can look at the incoming SOAP requests and dump requests for an unknown endpoint on the floor immediately. The you have to make sure the request gets properly validated by the SOAP implementation and application layer.
So on the one hand you have IIOP and DRPC that require additional products or you have SOAP with requires you to apply the products that, if you have a significant web presence, you already have. Seems like an easy choice to me but you have to understand how all the pieces fit together. If you don't have that expertise in house, go rent it from somewhere.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.
I would just like to point out that the "everything on port 80" trend isn't limited to SOAP. WebDAV and most IM systems already work on the HTTP port and I see how this could be dangerous.
This sort of thing puts the burdon on Firewall developers to improve packet inspection when those resources could very well be used to create more useful things such as a better integrated IDS. It's just plain stupid, when the TCP protocol is so well stablished for assuring a certain level of security, to make things more complex on benefit of dumb users who don't know firewalls. It's obvious that really sensitve stuff should use SSL, but this cannot be the rule.
So let me get this straight...
SOAP is insecure because it runs on port 80? Why? Who cares? What's this got to do with security?
You can switch it to port 1234... but what does that gain you?
I understand why they would want XML.
My point was that SOAP and XML-RPC work by encapsulating the response to a function call in XML. If the response already is XML this is particularly redundant.
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
What exactly is it about threads that "encourage" people to use a one-thread-per-client model?
The fact that it's the only available method under some systems. For instance, last time I checked, 100% Pure Java(tm) applications had no nonblocking I/O facility, so you had to open a thread for each concurrent I/O stream.
What is it about RPC that encourages people to to ignore network overhead?
Try developers designing, testing, and optimizing an application on a local LAN and then wondering why it doesn't work across the full Internet.
Will I retire or break 10K?
If you want "soap on a rope", you might want to look at the Remote Object Proxy Engine (ROPE), a part of Microsoft's SOAP implementation that translates COM calls to SOAP calls.
Will I retire or break 10K?
Your system is only as secure as the programs you allow to run on it. If a remote procedure call comes in, no matter how, it's up to you to handle it in a secure way.
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
While i realy don't know jack about networking and security, I can't remember an exploit that made big headlines that ran over a port higher than 1024. The ports lower than 1025 have to be opened by a process that at least initialy has root privs, force a buffer overflow and you've got instant root privs and a wide open system.
if the port is greater than 1024 then any UID can open it, overflow it and you only get the privs of the opening UID. This will usualy stop the kiddies dead in there tracks, you're not going to stop a hardcore hacker that realy wants in anyways, usualy around the firewall through some salesweenies modem and telephone extention.
Another thing is what about outgoing connections? Don't they establish a dialog, you know two way, as in talking also involve listening.
I guess what I'm realy pointing out is security is an illusion, the best you can hope for is to make the effort to hack your system greater than the rewards gained. A computer encased in concrete sitting on the bottom of the ocean is as secure as they get, but not very usefull. Force everybody to go around your security policies, and you've got no security.
<obigatoryRant>
Beside I'll bet that you don't block SMTP, and Email read on one of the Microsoft virus launchers is about as insecure as you can get.</obigatoryRant>
Apocalypse Cancelled, Sorry, No Ticket Refunds
The real problem with this SOAP/"everything over HTTP" thing people are pushing is it's about having two networks that want to talk a lot of arbitrary stuff to each other, on almost any topic unimaginable.
Putting a firewall between such networks is usually counter productive. Because the whole idea of a firewall is to block almost everything. Otherwise what is the firewall for?
Worse, people are actually suggesting that one or both of these networks will be exposed to hostile/unsecured networks.
Think about it. Should something on an unsecured network be able to ask a server on a secured network to run hundreds or thousands of undeterminable remote procedures for it?
That's where the main problem is.
"Mean Old Admin" blocked everything other than HTTP in order to block EVERYTHING THAT PEOPLE NOW WANT TO DO OVER SOAP from getting through to corporate networks. Yes sir, Mean Old Admin thinks that it's a bad idea to have someone outside telling your internal servers to run arbitrary stuff.
"Mean Old Admin" knows that most of those SOAP programmers are clueless about security if not why did they design such a protocol in the first place.
Because if it's on trusted networks why bother with tunnelling, HTTP/XML etc- go direct less overheads. If it's on an untrusted network, you got a LOT of explaining and justification to do.
Seems a lot of programmers couldn't explain and justify why they would want to do everything over untrusted networks that's why they are trying to sneak everything over HTTP.
So can we be sure these people can code this stuff securely?
If a lot of people start doing this, we'd probably need BUGTRAQ-SOAP soon.
Here's an extract from the SOAP spec on SOAPAction:
The SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request.
The presence and content of the SOAPAction header field can be used by servers such as firewalls to appropriately filter SOAP request messages in HTTP. The header field value of empty string ("") means that the intent of the SOAP message is provided by the HTTP Request-URI. No value means that there is no indication of the intent of the message
Yes, but that doesn't help you if the application is actually runs as root. (Sub 1024 ports are blocked for users because they are reserved ports, ftp and such should not be "spoofable" by users.) If your web server runs as root it doesn't matter if it's at port 80 or port 8080. If it's hacked it will give a root priviliges in any case. (Not that a www server
Yes, when an outgoing connection is established then the firewall/NAT will redirect a port in the other direction for the "answer". However this port is bound to a specific IP. (The IP of the computer the internal computer was contacting.) So it's not all that easy to exploit. (It can be done of course.)
And of course security is an illusion. You are never completely safe. That doesn't mean you should begin doing stupid things just because "well we are not safe anyways". Then you might as well tear the firewall down, it won't do you any good.
A request for a page produced by a CGI script is plain text. The CGI server runs a local, trusted application that outputs a plain HTTP text stream that is sent to the client that requested it (usually a web browser) and is not interpretted (except by javascript or a browser plugin)
SOAP implements the equivalent of allowing a remote host to send executable code to the client over a connection that is expecting plain text. It is the equivalent of having Outlook with VB Macros enabled that automatically executes as soon as an email is *received*. The biggest difference is that it is port 80 instead of 25. You will rely completely on the application itself to enforce whatever security restrictions.
Chances are that some SOAP applications will be browser plugins. But this is an opportunity for every SOAP service provider to lock you in to their proprietary interpreter, displayer, whatever; and believe me, they will.
SOAP bypasses security on the client-side. The host running the SOAP server knows the inherent risks. The same as running any network available service. What soap does is run a server process on the client's machine that attempts to bypass any firewall as well as allowing executable code to be run on the client.
if you use soap, you will
you'd be wise to keep IT (the data) off a 'pubic' web server.
What exactly does a 'pubic' web server contain? Porn?
Well, we didn't use Outlook, and all SMTP traffic was filtered through two different platforms with virus scanning on at least one.
The company also did periodic checks on phone lines to make certain only authorized modems would respond.
As someone else has pointed out, the UID question is a non-starter. It requires root privileges to bind a service to a port lower than 1024, but not to run the service past that point.
Outgoing connections were very limited as well, and as the other response pointed out, firewalls handle those relatively securely.
Anyway, this is a previous employer, but I still don't want to get too detailed about their security setup. Suffice it to say that I don't think a paranoid firewall policy is unreasonable, particularly for a large company.