kowsik

'Reflections on Trusting Trust' https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

Ultimately, the web is an attack vector that no one is immune to. Did you read the Syria hack recently? Just a skype chat with an attractive opposite-gender is enough to download a piece of malware masquerading as a picture you really want to see. While the human aspect has always been a key element of getting hacked, products that claim to distinguish the good vs. bad are failing big time. And this has been the pillar of enterprise security (classifying good against bad) for the last 20 years and is starting to show its age.

True that about the security engineers, but they are at the mercy of products that claim to distinguish good from bad and this has never worked, IMHO. How the hell can you write signatures against malware/documents/web-sites/files/attacks/blah when there's so much diversity and quantity of stuff to keep up with?

Disclaimer: I built the first IPS to be commercialized and yes we used signatures amongst other things.

+1 on the "sophisticated" == 'SQL injection', though it's all speculation at this point.

The security industry/products seriously need a make over. So much money spent and yet, hacks just keep getting bigger and worse.

[edit]: Disclaimer - I'm CTO at @menlosecurity.

See Ben Kepes' review here: http://wp.me/p8KWj-3Uj

Depends on what your expectations are. I built https://www.delayed-tweets.com for myself and I'm a heavy user of it and I tinker with it when I have time (Heroku + Stripe, if you want to know). If it also becomes a source of income, so be it. Otherwise, it costs me just a little more than using an alternate service to do the same thing (like HootSuite, Buffer, etc). But, I get to tinker with it on the side, learning new things and making little improvements as I have time. So 6 months from now, I don't have to be disappointed that it didn't go anywhere. A side project is exactly that, something that you tinker with while you still have a day job.

Very cool - just a few weeks ago, I spent two weekends (8 hours total) building https://www.delayed-tweets.com. Sinatra on Heroku + Stripe along with a bunch of gems to connect up to Facebook, Twitter and LinkedIn. It's mainly for my personal use right now, but awesome to see others having simliar needs to schedule and cross post social updates.

[edit] The "big" monthly cost for this project for me is primarily the SSL add-on. Everything else amounts to nothing since I have no long running dynos, even for resque.

Regarding ease of use, if you are a dev, there's always toto or jekyll. Throw in disqus for commenting and you are pretty much done. Each blog is just a simple haml/erb/liquid template and git push is all you need to get a new page/blog up.

I've been writing C and C++ for a long time (kernel and user mode) and what I find is, it takes a fair bit of discipline when writing C++ code (like hiding new/delete for stack-only objects or ensuring operator= works for heap objects and so on). Debugging with STL and templates can be PITA since the error messages are so convoluted in most compilers. One thing I would agree on Linus, is the talent pool of disciplined C++ programmers is pretty scarce. There are tons more C programmers that have enough OO experience of faking vtables and building structs-with-callbacks to simulate class inheritance and what not.

You can find out with dyno-blitzer: https://github.com/pcapr/dyno-blitzer

the cedar stack has a writeable file system, though no persistence across dyno recycles/restarts.

See this: http://blog.mudynamics.com/2011/09/05/help-couchdb-break-the... for various server tuning (not really CouchDB-specific). You can change the net.ipv4.ip_local_port_range to "1024 65535" to increase this range.

Read this thread first - http://news.ycombinator.com/item?id=2945185

Here's the blog on what we are learning as we scale: http://blog.mudynamics.com/2011/09/01/blitz-io-path-finding-...

I can only speak for http://blitz.io. We generate an account-specific UUID which becomes a URL that you need to make available on your app (adding a route in ruby/node.js or uploading a txt file). Before each load test we check that your UUID is available on the app. Even if your UUID is leaked, this is not a problem, since it's unique to your account. Unless of course, your Google/Facebook account gets compromised. We currently, do not support password logins. It's either OAuth/FB Connect or SSO through our partners.

thanks for the vote of confidence, will write up what happened soon.

sorry, we had a glitch this morning when one of our db clusters went offline - had to reroute all traffic to our other cluster - all good now.

You have to think about concurrency. If there were a total of 64K simultaneous requests to that physical instance, each of which is running 100+ apps because it's multi-tenant, this drastically reduces the number of ports available to each app. With evented IO, a socket could be open for 250 ms (db query taking time) that sucks up a port causing a potential DoS on the other apps.

thank you, thank you! whew Hopefully the new picture on the blog clarifies which ports I'm talking about.

Talking about port exhaustion is, I realize, a little confusing because there are the web requests coming in and the web-tier is making outbound requests to other services. Adding an image to the blog to hopefully clarify things.

I've added a picture to clarify which ports I'm talking about. Hopefully this clarifies things a bit.

My point is the thing you are connecting in the back-end has to scale at the same level as node - if not better. I'm sure making independent non-pipelined requests to CouchDB will help, but if CouchDB views are slow or it can't handle the concurrency, then the web requests to node.js will start slowing down resulting in a pipeline stall.

We had a node.js app where each inbound request would go through a set of HTTP connections to the back-end couchDB. When the concurrency reached around 1,000 then there were 1,000 requests made through 10 couchDB pipelined connections. The result was the web requests were starting to get slower and slower. Think of a 6-lane road merging into a 1-lane road. Congestion.

Okay, we are talking past each other. If you have a server on an EC2 instance, with enough RAM you can support more than 64K inbound connections for exactly the reasons you mention. Try generating more than 64K connections outbound and this is exactly what I'm talking about.

My observation/assumption is that your app is running in a multi-tenant PaaS environment, where mysteriously you start getting bind errors because the ephemeral port space is shared with other tenants.

Read the blog again. This is bollocks if you are running your own server where you can be multi-homed, add loopback aliases etc and crank up the memory to support 100,000+ sockets. I'm talking PaaS where your app is an multi-tenant environment with no root access.

try dyno-blitzer https://github.com/pcapr/dyno-blitzer which scales up dynos, runs a load test and tells you how many dynos you'll need to support x concurrent users.

It's going to cost you no more than $79/day * 2 for two days of load testing if you sign up directly to http://blitz.io. That's peanuts compared to anything else on the market. And with EC2 lowering inbound bandwidth costs, this only gets better!

One more thing. An m1.small instance on EC2 (on-demand pricing) will cost you around $60/month + bandwidth costs. So you need a multi-tenant load testing solution to amortize the costs and drive hourly price down, which is what we are doing.