Como lidar com um servidor comprometido?

É difícil dar conselhos específicos do que você postou aqui, mas eu tenho alguns conselhos genéricos com base em um post que escrevi há muito tempo atrás, quando eu ainda podia me incomodar em blogar.

Não entrar em pânico

Primeiramente, não há "soluções rápidas" além de restaurar seu sistema a partir de um backup feito antes da invasão, e isso tem pelo menos dois problemas.

1. É difícil identificar quando a invasão aconteceu.
2. Não ajuda a fechar o "buraco" que permitiu que eles invadissem da última vez, nem a lidar com as consequências de qualquer "roubo de dados" que também possa ter ocorrido.

Esta pergunta continua sendo feita repetidamente pelas vítimas de hackers que invadem seu servidor web. As respostas raramente mudam, mas as pessoas continuam fazendo a pergunta. Não tenho certeza por quê. Talvez as pessoas simplesmente não gostem das respostas que viram ao procurar ajuda ou não consigam encontrar alguém em quem confiem para aconselhá-las. Ou talvez as pessoas leiam uma resposta a essa pergunta e se concentrem demais nos 5% do motivo pelo qual seu caso é especial e diferente das respostas que podem encontrar on-line e percam os 95% da pergunta e resposta em que o caso é próximo o suficiente como o que eles lêem online.

Isso me leva à primeira pepita importante de informação. Eu realmente aprecio que você seja um floco de neve único e especial. Eu aprecio que seu site também seja, pois é um reflexo de você e sua empresa ou, no mínimo, seu trabalho árduo em nome de um empregador. Mas para alguém de fora olhando para dentro, seja um segurança de computador olhando para o problema para tentar ajudá-lo ou até mesmo o próprio invasor, é muito provável que seu problema seja pelo menos 95% idêntico a todos os outros casos que eles alguma vez olhou.

Não leve o ataque para o lado pessoal e não leve para o lado pessoal as recomendações que seguem aqui ou que você recebe de outras pessoas. Se você está lendo isso depois de se tornar vítima de um hack de site, sinto muito e realmente espero que você possa encontrar algo útil aqui, mas não é hora de deixar seu ego atrapalhar o que você precisa Faz.

Você acabou de descobrir que seus servidores foram invadidos. O que agora?

Não entre em pânico. Absolutamente não aja com pressa, e absolutamente não tente fingir que as coisas nunca aconteceram e não aja de forma alguma.

Primeiro: entenda que o desastre já aconteceu. Este não é o momento para negação; é hora de aceitar o que aconteceu, ser realista sobre isso e tomar medidas para gerenciar as consequências do impacto.

Algumas dessas etapas vão doer e (a menos que seu site tenha uma cópia dos meus detalhes) eu realmente não me importo se você ignorar todas ou algumas dessas etapas, isso é com você. Mas segui-los corretamente tornará as coisas melhores no final. O remédio pode ter um gosto horrível, mas às vezes você precisa ignorar isso se realmente quiser que a cura funcione.

Impeça que o problema se torne pior do que já é:

1. A primeira coisa que você deve fazer é desconectar os sistemas afetados da Internet. Quaisquer outros problemas que você tenha, deixar o sistema conectado à web só permitirá que o ataque continue. Quero dizer isso literalmente; peça a alguém para visitar fisicamente o servidor e desconecte os cabos de rede, se for necessário, mas desconecte a vítima de seus assaltantes antes de tentar fazer qualquer outra coisa.
2. Altere todas as suas senhas para todas as contas em todos os computadores que estão na mesma rede dos sistemas comprometidos. Não mesmo. Todas as contas. Todos os computadores. Sim, você está certo, isso pode ser um exagero; por outro lado, talvez não. Você não sabe de qualquer maneira, não é?
3. Verifique seus outros sistemas. Preste atenção especial a outros serviços voltados para a Internet e àqueles que detêm dados financeiros ou outros dados comercialmente sensíveis.
4. Se o sistema retiver os dados pessoais de alguém, informe imediatamente a pessoa responsável pela proteção de dados (se não for você) e URGE uma divulgação completa. Eu sei que este é difícil. Eu sei que essa vai doer. Eu sei que muitas empresas querem varrer esse tipo de problema para debaixo do tapete, mas a empresa terá que lidar com isso - e precisa fazê-lo de olho em todas e quaisquer leis de privacidade relevantes.

Por mais aborrecidos que seus clientes possam ficar por você contar a eles sobre um problema, eles ficarão muito mais aborrecidos se você não contar a eles, e eles só descobrirão por si mesmos depois que alguém cobrar $ 8.000 em mercadorias usando os detalhes do cartão de crédito que eles roubou do seu site.

Lembra do que eu disse anteriormente? O mal já aconteceu. A única questão agora é quão bem você lida com isso.

Entenda o problema completamente:

1. NÃO coloque os sistemas afetados online novamente até que este estágio esteja totalmente concluído, a menos que você queira ser a pessoa cuja postagem foi o ponto de inflexão para eu realmente decidir escrever este artigo. Eu não vou linkar para esse post para que as pessoas possam dar uma risada barata, mas a verdadeira tragédia é quando as pessoas não conseguem aprender com seus erros.
2. Examine os sistemas 'atacados' para entender como os ataques conseguiram comprometer sua segurança. Faça todos os esforços para descobrir de onde os ataques "vieram", para que você entenda quais problemas você tem e precisa resolver para tornar seu sistema seguro no futuro.
3. Examine os sistemas 'atacados' novamente, desta vez para entender para onde os ataques foram, para que você entenda quais sistemas foram comprometidos no ataque. Certifique-se de seguir todas as indicações que sugerem que sistemas comprometidos podem se tornar um trampolim para atacar ainda mais seus sistemas.
4. Certifique-se de que os "gateways" usados ​​em todo e qualquer ataque sejam totalmente compreendidos, para que você possa começar a fechá-los adequadamente. (por exemplo, se seus sistemas foram comprometidos por um ataque de injeção de SQL, então você não apenas precisa fechar a linha de código defeituosa específica pela qual eles invadiram, como também auditar todo o seu código para ver se o mesmo tipo de erro foi feito em outro lugar).
5. Entenda que os ataques podem ser bem-sucedidos devido a mais de uma falha. Freqüentemente, os ataques são bem-sucedidos não por encontrar um bug principal em um sistema, mas por reunir vários problemas (às vezes menores e triviais por si só) para comprometer um sistema. Por exemplo, usando ataques de injeção de SQL para enviar comandos para um servidor de banco de dados, descobrir que o site/aplicativo que você está atacando está sendo executado no contexto de um usuário administrativo e usar os direitos dessa conta como um trampolim para comprometer outras partes do um sistema. Ou como os hackers gostam de chamar: "mais um dia no escritório aproveitando os erros comuns que as pessoas cometem".

Por que não apenas "reparar" o exploit ou rootkit que você detectou e colocar o sistema novamente online?

Em situações como essa, o problema é que você não tem mais controle desse sistema. Não é mais o seu computador.

A única maneira de ter certeza de que você tem o controle do sistema é reconstruir o sistema. Embora haja muito valor em encontrar e corrigir o exploit usado para invadir o sistema, você não pode ter certeza sobre o que mais foi feito no sistema depois que os invasores obtiveram o controle (na verdade, não é inédito para hackers que recrutam sistemas em uma botnet para corrigir as explorações que eles próprios usaram, para proteger "seu" novo computador de outros hackers, bem como instalar seu rootkit).

Faça um plano para recuperação e para colocar seu site online novamente e cumpri-lo:

Ninguém quer ficar offline por mais tempo do que o necessário. Isso é um dado. Se este site for um mecanismo de geração de receita, a pressão para trazê-lo de volta ao ar rapidamente será intensa. Mesmo que a única coisa em jogo seja a reputação da sua empresa, isso ainda vai gerar muita pressão para colocar as coisas de volta rapidamente.

No entanto, não ceda à tentação de voltar a ficar online rápido demais. Em vez disso, mova-se o mais rápido possível para entender o que causou o problema e resolvê-lo antes de voltar a ficar online, ou então você quase certamente será vítima de uma intrusão mais uma vez, e lembre-se, "ser hackeado uma vez pode ser classificado como infortúnio; ser hackeado novamente logo em seguida parece descuido" (com desculpas a Oscar Wilde).

1. Presumo que você tenha entendido todos os problemas que levaram à invasão bem-sucedida antes mesmo de começar esta seção. Eu não quero exagerar o caso, mas se você não fez isso primeiro, então você realmente precisa. Desculpe.
2. Nunca pague chantagem/dinheiro de proteção. Este é o sinal de uma marca fácil e você não quer que essa frase seja usada para descrevê-lo.
3. Não fique tentado a colocar o(s) mesmo(s) servidor(es) novamente online sem uma reconstrução completa. Deve ser muito mais rápido construir uma nova caixa ou "tirar o servidor da órbita e fazer uma instalação limpa" no hardware antigo do que auditar cada canto do sistema antigo para garantir que ele esteja limpo antes de colocá-lo de volta on-line novamente. Se você discordar disso, provavelmente não sabe o que realmente significa garantir que um sistema seja totalmente limpo ou que os procedimentos de implantação de seu site sejam uma bagunça profana. Você provavelmente tem backups e implantações de teste do seu site que você pode usar apenas para criar o site ao vivo e, se não tiver, ser hackeado não é seu maior problema.
4. Tenha muito cuidado ao reutilizar dados que estavam "ativos" no sistema no momento do hack. Não direi "nunca faça isso" porque você simplesmente me ignorará, mas, francamente, acho que você precisa considerar as consequências de manter os dados por perto quando sabe que não pode garantir sua integridade. Idealmente, você deve restaurar isso de um backup feito antes da invasão. Se você não pode ou não quer fazer isso, você deve ter muito cuidado com esses dados porque eles estão corrompidos. Você deve estar especialmente ciente das consequências para outras pessoas se esses dados pertencerem a clientes ou visitantes do site e não diretamente a você.
5. Monitore o(s) sistema(s) cuidadosamente. Você deve decidir fazer isso como um processo contínuo no futuro (mais abaixo), mas se esforça para ficar atento durante o período imediatamente após o site voltar a ficar on-line. Os invasores quase certamente voltarão, e se você puder localizá-los tentando invadir novamente, certamente será capaz de ver rapidamente se realmente fechou todos os buracos que eles usaram antes, mais os que eles fizeram para si mesmos, e você pode reunir informações úteis informações que você pode passar para as autoridades locais.

Reduzindo o risco no futuro.

A primeira coisa que você precisa entender é que a segurança é um processo que você tem que aplicar durante todo o ciclo de vida de projeto, implantação e manutenção de um sistema voltado para a Internet, não algo que você pode colocar algumas camadas sobre seu código depois como barato pintar. Para ser adequadamente seguro, um serviço e um aplicativo precisam ser projetados desde o início com isso em mente como um dos principais objetivos do projeto. Sei que isso é chato e você já ouviu tudo isso antes e que eu "simplesmente não percebo a pressão, cara" de colocar seu serviço beta web2.0 (beta) em status beta na web, mas o fato é que isso continua sendo repetido porque era verdade na primeira vez que foi dito e ainda não se tornou uma mentira.

Você não pode eliminar o risco. Você nem deveria tentar fazer isso. No entanto, o que você deve fazer é entender quais riscos de segurança são importantes para você e entender como gerenciar e reduzir o impacto do risco e a probabilidade de que o risco ocorra.

Que medidas você pode tomar para reduzir a probabilidade de um ataque ser bem-sucedido?

Por exemplo:

1. A falha que permitiu que as pessoas invadissem seu site era um bug conhecido no código do fornecedor, para o qual um patch estava disponível? Em caso afirmativo, você precisa repensar sua abordagem de como corrigir aplicativos em seus servidores voltados para a Internet?
2. A falha que permitiu que as pessoas invadissem seu site era um bug desconhecido no código do fornecedor, para o qual um patch não estava disponível? Eu certamente não defendo a mudança de fornecedores sempre que algo assim o incomoda, porque todos eles têm seus problemas e você ficará sem plataformas em um ano no máximo se adotar essa abordagem. No entanto, se um sistema constantemente o decepcionar, você deve migrar para algo mais robusto ou, no mínimo, rearquitetar seu sistema para que os componentes vulneráveis ​​permaneçam embrulhados em algodão e o mais longe possível dos olhos hostis.
3. A falha foi um bug no código desenvolvido por você (ou um contratado trabalhando para você)? Em caso afirmativo, você precisa repensar sua abordagem de como você aprova o código para implantação em seu site ativo? O bug pode ter sido detectado com um sistema de teste aprimorado ou com alterações no seu "padrão" de codificação (por exemplo, embora a tecnologia não seja uma panacéia, você pode reduzir a probabilidade de um ataque de injeção de SQL bem-sucedido usando técnicas de codificação bem documentadas ).
4. A falha foi devido a um problema com a forma como o servidor ou o software do aplicativo foi implantado? Em caso afirmativo, você está usando procedimentos automatizados para criar e implantar servidores sempre que possível? Estes são uma grande ajuda para manter um estado de "linha de base" consistente em todos os seus servidores, minimizando a quantidade de trabalho personalizado que deve ser feito em cada um e, portanto, minimizando a oportunidade de cometer um erro. O mesmo vale para a implantação de código - se você precisar que algo "especial" seja feito para implantar a versão mais recente do seu aplicativo da Web, tente automatizá-lo e garantir que sempre seja feito de maneira consistente.
5. Could the intrusion have been caught earlier with better monitoring of your systems? Of course, 24-hour monitoring or an "on call" system for your staff might not be cost effective, but there are companies out there who can monitor your web facing services for you and alert you in the event of a problem. You might decide you can't afford this or don't need it and that's just fine... just take it into consideration.
6. Use tools such as tripwire and nessus where appropriate - but don't just use them blindly because I said so. Take the time to learn how to use a few good security tools that are appropriate to your environment, keep these tools updated and use them on a regular basis.
7. Consider hiring security experts to 'audit' your website security on a regular basis. Again, you might decide you can't afford this or don't need it and that's just fine... just take it into consideration.

What steps can you take to reduce the consequences of a successful attack?

If you decide that the "risk" of the lower floor of your home flooding is high, but not high enough to warrant moving, you should at least move the irreplaceable family heirlooms upstairs. Right?

1. Can you reduce the amount of services directly exposed to the Internet? Can you maintain some kind of gap between your internal services and your Internet-facing services? This ensures that even if your external systems are compromised the chances of using this as a springboard to attack your internal systems are limited.
2. Are you storing information you don't need to store? Are you storing such information "online" when it could be archived somewhere else. There are two points to this part; the obvious one is that people cannot steal information from you that you don't have, and the second point is that the less you store, the less you need to maintain and code for, and so there are fewer chances for bugs to slip into your code or systems design.
3. Are you using "least access" principles for your web app? If users only need to read from a database, then make sure the account the web app uses to service this only has read access, don't allow it write access and certainly not system-level access.
4. If you're not very experienced at something and it is not central to your business, consider outsourcing it. In other words, if you run a small website talking about writing desktop application code and decide to start selling small desktop applications from the site then consider "outsourcing" your credit card order system to someone like Paypal.
5. If at all possible, make practicing recovery from compromised systems part of your Disaster Recovery plan. This is arguably just another "disaster scenario" that you could encounter, simply one with its own set of problems and issues that are distinct from the usual 'server room caught fire'/'was invaded by giant server eating furbies' kind of thing.

... And finally

I've probably left out no end of stuff that others consider important, but the steps above should at least help you start sorting things out if you are unlucky enough to fall victim to hackers.

Above all: Don't panic. Think before you act. Act firmly once you've made a decision, and leave a comment below if you have something to add to my list of steps.

It sounds like are in slightly over your head; that's ok. Call your boss and start negotiating for an emergency security response budget. $10,000 might be a good place to start. Then you need to get somebody (a PFY, a coworker, a manager) to start calling companies that specialize in security incident response. Many can respond within 24 hours, and sometimes even faster if they have an office in your city.

You also need somebody to triage customers; Doubtless, somebody already is. Somebody needs to be on the phone with them to explain what is going on, what is being done to handle the situation, and to answer their questions.

Then, you need to...

1. Stay calm. If you are in charge of incident response, what you do now needs to demonstrate the utmost professionalism and leadership. Document everything you do, and keep your manager and executive team apprised of major actions you take; this includes working with a response team, disabling servers, backing up data, and bringing things online again. They don't need gory details, but they should hear from you every 30 minutes or so.

2. Be realistic. You aren't a security professional, and there are things you don't know. That's ok. When logging in to servers and looking at data, you need to understand your limits. Tread gently. In the course of your investigation, make sure you don't stomp on vital information or change something that might be needed later. If you feel uncomfortable or that you are guessing, that's a good place to stop and get an experienced professional to take over.

3. Get a clean USB stick and spare hard drives. You will collect evidence here. Make backups of everything you feel may be relevant; communication with your ISP, network dumps, etc. Even if law enforcement doesn't get involved, in case of lawsuit you will want this evidence to prove that your company handled the security incident in a professional and appropriate manner.

4. Most important is to stop loss. Identify and cut off access to compromised services, data, and machines. Preferably, you should pull their network cable; if you cannot, then pull the power.

5. Next, you need to remove the attacker and close the hole(s). Presumably, the attacker no longer has interactive access because you pulled the network. You now need to identify, document (with backups, screenshots, and your own personal observational notes; or preferably even by removing the drives from the affected servers and making a full disk image copy), and then remove any code and processes he left behind. This next part will suck if you don't have backups; You can try to untangle the attacker from the system by hand, but you will never be sure that you got everything he left behind. Rootkits are vicious, and not all are detectable. The best response will be to identify the vulnerability he used to get in, make image copies of the affected disks, and then wipe the affected systems and reload from a known good backup. Don't blindly trust your backup; verify it! Repair or close the vulnerability before the new host goes on the network again, and then bring it online.

6. Organize all of your data into a report. At this point the vulnerability is closed and you have some time to breath. Don't be tempted to skip this step; it is even more important than the rest of the process. In the report, you need to identify what went wrong, how your team responded, and the steps you are taking to prevent this incident from occurring again. Be as detailed as you can; this isn't just for you, but for your management and as a defense in a potential lawsuit.

That's a sky-high review of what to do; most of the work is simply documentation and backup handling. Don't panic, you can do that stuff. I strongly recommend you get professional security help. Even if you can handle what's going on, their help will be invaluable and they usually come with equipment to make the process easier and faster. If your boss balks at the cost, remind him that it's very small when compared to handling a lawsuit.

You have my consolations for your situation. Good luck.

CERT tem um documento Steps for Recovering from a UNIX or NT System Compromise que é bom. Os detalhes técnicos específicos deste documento estão um pouco desatualizados, mas muitos dos conselhos gerais ainda se aplicam diretamente.

Um resumo rápido dos passos básicos é este.

• Consulte sua política ou gerenciamento de segurança.
• Obtenha o controle (coloque o computador offline)
• Analise a intrusão, obtenha logs, descubra o que deu errado
• Reparar coisas
  • Instale uma versão limpa do seu sistema operacional!!! Se o sistema foi comprometido, você não pode confiar nele, ponto final.
• Atualize os sistemas para que isso não aconteça novamente
• Retomar operações
• Atualize sua política para o futuro e documente

Eu gostaria de apontar especificamente para a seção E.1.

E.1. Lembre-se de que, se uma máquina estiver comprometida, qualquer coisa nesse sistema pode ter sido modificada, incluindo o kernel, binários, arquivos de dados, processos em execução e memória. Em geral, a única maneira de confiar que uma máquina está livre de backdoors e modificações de intrusos é reinstalar o sistema operacional.

Se você não tiver um sistema já instalado como o tripwire, não há como ter 100% de certeza de que limpou o sistema.

1. Identify the problem. Read the logs.
2. Contain. You've disconnected the server, so that's done.
3. Eradicate. Reinstall the affected system, most likely. Don't erase the hard drive of the hacked one though, use a new one. It's safer, and you might need the old one to recover ugly hacks that weren't backed up, and to do forensics to find out what happened.
4. Recover. Install whatever's needed and recover backups to get your clients online.
5. Follow-up. Figure out what was the problem, and prevent it from happening again.

Robert's "bitter pill" answer is spot-on but completely generic (well, as was your question). It does sound like you have a management problem and in dire need of a full-time sysadmin if you have one server and 600 clients but that doesn't help you now.

I run a hosting company which provides a bit of hand-holding in this situation, so I deal with lots of compromised machines, but also deal in best practice for our own. We always tell our compromised clients to rebuild unless they're not absolutely sure of the nature of a compromise. There is no other responsible route in the long term.

However, you are almost certainly just the victim of a script kiddy who wanted a launching pad for DoS attacks, or IRC bouncers, or something completely unrelated to your customers' sites and data. Therefore as a temporary measure while you rebuild, you might consider the bringing up a heavy outbound firewall on your box. If you can block all outbound UDP and TCP connections that aren't absolutely necessary for your sites' functioning, you can easily make your compromised box useless to whoever is borrowing it from you, and mitigate the effect on your provider's network to zero.

This process might take a few hours if you've not done it before, and have never considered a firewall, but might help you restore your clients service at the risk of continuing to give the attacker access to your clients data. Since you say that you have hundreds of clients on one machine, I'm guessing that you're hosting small brochure web sites for small businesses, and not 600 ecommerce systems full of credit card numbers. If that's the case this may be an acceptable risk for you, and get your system back online faster than auditing 600 sites for security bugs before you bring anything back. But you will know what data is there, and how comfortable you would be taking that decision.

This is absolutely not best practice, but if that's not what has been happening at your employer so far, wagging your finger at them and asking for tens of thousands of pounds for a SWAT team for something they might feel is your fault (however unjustified!) doesn't sound like the practical option.

Your ISP's help here is going to be pretty crucial - some ISPs provide a console server and network boot environment (plug, but at least you know what kind of facility to look for) which will let you administer the server while disconnected from the network. If this is at all an option, ask for it and use it.

But in the long term you should plan on a system rebuild based on Robert's post and an audit of each site and its setup. If you can't get a sysadmin added to your team, look for a managed hosting deal where you pay your ISP for sysadminning help and 24-hour response for this kind of thing. Good luck :)

Você precisa reinstalar. Salve o que você realmente precisa. Mas lembre-se de que todos os seus arquivos executáveis ​​podem estar infectados e adulterados. Eu escrevi o seguinte em python: http://frw.se/monty.py que cria MD5-sumbs de todos os seus arquivos em um determinado diretório e na próxima vez que você executá-lo, ele verifica se alguma coisa foi alterada e, em seguida, gera o que arquivos alterados e o que mudou nos arquivos.

Isso pode ser útil para você, para ver se arquivos estranhos são alterados regularmente.

Mas a única coisa que você deve fazer agora é remover seu computador da internet.

NOTE: This is not a recommendation. My specific Incident Response protocol probably would not does not apply unmodified to Grant unwin's case.

In our academic facilities we have about 300 researchers who only do computation. You have 600 clients with websites so your protocol will probably be different.

The first steps in our When a Server Gets Compromised Protocol is:

1. Identify that the attacker was able to gain root (elevated privileges)
2. Unplug the affected server(s). Network or power? Please see a separate discussion.
3. Check all other systems
4. Boot the affected server(s) from a live cd
5. (optional) Grab the images of all system drives with dd

6. Start doing the post-mortem forensics. Look at logs, figure out the time of the attack, find files that were modified on that time. Try to answer the How? question.

   • In parallel, plan and execute your recovery.
   • Reset all root and user passwords before resuming the service

Even if "all backdoors and rootkits are cleaned-up", don't trust that system - re-install from scratch.

Na minha experiência limitada, os comprometimentos do sistema no Linux tendem a ser mais 'abrangentes' do que no Windows. É muito mais provável que os rootkits incluam a substituição de binários do sistema por código personalizado para ocultar o malware, e a barreira para o hot-patch do kernel é um pouco menor. Além disso, é o sistema operacional doméstico para muitos autores de malware. A orientação geral é sempre reconstruir o servidor afetado do zero e é a orientação geral por um motivo.

Formate esse cachorrinho.

Mas, se você não pode reconstruir (ou os poderes constituídos não o deixarão reconstruí-lo contra sua insistência extenuante de que ele precisa), o que você procura?

Como parece que já faz um tempo desde que a invasão foi descoberta e uma restauração do sistema foi feita, é muito provável que os vestígios de como eles entraram tenham sido pisoteados na debandada para restaurar o serviço. Infeliz.

O tráfego de rede incomum é provavelmente o mais fácil de encontrar, pois isso não envolve a execução de nada na caixa e pode ser feito enquanto o servidor está ativo e fazendo qualquer coisa. Presumindo, é claro, que seu equipamento de rede permita a expansão de portas. O que você encontra pode ou não ser diagnóstico, mas pelo menos é informação. Obter tráfego incomum será uma forte evidência de que o sistema ainda está comprometido e precisa ser nivelado. Pode ser bom o suficiente para convencer o TPTB de que uma reformatação realmente vale o tempo de inatividade.

Caso contrário, faça uma cópia dd das partições do seu sistema e monte-as em outra caixa. Comece a comparar o conteúdo com um servidor no mesmo nível de patch que o comprometido. Ele deve ajudá-lo a identificar o que parece diferente (aqueles md5sums novamente) e pode apontar para áreas negligenciadas no servidor comprometido. Esta é uma grande peneiração através de diretórios e binários, e será bastante trabalhoso. Pode até ser mais trabalhoso do que uma reformatação/reconstrução seria, e pode ser outra coisa para acertar o TPTB sobre realmente fazer a reformatação de que realmente precisa.

I'd say @Robert Moir, @Aleksandr Levchuk, @blueben and @Matthew Bloch are all pretty much spot-on in their responses.

However, the answers of different posters differ - some are more on a high-level and talk about what procedures you should have in place (in general).

I'd prefer to separate this out into several separate parts 1) Triage, AKA How to deal with the customers and the legal implications, and identify where to go from there (Listed very well by Robert and @blueben 2) Mitigation of impact 3) Incident response 4) Post-mortem forensics 5) Remediation items and architecture changes

(Insert boilerplate SANS GSC certified response statement here) Based on past experiences, I'd say the following:

Regardless of how you are handling the customer responses, notifications, legal, and future plans, I'd prefer to focus on the main issue at hand. The original question of the OP really only pertains directly to #2 and #3, basically, how to stop the attack, get customers back online ASAP in their original state, which has been well covered in responses.

The rest of the responses are great and cover a lot of identified best-practices and ways to both prevent it from happening in the future as well as better respond to it.

It really depends on the budget of the OP and what sector of industry they are in, what their desired solution is etc.

Maybe they need to hire a dedicated onsite SA. Maybe they need a security person. Or maybe they need a fully managed solution such as Firehost or Rackspace Managed, Softlayer, ServePath etc.

It really depends on what works for their business. Maybe their core competency isn't in server management and it doesn't make sense for them to try to develop that. Or, maybe they are a pretty technical organization already and can make the right hiring decisions and bring on a dedicated team fulltime.

After getting to work and taking a look at the server we managed to figure out the problem. Luckily, the offending files were uploaded to the system on a Sunday, when the office is closed and no files should be created, apart from logs and cache files. With a simple shell command to find out which files have been created on that day we found them.

All the offending files seem to have been within the /images/ folder on some of our older zencart sites. It seems there was a security vulnerability that allowed (using curl) any idiot to upload non-images into the image upload section in the admin section. We deleted the offending .php files, and fixed the upload scripts to dissallow any file uploads that aren't images.

In retrospect, it was quite simple and I raised this question on my iPhone on the way into work. Thank you for all your help guys.

For the reference of anyone that visits this post in the future. I would not recommend pulling the power plug.