nenolod

you seem to be new to this, most companies lie all the time about the nature of their security compromises.

the database server is local, read the entire log...

the compression is unnecessary here, you're moving a max of less than a couple of hundred GB of data.

for the record, i am the person who started the WHT thread.

there is a mixture of truth and lies on both sides, to be honest.

i am annoyed with it, because i reached out to several linode employees privately to given them an opportunity to explain what was going on -- they either said 'no comment' or said my linode was fine.

based on the irc log, that is clearly not the case. which is why i decided to raise my concerns publically.

luckily for me, my linode was not doing anything mission-critical, just some secondary monitoring and running an ircd for a network i like using, but there are others who are using linode for mission-critical work, and they deserve more transparency than this.

dd if=/dev/sda bs=1M | ssh root@<newhost> dd of=/dev/sda bs=1M

let SSH handle compression for you instead.

Except Linode didn't tell us that. Linode said it was a downstream customer's info that was compromised. Nothing about Linode itself.

Hacker News, wherein I find further motivation to immediately get my off-site services off of Linode...

yes, Cisco discontinued the Guard module, which is unfortunate, as it did a pretty good job at determining what ACLs needed to be generated and applying them, and was actually much cheaper than the appliances.

in terms of mitigation hardware, all of those appliances are a ripoff. the solution is to replace them with free software that does automatic analysis on the flows and then sends that data automatically elsewhere, putting them out of business.

i have a system set up that does automatic mitigation using ddosmon by having a "scrubbing center" running on freebsd-based devices. this is accomplished by having a custom 'action' module in ddosmon which does three things:

- calculate the necessary ACLs

- insert them into the appropriate pf tables so the mitigation strategy fits my ruleset

- direct the router to send traffic for the IP being flooded to the scrubbing appliance

this is basically the way that the mitigation appliance vendors tell you to do it if you're handling >10gig floods anyway.

i think ddos mitigation is really a place where free software can cause a massively needed paradigm shift.

your example is pointless as no actual datacenter actually pays their equipment vendor anywhere near list price for those devices. i certainly don't.

network equipment vendors like to have high list prices in order to:

- ensure they get sales inquiries from serious buyers;

- give sales representatives a large amount of leverage when negotiating the actual line-item pricing for each purchase order;

- promote some kind of enhanced "value" to executives ("it costs a lot of money, so it must be good!")

a realistic price for two routers with two 10gig-e linecards is about $15,000-$25,000 per unit direct from brocade. cisco would be around the $35,000-$50,000 per unit ballpark. if you're paying any more than that, you're getting extremely shafted.

further, the circuits for the uplinks aren't going to cost that much themselves, as it's all sold under percentile-billing (not even 95%, usually more like 90% or 80% at over-gig-e levels these days) when we're talking actual transit costs. commits for "Joe's Web Hosting" might only be 1.5gig on each 10gig circuit, so that cuts down pricing a lot right there.

in terms of getting an experienced engineer, most attacks can be detected and mitigated automatically using netflow/sflow/ipfix flow analysis. i wrote software which handles the detection automatically, with a fairly high success rate, and it's free to use on bitbucket. :)

well, that's the danger of MLAT treaties in this time of multinational corporations. even though ahimsa.i.o was hosted in london, the datacenter facility was owned by rackspace which was based in the USA so they had to comply with the MLAT request initiated by the dutch. it was a shitty deal, but certainly not rackspace's fault completely.

you're expecting competence from HE?

i colo'd at HE until last year when they ran ~400V through my racks which had 110V circuits, several PDUs and servers were damaged. that was the cherry on top of the sundae though, there had been 2 power outages at that point and 2 other outages after that point.

use a DNS roundrobin with low TTLs and use monitoring to remove IPs when they go down. if you have 3 hosts in your production app's roundrobin, that makes it much less likely that they'll hit the dead server and if the TTL is 300, then it's only a few minute window anyway.

Yes, the PayPal debit cards are US-only. They also had virtual cards, which was an intriguing product, but it got cancelled when they got rid of the browser plugin.

PayPal will back you up on virtual services provided that you log the customer's IP so that you can prove that the access was legitimate (e.g. from the customer's IP that he uses to log into PayPal regularly).

I have yet to lose on a chargeback or dispute.

That said, sweeping the PayPal balance to a real bank account is always the smart option.

Google Checkout is a good alternative. We clear almost as much money through Google as we do through PayPal and they strictly concentrate on processing payments... unlike PayPal which tries to do more than that.

But, it is only available in a few countries so it may not be available to you.