On Sun, Apr 12, 2015 at 6:22 PM, Ish Sookun <ish_at_hacklog.in> wrote:
> On Sun, Apr 12, 2015 at 9:31 PM, Loganaden Velvindron <loganaden_at_gmail.com>
> wrote:
>>
>>
>> I believe that this was before I left the said company in 2012.
>>
>> In 2010, I worked on a very big project. I'm trying to reach my
>> ex-boss, but he doesn't seem to be around. I would just like to check
>> if it's ok with him if I disclose the client's name, which we will
>> call Big-Client for now.
>>
>> So big-client came to us to develop a very complex website, and they
>> wanted it to be both fast & secure.
>>
>> When we finished the first prototype, it was already quite slow, and
>> of course, Big-client wouldn't accept it. It was painfully slow, and
>> Big-client had made it clear that they wanted the website to load
>> completely in less than 30 seconds, despite the insane amount of
>> complexity involved in the code :-)
>
>
> Long-story cut short. I only want to know what you call a "very large
> project". You answered by the word "complexity". They are two different
> things.
>
> I can have a plain HTML file getting 100K/hits per second and a Java webapp
> calculating heat of the planet getting 1 hit per month. Which one do you
> call large and which one complex?
Large: as in a huge catalog of items, that were destined for the
european and US market.
Complex: The huge amount of dynamic content, that were written in a
CMS which was heavily customised. The client had many wishes, and the
code generated was quite complex, requiring a different kind of
architecture to meet the performance & security demands.
>
>>
>> One of the patches here:
>>
>> http://markmail.org/message/6ekrembdv5ml6o5i#query:+page:1+mid:6ekrembdv5ml6o5i+state:results
>
>
> Are telling me the patch you wrote to disable "remote debug support"
> actually made memcached function better? So, were you running memcached on a
> public IP with no firewall rule in the first place? I guess you had strong
> reasons for doing that.
Firewall was a standard thing :-) However, there's is one attack
vector that you didn't take into account in your scenario :-)
_at_Everybody who is reading this mail: There is still a way to hack
servers, by bypassing typical firewall rules. Those attacks are used
by elite crackers on the internet :-)
There are security problem with memcached that I was fixing at the time:
http://it.slashdot.org/story/10/08/07/035255/cache-on-delivery-memcached-opens-an-accidental-security-hole.
Again, I would like to point out that simply using a typical firewall,
does not completely solve the security problem in memcache :)
>
> In the email, your signature states "Esokia Web Agency". So, technically
> that patch belongs to Esokia as you were paid by the same for doing it. Am I
> right?
Esokia webagency was among the first companies to send code to Open
Source projects in Mauritius. I was paid to do security & high
performance work at Esokia, on top of normal system administration
tasks for high profile projects.
I suggested that we send our code, and discuss ways to integrate it,
as it would reduce the amount of internal engineering to keep the
patches in sync. Engineering-wise, it makes total sense :-)
>
>> It's funny to think that many large websites scrambled to take my
>> patches for their memcached for their big websites, including several
>> large companies in the US :-)
>
>
> Esokia's patch?
The patch that Esokia sponsored me to develop :-)
>
>
> What do you mean by scrambled to take your patches? There is a difference
> between a project accepting your patch because it is a good code and
> companies running after you begging for a patch. Your text above sounds more
> like the latter.
I was hanging on developer channels, and the news hit slashdot, every
large company relying on memcache were looking for solutions. I
mentioned to them, that I had a patch, that fixes the issue. They
immediately showed interest. After consultation, we decided to send
our code upstream:
Again, simply using a firewall, does not solve the problem. Those
large US websites were highly attractive targets on the internet and
they attracted elite hackers. Hacking one of them would bring a
cracker huge amount of money & fame :-)
(Hint: A partial List of large companies relying on memcache can be
found in the security presentation of sensepost on memcache :-))
>
>> At one point, we pushed the remaining server bits to the client,
>> documented it, and they took over the maintainance of the big website.
>>
>> It appears that once I left, the said company took smaller projects in
>> scale, and they appear to have outsourced the infrastructure
>> management to another company. ex-employees have told me that it was
>> hard to find systems engineers who could design high-performance and
>> secure web servers, and the web agency couldn't find people of the
>> same caliber to fill in. I guess they scaled down their ambitions, and
>> went with sysadmins who deployed from templates, and watch servers
>> with top :-) :-D
>
>
> As per your saying your ex-exployer was getting "very large projects" thanks
> to you then? That's a big claim you know.
It happened quite a few times :)
>
> "top" is just one of the many investigative tools that gives you a quick
> overview of your system resources utilization. It's not to be trusted alone
> as you could analyze more from your /proc arborescence. So, I believe you
> ex-employer has brought in some freshers and they yet need to get an
> experience. It's okay to be new in the field. There's nothing to :-D about
> that.
My ex-collegues often complained about the company that was paid to
manage the infrastructure, once I left :)
>
> Cheers,
>
> --
> Ish Sookun
>
> - Geek by birth, Linux by choice.
> - I blog at HACKLOG.in.
>
> https://twitter.com/IshSookun ^^ Do you tweet?
Received on Sun Apr 12 2015 - 19:17:04 PST