Hi folks,
> >Given that the 0MQ code has not bee through any kind of security audit
> >(however formal/informal that may be) we should not be claiming that 0MQ
> >2.0.x is in any way suitable for deployment of Internet-connected
> services.
> >The FAQ entry regarding security should be updated to explicitly state
> >this.
>
> Yes. It's easy to kill 0MQ nodes by sending them poisonous data. It
> causes assert instead of undefined (and possibly malicious) behaviour,
> however, it shoudn't crash at all. Instead it should log and continue.
>
> >Now, as for 0MQ 2.1.x, I think we're getting to the point where putting
> in
> >effort for making 0MQ suitable for deployment on the global Internet or
> >other untrusted networks is worthwhile. However, this does need to be
> done
> >systematically.
> >
> >Martin, this means that from a network point of view we should follow the
> >well known principle of "be conservative in what you send, and liberal in
> >what you accept". It should not be possible to crash 0MQ from the network
> >side.
>
> Agreed. Missing logging infrastructure was preventing to implement the
> correct behaviour. Sane logging is in a subtle way dependent on
> migration of sockets between threads etc. Now that we have all that
> functionality in the trunk, it should be easy to apply "log and
> disconnect" approach to poisonous connections.
I don't want to jump the gun and start going hog wild on security
but if the API is to remain pretty much the same, which I agree with, I
"HIGHLY" suggest not even thinking about trying to support internet
connections and instead write a gateway with all the real security to sit
between a client and the internal cluster. There is unfortunately a hell of
a lot of stuff that zmq would be required to do which is just not
appropriate for what it does.
This is what I'm using as my primary experimentation platform for
Zmq; a gateway system. Just some of the things a "generally" secure and
reasonable gateway should provide:
1. The big one. Single connection, single point of failure when
dealing with the internet. Not to mention, without connect/disconnect
notifications, a client app would end up with really crappy feedback if it
couldn't determine if/when it got disconnected. All messages, even if
intended to route to a specific service in the server, should route from the
client down a single tcp connection in the gateway for validation prior to
being sent into the cluster.
2. Ip bans and filtering. Most permanent bans should be in hardware
routers but personal hobby stuff will need software bans if they don't have
such abilities. Additionally you need software bans for exponential backoff
of failed connection attempts. I.e. you connected and failed to validate,
you are banned for 5 seconds, you connected and failed to validate less than
5 seconds ago so you are now banned 10 seconds etc etc. Closing repeated
connections quick is a first step against ddos attacks and such. I.e. no
auto reconnect. (Auto reconnect opens things up to force disconnecting a
process so a new process can take over the stream and do bad things.)
3. Client validation user/password stuff. I won't accept a connection
is allowed to send any message unless it is "ThisIsMe" with a valid
user/password on the internet. This can be supported with Zmq, I believe,
but a dedicated system is actually a lot easier in this case.
4. SSL or other encryption, I wouldn't want this in the cluster, only
in the gateway to client connection. Waste of cpu/memory if used internally
where no one can intercept packets.
5. No synchronization between client and gateway.
Rep/Req/Push/Pull/etc don't fit with the possible non-uniform ways a client
could want to communicate with a server "cluster".
6. Zmq doesn't support oob. Emergency messages, time critical items
etc can go down the oob pipe of tcp, this is missing from zmq.
What I'm building right now as an experiment is a fully async
bridging device with all of the above items trying to be covered. I'm using
zmq push/pull to validate banned ip's, zmq for key validations etc. Zmq
sits behind such a thing quite well.
KB
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
