Sem querer achei isso no Twitter há pouco.
A ideia é interessante. Trata-se de um Live DVD GNU/Linux com várias falhas de segurança, permitindo ataques diversos, como SQL injection e buffer overflow. Apesar de ser um Live DVD, o DVL pode rodar a partir de sistemas de máquinas virtuais ou ser instalado em um desktop ou pendrive.
Segundo o líder do projeto, Dr. Thorsten Schneider, a distro de janeiro de 2009 e em processo de atualização, serve como um sistema de treinamento e aprendizado que ele usa para ensinar segurança para universitários. O ISO da mídia tem 1.8 GB e contém versões antigas do Apache, MySQL, PHP, FTP e SSH. O DVD é desenvolvido por algumas pessoas com conhecimentos do tipo “black hat” e já teve mais de 500.000 downloads.
Em virtude da grande quantidade de downloads, atualmente, o DVL só está disponível via torrent.
Essa é uma dica para quem quer montar um laboratório para aprender sobre segurança, principalmente em uma rede interna e controlada. Mas cuidado: não disponibilize uma máquina vulnerável na Internet sem saber o que está fazendo ou usando um computador com dados e documentos pessoais. Você poderá perder todos os seus arquivos.
O site do DVL é http://www.damnvulnerablelinux.org.
Adendo em 22 ago. 2010, às 18:20h:
O DVL é baseado no SLAX.
Tags:cracker, defacement, firewall, forense, Forense computacional, hacker, intrusão, invasão, Linux, Rede, redes, Segurança
Posted by Eriberto on ago 17, 2010 in
Debian,
Eventos,
Forense computacional,
Linux,
Microsoft,
Palestras,
Recuperação em desastres,
Rede,
Segurança,
Sistema Operacional,
Windows 17 ago. 2010 – 16:45 h
Estou ralando aqui para fazer os guias de consulta rápida para a minha oficina de forense amanhã no Consegi. Acabo de terminar o primeiro. É muita coisa. Então, terei que dividir em duas partes. Assim sendo, o guia Perícia Linux com Debian GNU/Linux – Parte 1: Procedimentos iniciais e coletas está disponível em http://eriberto.pro.br/forense.
Assim que eu tiver novidades, possivelmente hoje ainda, posto aqui e no meu Twitter.
17 ago. 2010 – 22:51 h
Ok, disponibilizado no mesmo site o o guia Perícia Linux com Debian GNU/Linux – Parte 2: Análise de evidências e laudo.
Agora só faltam os slides atualizados.
17 ago. 2010 – 23:31 h
Palestra atualizada e disponível em http://www.eriberto.pro.br/palestras. The end.
Até amanhã no Consegi! E obrigado à organização do evento pelo convite.
Tags:computador, forense, Forense computacional, guia, Linux, Rede, redes, Segurança
Posted by Eriberto on ago 16, 2010 in
Curiosidades,
Debian,
Sistema Operacional A maior distribuição GNU/Linux do mundo completa hoje 17 anos de existência.
O Debian foi criado por Ian Murdock em 16 de agosto de 1993 e, atualmente, é a segunda distro mais antiga existente no mundo. A mais antiga é o Slackware, que é um mês mais velho que o Debian (16 de julho de 1993).
Se você visitar qualquer bug report do Debian no dia de hoje (em http://bugs.debian.org), verá balões, como mostrado abaixo:
Também há um site comemorativo, disponível em http://thank.debian.net, onde as pessoas podem deixar mensagens para o Debian.
Parabéns ao Debian, o maior projeto de Software Livre do planeta e o perfeito exemplo de trabalho em comunidade!
Tags:16 de agosto de 1993, 16/08/93, 17 anos, 1993, aniversário, Aniversário Debian, Debian, Linux, Squeeze
Bem, isso quer dizer que em poucos meses teremos um novo Debian.
Confiram em http://www.debian.org/News/2010/20100806 .
Mas continuem acompanhando as novidades no post anterior. Hoje é sexta-feira e deve ter invasão.
[]s!
Tags:6.0, Debian, Debian Squeeze, freeze, frozen, Squeeze
Povo de Deus, Novamente temos uma máquina no ar, desde 18:40h, realizando a mesma tarefa descrita no post “Assistindo a uma invasão de rede de camarote…“. A diferença é que, desta vez, pretendo disponibilizar o dump de memória e já estou escrevendo um wiki que ensina preparar o mesmo ambiente que eu fiz. Agora é esperar os acontecimentos…
Dia 03 ago. 2010
18:40 h
Dia 04 ago. 2010
06:26 h
- Até agora o samhain não enviou qualquer mensagem. Tudo calmo. Isso pode ocorrer pelo fato do meu range de IPs talvez não ter sido scaneado pelos robôs (bots) da Internet ainda. Daqui a pouco estarei junto à máquina e direi o que ocorreu em termos de tráfego de rede. Não quero entrar nela para olhar. Vai contaminar o ambiente. Mas é fato que algo vai ocorrer. Mesmo que demore dias. Vamos esperar como se fôssemos pescadores…
06:35 h
- Opa! Nova análise. Entrei na máquina base, remotamente (isso não contamina a real) e vi, nas gravações tcpdump, que houve movimento ssh a partir das 22:35 h. Então, o samhain não acusou nada ou porque foi morto com kill -9 ou porque não houve alterações na máquina. Vou tentar colher agora o log /var/log/auth.log por scp para dar uma olhada sem contaminar muito a máquina.
- Colhi o log. A senha ainda é a mesma. Vejam:
Aug 4 00:01:29 server sshd[1141]: Invalid user Benutzer from 98.173.22.178
- Na linha anterior já houve uma tentativa de entrada a partir dos USA. Esse camarada fez tentativas até as 00:11 h mas não chegou a entrar. Foram 32 tentativas em cerca de 10 minutos. Depois veio:
Aug 4 02:29:12 server sshd[1511]: Failed password for root from 61.129.86.186 port 65487 ssh2
- Agora veio da China. Foram 5 tentativas em 1 minuto mas também não entrou. Vamos aguardar. O que acontecerá durante o dia?
09:10 h
- Já no local onde está a máquina. Acabo de fazer um dump de memória, externamente, via Xen. Analisei os logs (dentro da memória) e não há novidades. O samhain também permanece quieto. Sabemos que agora é noite no hemisfério oriental e daqui a pouco será madrugada. Talvez algo ocorra. Mas um fato marcante é que ainda não houve um ataque ssh de força bruta (do tipo tentativa em massa de logins) por nenhum bot. Temos que esperar…
09:40 h
- Estou notando no Iptraf que está rodando na máquina real a ocorrência de alguns pings (ICMP Echo Request). Assim, acabo de fazer um levantamento disso no arquivo que está sendo gravado pelo tcpdump. O resultado (mostrando somente até o IP de origem):
2010-08-03 19:11:45.040983 IP 220.76.200.59
2010-08-03 19:11:45.365377 IP 220.76.200.59
2010-08-03 19:14:49.230188 IP 192.168.100.20
2010-08-03 19:22:17.485984 IP 200.252.13.18
2010-08-03 19:27:26.205297 IP 60.195.124.238
2010-08-03 19:27:26.601530 IP 60.195.124.238
2010-08-03 20:22:20.046507 IP 189.107.24.115
2010-08-03 21:31:46.417342 IP 200.252.61.5
2010-08-03 23:06:29.001721 IP 200.252.67.194
2010-08-03 23:39:52.022671 IP 200.252.59.194
2010-08-04 01:01:48.582544 IP 200.252.55.9
2010-08-04 01:06:26.379342 IP 200.252.16.180
2010-08-04 03:39:29.641986 IP 61.251.176.29
2010-08-04 03:39:30.015736 IP 61.251.176.29
2010-08-04 06:09:36.519864 IP 68.169.176.89
2010-08-04 06:09:36.683012 IP 68.169.176.89
2010-08-04 06:41:36.830823 IP 80.183.103.193
2010-08-04 06:41:37.136954 IP 80.183.103.193
2010-08-04 07:33:28.368651 IP 200.252.76.101
2010-08-04 08:31:13.581548 IP 119.175.16.243
2010-08-04 08:31:13.947929 IP 119.175.16.243
2010-08-04 09:21:37.754272 IP 63.81.251.30
2010-08-04 09:21:39.806937 IP 63.81.251.30
2010-08-04 09:31:37.037950 IP 200.252.130.65
10:20 h
- Só para ter uma ideia de máquinas Windows com vírus ou coisas correlatas, decidi ver os TCP resets emitidos. Veja a listagem até agora:
2010-08-03 19:04:33.674752 IP 201.240.72.50.3126 > x.x.x.x.23: [S]
2010-08-03 19:04:33.674884 IP x.x.x.x.23 > 201.240.72.50.3126: [R.]
2010-08-03 19:04:48.592490 IP 41.145.25.77.4688 > x.x.x.x.23: [S]
2010-08-03 19:04:48.592607 IP x.x.x.x.23 > 41.145.25.77.4688: [R.]
2010-08-03 19:22:17.514418 IP 200.252.13.18.1070 > x.x.x.x.445: [S]
2010-08-03 19:22:17.514532 IP x.x.x.x.445 > 200.252.13.18.1070: [R.]
2010-08-03 19:22:17.514664 IP 200.252.13.18.63371 > x.x.x.x.139: [S]
2010-08-03 19:22:17.514775 IP x.x.x.x.139 > 200.252.13.18.1071: [R.]
2010-08-03 19:22:17.514800 IP x.x.x.x.139 > 200.252.13.18.63371: [R.]
2010-08-03 19:22:17.859811 IP 200.252.13.18.63371 > x.x.x.x.139: [S]
2010-08-03 19:22:17.859922 IP x.x.x.x.139 > 200.252.13.18.1071: [R.]
2010-08-03 19:22:17.859949 IP x.x.x.x.139 > 200.252.13.18.63371: [R.]
2010-08-03 19:22:17.875350 IP 200.252.13.18.1070 > x.x.x.x.445: [S]
2010-08-03 19:22:17.875465 IP x.x.x.x.445 > 200.252.13.18.1070: [R.]
2010-08-03 19:22:18.406396 IP 200.252.13.18.1071 > x.x.x.x.139: [S]
2010-08-03 19:22:18.406510 IP x.x.x.x.139 > 200.252.13.18.1071: [R.]
2010-08-03 19:22:18.422025 IP 200.252.13.18.63371 > x.x.x.x.139: [S]
2010-08-03 19:22:18.422162 IP x.x.x.x.139 > 200.252.13.18.63371: [R.]
2010-08-03 19:22:18.531637 IP 200.252.13.18.1070 > x.x.x.x.445: [S]
2010-08-03 19:22:18.531859 IP x.x.x.x.445 > 200.252.13.18.1070: [R.]
2010-08-03 19:27:26.990938 IP 60.195.124.238.53364 > x.x.x.x.139: [S]
2010-08-03 19:27:26.991057 IP x.x.x.x.139 > 60.195.124.238.53364: [R.]
2010-08-03 19:27:27.806026 IP 60.195.124.238.53364 > x.x.x.x.139: [S]
2010-08-03 19:27:27.806141 IP x.x.x.x.139 > 60.195.124.238.53364: [R.]
2010-08-03 19:27:28.607119 IP 60.195.124.238.53364 > x.x.x.x.139: [S]
2010-08-03 19:27:28.607214 IP x.x.x.x.139 > 60.195.124.238.53364: [R.]
2010-08-03 19:27:32.993421 IP 60.195.124.238.53995 > x.x.x.x.445: [S]
2010-08-03 19:27:32.993537 IP x.x.x.x.445 > 60.195.124.238.53995: [R.]
2010-08-03 19:27:35.917854 IP 60.195.124.238.53995 > x.x.x.x.445: [S]
2010-08-03 19:27:35.917967 IP x.x.x.x.445 > 60.195.124.238.53995: [R.]
2010-08-03 20:22:20.266544 IP 189.107.24.115.12602 > x.x.x.x.445: [S]
2010-08-03 20:22:20.266697 IP x.x.x.x.445 > 189.107.24.115.12602: [R.]
2010-08-03 20:22:20.731732 IP 189.107.24.115.12602 > x.x.x.x.445: [S]
2010-08-03 20:22:20.731973 IP x.x.x.x.445 > 189.107.24.115.12602: [R.]
2010-08-03 20:22:21.273379 IP 189.107.24.115.12602 > x.x.x.x.445: [S]
2010-08-03 20:22:21.273526 IP x.x.x.x.445 > 189.107.24.115.12602: [R.]
2010-08-03 23:18:00.219049 IP 58.215.79.84.6000 > x.x.x.x.9415: [S]
2010-08-03 23:18:00.219959 IP x.x.x.x.9415 > 58.215.79.84.6000: [R.]
2010-08-03 23:31:53.948650 IP 218.175.146.176.2089 > x.x.x.x.445: [S]
2010-08-03 23:31:53.952306 IP x.x.x.x.445 > 218.175.146.176.2089: [R.]
2010-08-03 23:31:55.869555 IP 218.175.146.176.2089 > x.x.x.x.445: [S]
2010-08-03 23:31:55.869645 IP x.x.x.x.445 > 218.175.146.176.2089: [R.]
2010-08-03 23:36:48.848734 IP 200.32.172.184.3883 > x.x.x.x.445: [S]
2010-08-03 23:36:48.848844 IP x.x.x.x.445 > 200.32.172.184.3883: [R.]
2010-08-03 23:36:51.707795 IP 200.32.172.184.3883 > x.x.x.x.445: [S]
2010-08-03 23:36:51.707886 IP x.x.x.x.445 > 200.32.172.184.3883: [R.]
2010-08-03 23:39:52.264355 IP 200.252.59.194.1609 > x.x.x.x.445: [S]
2010-08-03 23:39:52.264458 IP x.x.x.x.445 > 200.252.59.194.1609: [R.]
2010-08-03 23:39:52.267255 IP 200.252.59.194.1610 > x.x.x.x.139: [S]
2010-08-03 23:39:52.267345 IP x.x.x.x.139 > 200.252.59.194.1610: [R.]
2010-08-03 23:39:52.821223 IP 200.252.59.194.1610 > x.x.x.x.139: [S]
2010-08-03 23:39:52.821315 IP x.x.x.x.139 > 200.252.59.194.1610: [R.]
2010-08-03 23:39:52.825174 IP 200.252.59.194.1609 > x.x.x.x.445: [S]
2010-08-03 23:39:52.825264 IP x.x.x.x.445 > 200.252.59.194.1609: [R.]
2010-08-03 23:39:53.604568 IP 200.252.59.194.1610 > x.x.x.x.139: [S]
2010-08-03 23:39:53.604734 IP x.x.x.x.445 > 200.252.59.194.1609: [R.]
2010-08-03 23:39:53.604761 IP x.x.x.x.139 > 200.252.59.194.1610: [R.]
2010-08-03 23:53:27.337014 IP 41.250.160.206.4127 > x.x.x.x.23: [S]
2010-08-03 23:53:27.340306 IP x.x.x.x.23 > 41.250.160.206.4127: [R.]
2010-08-03 23:58:38.434406 IP 222.186.25.143.6000 > x.x.x.x.9415: [S]
2010-08-03 23:58:38.434513 IP x.x.x.x.9415 > 222.186.25.143.6000: [R.]
2010-08-04 00:06:00.316734 IP 58.215.79.202.6000 > x.x.x.x.9415: [S]
2010-08-04 00:06:00.316832 IP x.x.x.x.9415 > 58.215.79.202.6000: [R.]
2010-08-04 00:08:21.859852 IP 196.204.141.8.3970 > x.x.x.x.1433: [S]
2010-08-04 00:08:21.859959 IP x.x.x.x.1433 > 196.204.141.8.3970: [R.]
2010-08-04 00:08:22.510285 IP 196.204.141.8.3970 > x.x.x.x.1433: [S]
2010-08-04 00:08:22.510378 IP x.x.x.x.1433 > 196.204.141.8.3970: [R.]
2010-08-04 00:08:23.275186 IP 196.204.141.8.3970 > x.x.x.x.1433: [S]
2010-08-04 00:08:23.275353 IP x.x.x.x.1433 > 196.204.141.8.3970: [R.]
2010-08-04 00:11:35.799521 IP 217.219.23.166.3094 > x.x.x.x.445: [S]
2010-08-04 00:11:35.799617 IP x.x.x.x.445 > 217.219.23.166.3094: [R.]
2010-08-04 00:47:12.982595 IP 218.56.160.61.2477 > x.x.x.x.4899: [S]
2010-08-04 00:47:12.984326 IP x.x.x.x.4899 > 218.56.160.61.2477: [R.]
2010-08-04 00:47:13.836599 IP 218.56.160.61.2477 > x.x.x.x.4899: [S]
2010-08-04 00:47:13.836691 IP x.x.x.x.4899 > 218.56.160.61.2477: [R.]
2010-08-04 00:47:14.643027 IP 218.56.160.61.2477 > x.x.x.x.4899: [S]
2010-08-04 00:47:14.643184 IP x.x.x.x.4899 > 218.56.160.61.2477: [R.]
2010-08-04 01:01:48.713103 IP 200.252.55.9.62558 > x.x.x.x.445: [S]
2010-08-04 01:01:48.713197 IP x.x.x.x.445 > 200.252.55.9.62558: [R.]
2010-08-04 01:01:48.714286 IP 200.252.55.9.62559 > x.x.x.x.139: [S]
2010-08-04 01:01:48.714401 IP x.x.x.x.139 > 200.252.55.9.62559: [R.]
2010-08-04 01:01:48.715810 IP 200.252.55.9.62560 > x.x.x.x.139: [S]
2010-08-04 01:01:48.715897 IP x.x.x.x.139 > 200.252.55.9.62560: [R.]
2010-08-04 01:01:49.190492 IP 200.252.55.9.62560 > x.x.x.x.139: [S]
2010-08-04 01:01:49.190583 IP x.x.x.x.139 > 200.252.55.9.62560: [R.]
2010-08-04 01:01:49.192387 IP 200.252.55.9.62558 > x.x.x.x.445: [S]
2010-08-04 01:01:49.192476 IP x.x.x.x.445 > 200.252.55.9.62558: [R.]
2010-08-04 01:01:49.737738 IP 200.252.55.9.62560 > x.x.x.x.139: [S]
2010-08-04 01:01:49.737840 IP x.x.x.x.139 > 200.252.55.9.62560: [R.]
2010-08-04 01:01:49.738908 IP 200.252.55.9.62558 > x.x.x.x.445: [S]
2010-08-04 01:01:49.739025 IP x.x.x.x.445 > 200.252.55.9.62558: [R.]
2010-08-04 01:01:51.597553 IP 200.252.55.9.62559 > x.x.x.x.139: [S]
2010-08-04 01:01:51.597643 IP x.x.x.x.139 > 200.252.55.9.62559: [R.]
2010-08-04 01:01:57.617015 IP 200.252.55.9.62559 > x.x.x.x.139: [S]
2010-08-04 01:01:57.617148 IP x.x.x.x.139 > 200.252.55.9.62559: [R.]
2010-08-04 01:06:32.120233 IP 200.252.16.180.20029 > x.x.x.x.445: [S]
2010-08-04 01:06:32.120327 IP x.x.x.x.445 > 200.252.16.180.20029: [R.]
2010-08-04 01:06:32.120595 IP 200.252.16.180.20030 > x.x.x.x.139: [S]
2010-08-04 01:06:32.120683 IP x.x.x.x.139 > 200.252.16.180.20030: [R.]
2010-08-04 01:06:32.671419 IP 200.252.16.180.20030 > x.x.x.x.139: [S]
2010-08-04 01:06:32.671509 IP x.x.x.x.139 > 200.252.16.180.20030: [R.]
2010-08-04 01:06:32.671920 IP 200.252.16.180.20029 > x.x.x.x.445: [S]
2010-08-04 01:06:32.672008 IP x.x.x.x.445 > 200.252.16.180.20029: [R.]
2010-08-04 01:06:33.108411 IP 200.252.16.180.20030 > x.x.x.x.139: [S]
2010-08-04 01:06:33.108526 IP x.x.x.x.139 > 200.252.16.180.20030: [R.]
2010-08-04 01:06:33.109059 IP 200.252.16.180.20029 > x.x.x.x.445: [S]
2010-08-04 01:06:33.109168 IP x.x.x.x.445 > 200.252.16.180.20029: [R.]
2010-08-04 02:13:04.460384 IP 58.57.9.44.6000 > x.x.x.x.3389: [S]
2010-08-04 02:13:04.460596 IP x.x.x.x.3389 > 58.57.9.44.6000: [R.]
2010-08-04 02:36:32.697229 IP 220.226.18.10.6000 > x.x.x.x.1433: [S]
2010-08-04 02:36:32.704499 IP x.x.x.x.1433 > 220.226.18.10.6000: [R.]
2010-08-04 03:16:03.154845 IP 59.94.130.220.9989 > x.x.x.x.139: [S]
2010-08-04 03:16:03.156371 IP x.x.x.x.139 > 59.94.130.220.9989: [R.]
2010-08-04 03:16:10.370418 IP 59.94.130.220.9989 > x.x.x.x.139: [S]
2010-08-04 03:16:10.370508 IP x.x.x.x.139 > 59.94.130.220.9989: [R.]
2010-08-04 03:39:30.377836 IP 61.251.176.29.3040 > x.x.x.x.139: [S]
2010-08-04 03:39:30.377930 IP x.x.x.x.139 > 61.251.176.29.3040: [R.]
2010-08-04 03:39:31.129670 IP 61.251.176.29.3040 > x.x.x.x.139: [S]
2010-08-04 03:39:31.129762 IP x.x.x.x.139 > 61.251.176.29.3040: [R.]
2010-08-04 03:39:32.016606 IP 61.251.176.29.3040 > x.x.x.x.139: [S]
2010-08-04 03:39:32.016710 IP x.x.x.x.139 > 61.251.176.29.3040: [R.]
2010-08-04 03:51:01.001740 IP 124.172.159.228.6000 > x.x.x.x.9415: [S]
2010-08-04 03:51:01.003497 IP x.x.x.x.9415 > 124.172.159.228.6000: [R.]
2010-08-04 03:56:48.153734 IP 74.208.197.77.4763 > x.x.x.x.5900: [S]
2010-08-04 03:56:48.156272 IP x.x.x.x.5900 > 74.208.197.77.4763: [R.]
2010-08-04 03:56:48.843364 IP 74.208.197.77.4763 > x.x.x.x.5900: [S]
2010-08-04 03:56:48.843457 IP x.x.x.x.5900 > 74.208.197.77.4763: [R.]
2010-08-04 03:56:49.389654 IP 74.208.197.77.4763 > x.x.x.x.5900: [S]
2010-08-04 03:56:49.389789 IP x.x.x.x.5900 > 74.208.197.77.4763: [R.]
2010-08-04 04:45:46.099151 IP 78.183.144.144.2131 > x.x.x.x.23: [S]
2010-08-04 04:45:46.100313 IP x.x.x.x.23 > 78.183.144.144.2131: [R.]
2010-08-04 05:10:18.061284 IP 118.168.134.220.1082 > x.x.x.x.3128: [S]
2010-08-04 05:10:18.063497 IP x.x.x.x.3128 > 118.168.134.220.1082: [R.]
2010-08-04 05:10:18.860405 IP 118.168.134.220.1082 > x.x.x.x.3128: [S]
2010-08-04 05:10:18.860497 IP x.x.x.x.3128 > 118.168.134.220.1082: [R.]
2010-08-04 05:10:19.727480 IP 118.168.134.220.1082 > x.x.x.x.3128: [S]
2010-08-04 05:10:19.727568 IP x.x.x.x.3128 > 118.168.134.220.1082: [R.]
2010-08-04 06:09:36.842784 IP 68.169.176.89.29467 > x.x.x.x.139: [S]
2010-08-04 06:09:36.842943 IP x.x.x.x.139 > 68.169.176.89.29467: [R.]
2010-08-04 06:09:37.489436 IP 68.169.176.89.29467 > x.x.x.x.139: [S]
2010-08-04 06:09:37.489527 IP x.x.x.x.139 > 68.169.176.89.29467: [R.]
2010-08-04 06:09:38.091033 IP 68.169.176.89.29467 > x.x.x.x.139: [S]
2010-08-04 06:09:38.091125 IP x.x.x.x.139 > 68.169.176.89.29467: [R.]
2010-08-04 06:09:42.849257 IP 68.169.176.89.30144 > x.x.x.x.445: [S]
2010-08-04 06:09:42.849350 IP x.x.x.x.445 > 68.169.176.89.30144: [R.]
2010-08-04 06:09:43.498862 IP 68.169.176.89.30144 > x.x.x.x.445: [S]
2010-08-04 06:09:43.498952 IP x.x.x.x.445 > 68.169.176.89.30144: [R.]
2010-08-04 06:09:44.097595 IP 68.169.176.89.30144 > x.x.x.x.445: [S]
2010-08-04 06:09:44.097685 IP x.x.x.x.445 > 68.169.176.89.30144: [R.]
2010-08-04 06:41:37.440980 IP 80.183.103.193.41973 > x.x.x.x.139: [S]
2010-08-04 06:41:37.441075 IP x.x.x.x.139 > 80.183.103.193.41973: [R.]
2010-08-04 06:41:38.250208 IP 80.183.103.193.41973 > x.x.x.x.139: [S]
2010-08-04 06:41:38.250299 IP x.x.x.x.139 > 80.183.103.193.41973: [R.]
2010-08-04 06:41:38.947670 IP 80.183.103.193.41973 > x.x.x.x.139: [S]
2010-08-04 06:41:38.947761 IP x.x.x.x.139 > 80.183.103.193.41973: [R.]
2010-08-04 06:41:43.441575 IP 80.183.103.193.42716 > x.x.x.x.445: [S]
2010-08-04 06:41:43.441665 IP x.x.x.x.445 > 80.183.103.193.42716: [R.]
2010-08-04 06:41:44.169465 IP 80.183.103.193.42716 > x.x.x.x.445: [S]
2010-08-04 06:41:44.169552 IP x.x.x.x.445 > 80.183.103.193.42716: [R.]
2010-08-04 06:41:44.962688 IP 80.183.103.193.42716 > x.x.x.x.445: [S]
2010-08-04 06:41:44.962779 IP x.x.x.x.445 > 80.183.103.193.42716: [R.]
2010-08-04 07:33:49.605152 IP 200.252.76.101.62341 > x.x.x.x.445: [S]
2010-08-04 07:33:49.605250 IP x.x.x.x.445 > 200.252.76.101.62341: [R.]
2010-08-04 07:33:49.605824 IP 200.252.76.101.62342 > x.x.x.x.139: [S]
2010-08-04 07:33:49.605911 IP x.x.x.x.139 > 200.252.76.101.62342: [R.]
2010-08-04 07:33:49.606176 IP 200.252.76.101.62343 > x.x.x.x.139: [S]
2010-08-04 07:33:49.606261 IP x.x.x.x.139 > 200.252.76.101.62343: [R.]
2010-08-04 07:33:50.086681 IP 200.252.76.101.62342 > x.x.x.x.139: [S]
2010-08-04 07:33:50.086772 IP x.x.x.x.139 > 200.252.76.101.62342: [R.]
2010-08-04 07:33:50.087365 IP 200.252.76.101.62341 > x.x.x.x.445: [S]
2010-08-04 07:33:50.087452 IP x.x.x.x.445 > 200.252.76.101.62341: [R.]
2010-08-04 07:33:50.524591 IP 200.252.76.101.62342 > x.x.x.x.139: [S]
2010-08-04 07:33:50.524759 IP x.x.x.x.139 > 200.252.76.101.62342: [R.]
2010-08-04 07:33:50.524975 IP 200.252.76.101.62341 > x.x.x.x.445: [S]
2010-08-04 07:33:50.525062 IP x.x.x.x.445 > 200.252.76.101.62341: [R.]
2010-08-04 07:33:52.604693 IP 200.252.76.101.62343 > x.x.x.x.139: [S]
2010-08-04 07:33:52.604849 IP x.x.x.x.139 > 200.252.76.101.62343: [R.]
2010-08-04 07:33:58.727620 IP 200.252.76.101.62343 > x.x.x.x.139: [S]
2010-08-04 07:33:58.727711 IP x.x.x.x.139 > 200.252.76.101.62343: [R.]
2010-08-04 08:27:13.087499 IP 122.226.223.134.6000 > x.x.x.x.9415: [S]
2010-08-04 08:27:13.088122 IP x.x.x.x.9415 > 122.226.223.134.6000: [R.]
- Ao analisar a listagem anterior, lembre-se de que na máquina só há as portas 22 e 80 abertas para fora.
- Estou atento ao samhaim e ao Iptraf. Vamos esperar novidades mais concretas. Assim que tiver algo, posto aqui.
10:40 h
- Novidades. Movimento intenso no Iptraf. É alguém do nosso querido Brasil atancando com vontade. IP 187.50.126.38. Tudo indica que vem de São Paulo (conclusão via traceroute interrompido pela metade e whois). Mas esse IP já apareceu antes. Assim que ele terminar, posto algo aqui. Acho que não demora.
10:53 h
- Parece que terminou. Fiz dumps de memória seguidos para verificar os logs lá por dentro. Foram 18 minutos de tentativas. Isso rendeu 353 tentativas. Veja a primeira e a última linha:
Aug 4 10:30:02 server sshd[2359]: Failed password for root from 187.50.126.38 port 43061 ssh2
…
Aug 4 10:48:11 server sshd[3095]: Failed password for root from 187.50.126.38 port 60030 ssh2
11:07 h
- Entrou! (num bom sentido)
- No post das 10:53 h eu estava procurando apenas por logins com falha. Mas, olhando com mais cuidado agora, veja:
Aug 4 10:30:10 server sshd[2366]: Accepted password for root from 187.50.126.38 port 43338 ssh2
- Ou seja: esse cara tem um bot e ainda não viu que o mesmo conseguiu coletar a senha de root correta. Com certeza, mais tarde, ele vai ver e atuar. Isso se não estiver acompanhando estes posts!
- O pior é que é um robô burro, porque conseguiu a senha no primeiro minuto e continuou tentando.
11:37 h
- Perguntas? Vão fazendo que eu vou olhando tráfego, memória etc. e vou respondendo.
12:35 h
14:06 h
Aug 4 14:03:01 server sshd[3383]: Did not receive identification string from 200.161.99.38
14:30 h
- Para o Paulo (veja lá em baixo nos comentários): uma foto do Iptraf em ação.
17:55 h
- Bem, foi uma tarde calma e serena. Podemos concluir algo até aqui: quartas-feiras são dias bem seguros. Ninguém nunca lhe atacará. Nem quem já tem a sua senha de root. Bom, de noite darei uma olhadinha na situação e, havendo novidades, informo aqui. T+
22:10 h
- Nenhuma novidade. Vou dormir. Amanhã voltarei a monitorar a situação. Vamos ver se acontece algo na madrugada. []s a todos!
Dia 05 ago. 2010
06:25 h
- Bom dia a todos! Há pouco o milagre da vida aconteceu novamente. Veio da China. Vejam:
Aug 5 05:36:29 server sshd[4743]: Failed password for root from 219.143.125.205 port 54497 ssh2
Aug 5 05:36:35 server sshd[4746]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.143.125.205 user=root
Aug 5 05:36:37 server sshd[4746]: Failed password for root from 219.143.125.205 port 54843 ssh2
Aug 5 05:36:42 server sshd[4748]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.143.125.205 user=root
Aug 5 05:36:45 server sshd[4748]: Failed password for root from 219.143.125.205 port 55161 ssh2
Aug 5 05:36:50 server sshd[4750]: Accepted password for root from 219.143.125.205 port 55493 ssh2
- Bem, até agora o samhain está quieto. Isso quer dizer que ele entrou mas nada fez de relevante. Então, como ainda está anoitecendo na China, creio que mais tarde as coisas irão esquentar. Vamos esperar mais uma vez… Mas o samhain está funcionando. Vejam o último log dele na memória:
INFO : [2010-08-05T04:46:15-0300] msg=<Checking>, path=</etc/samhain>
- Ele ainda não enviou nada porque a sua configuração default é enviar somente eventos do nível CRIT. Volto mais tarde com novas notícias.
11:05 h
- Bem, ninguém entrou efetivamente ainda. Mas vários fizeram scaneamento com nmap e similares. O nmap, no modo normal de operação (TCP scan), envia uma flag TCP Syn para a porta. Se ela responder com Syn/Ack é porque está aberta. Então, para evitar ser logado, o nmap envia um Rst para a porta.
- Até o presente momento, a nossa porta 22 recebeu 133 resets de 12 máquinas diferentes. A seguir, a lista das máquinas que fizeram isso (fora as máquinas que adotaram outros tipos de procedimentos):
61.129.86.186: CN, China
91.188.59.62: LV, Latvia
94.138.164.155: IT, Italy
95.0.85.118: TR, Turkey
98.173.22.178: US, United States
115.165.163.55: VN, Vietnam
123.150.196.38: CN, China
124.31.204.185: CN, China
187.50.126.38: BR, Brazil
200.161.99.38: BR, Brazil
202.201.14.252: CN, China
219.143.125.205: CN, China
20:45 h
- Boa noite pessoal. Não tivemos grandes novidades hoje. No entanto, mais uma máquina da China conseguiu o acesso à máquina. No entanto, não houve atuação da mesma, o que nos leva a crer que era mais um bot com um dono (ser humano) desatento. Veja:
Aug 5 13:44:00 server sshd[5578]: Accepted password for root from 61.164.108.149 port 51914 ssh2
- O bot scaneou a rede por 16 minutos, até obter êxito. Foram 115 tentativas até o sucesso.
- Será que a noite será promissora? Bem, se for, saberemos amanhã.
Dia 06 ago. 2010
09:30 h
- Bom dia a todos! Desculpem o atraso. As coisas estão meio complicadas. Muitos contratempos de vida… Mas vamos às notícias.
- Ontem, depois das 23 h, mais duas máquinas conseguiram obter a senha do root. Vejam:
Aug 5 23:09:58 server sshd[6635]: Accepted password for root from 209.195.11.34 port 36680 ssh2
Aug 5 23:28:10 server sshd[6686]: Accepted password for root from 95.104.114.44 port 20370 ssh2
- A máquina 209.195.11.34 (USA) fez 13 tentativas até chegar à senha. Foi cerca de 1 minuto de tentativas.
- A máquina 95.104.114.44 (Geórgia) foi mais interessante. Ela entrou de primeira. Tudo leva a crer que alguém já colheu a senha em algum bot e a divulgou ou, se não, fez uma ponte pela Geórgia. Ou, ainda, tinha feito uma ponte partindo da Geórgia e passando por outro lugar anteriormente.
- Bem, o fato é que podem até ter entrado e navegado lá dentro. Mas, até agora, ninguém modificou nada, pois o samhain acusaria. E ele ainda está no ar, operando normalmente. Vejam a última mensagem dele que colhi no dump de memória:
INFO : [2010-08-06T08:49:37-0300] msg=<Checking>, path=</var/run/utmp>
- No mais, hoje é sexta-feira, dia internacional da invasão. Será que rola hoje?
11:55 h
- Entraram! Estão conversando lá dentro conectados a IRC. Vou publicar a conversa já já.
12:03 h
- Estão procurando portas 22 abertas na rede 86.0.0.0/8 a partir da máquina. A máquina virou um bot!!!
12:28 h
12:50 h
- Desculpem o desaparecimento. Perdi um pouco do controle da rede. Começaram a usar toda a banda. Fiquei sem Internet para mim.
- Para corrigir o problema, fiz um HTB para controlar o tráfego. Referências: http://www.eriberto.pro.br/palestras/controle_trafego.pdf .
- Vou almoçar voando e já volto. Ah, estão scaneando portas 22 na rede 94.0.0.0/8!
13:25 h
- Finalmente um e-mail do samhain! Vejam:
[2010-08-06T12:50:08-0300] server.projirradiante.com.br
CRIT : [2010-08-06T12:49:55-0300] msg=<POLICY [ReadOnly] C–I—-T->, path=</etc/shadow>, inode_old=<13300>, inode_new=<17168>, dev_old=<202,1>, dev_new=<202,1>, ctime_old=<[2010-08-03T21:34:30]>, ctime_new=<[2010-08-06T14:51:17]>, mtime_old=<[2010-08-03T21:34:30]>, mtime_new=<[2010-08-06T14:51:17]>, chksum_old=<4E3A8F642C54E0ABD1310A03A7BEFA954DC4EBEBA6349BB5>, chksum_new=<A91AC2692A353AD96F399F994CAE602A575CA16149CDDC36>,
- O arquivo /etc/shadow foi modificado. Ou seja: ou trocaram a a senha de algum usuário ou adicionaram um usuário. Mas se tivessem adicionado um usuário, o arquivo /etc/passwd também teria sido alterado. Vamos conferir se há algum log no dump de memória:
# strings memoria.dd |grep passwd|grep root
Aug 6 11:51:17 server passwd[17395]: pam_unix(passwd:chauthtok): password changed for root
- Agora, realmente, não sei dizer se o horário interno da máquina foi modificado também. Os horários parecem ter uma defasagem de 1 hora.
- Vamos ver tudo o que ocorreu entre 11:40 e 11:59 (exceto evntos corriqueiros de cron):
# strings memoria.dd |grep "Aug 6 11:[45]"|grep -v CRON|sort -n
Aug 6 11:42:42 server crontab[17311]: (root) REPLACE (root)
Aug 6 11:42:42 server crontab[17313]: (root) LIST (root)
Aug 6 11:42:51 server crontab[17331]: (root) REPLACE (root)
Aug 6 11:42:51 server crontab[17332]: (root) LIST (root)
Aug 6 11:51:17 server passwd[17395]: pam_unix(passwd:chauthtok): password changed for root
- Ok! Bem, vamos em frente!
13:47 h
- As coisas aqui estão lentas. Muito tráfego e uso de CPU.
- Bem, eles já trocaram a senha de root, conectaram a chat, scanearam redes etc. Acho que está na hora de derrubar o server e disponibilizar a memória. O que acham? Respondam aqui…
14:52 h
- Terminado pessoal. Estavam fazendo ataques pesados e grande parte da memória foi tomada por listas de nomes de usuários e senhas (dicionários). Vou preparar tudo para download. Daqui a pouco estará disponível.
16:07 h – DOWNLOAD DA IMAGEM DA MEMÓRIA!
16:46
- Vai ser liberada a imagem do disco…
18:31 – DOWNLOAD DA IMAGEM DA PARTIÇÃO!
- Disponível a imagem da partição que continha a máquina virtual em http://www.eriberto.pro.br/forense/caso_03 (150 MBcomprimidos, 954 MB descomprimidos).
- Notem que foi utilizado swap em arquivo. Como a memória era pequena, muita coisa foi pagina em swap…
Dia 07 ago. 2010
08:10 h
10:45 h
- Bem, esqueci de dizer outra coisinha importante. É muita coisa pra lembrar… Este caso foi montado, dentre outras coisas, para a minha oficina do Consegi 2010 aqui em Brasília. Quem quiser ter um minicurso de forense basta se inscrever. Na verdade, não sei se ainda tem vaga.
- Também, já fui convidado mais uma vez para o Latinoware. Então, vou propor, dentre outras coisas, o mesmo minicurso para lá.
- E, no FISL 2011 (FISL12), acho que vou fazer uma forense ao vivo para o pessoal ver também. Já dei uma palestra de forense no FISL 2009. Mas, desta vez, não será palestra. Será pura ação!
Dia 09 ago. 2010
- Hoje um amigo me alertou sobre uma mensagem postada em um forum. Aqui está ela:
http://www.istf.com.br/vb/pericia-forense/14955-assistindo-uma-invasao-de-camarote-analise-forente.html
- Bem, acho que o pessoal lá no fórum não leu o post antes de comentar algo. Então, vamos lá:
- Como eu disse no post, precisava montar um caso para os meus alunos. Então, não posso fazer uma perícia completa porque, se não, estarei dando a resposta do problema a quem deverá passar alguns dias fazendo o exercício.
- Narrei o que vi para tornar interessante para quem acompanhava ao vivo. Mas não tive a menor intenção de periciar o caso enquanto narrava, pelo motivo já citado. Por isso, as informações morreram no que foi publicado.
- Quanto ao scaneamento de uma rede /8, eu estava observando tudo. Eu fiz dump de memória e vi os acontecimentos no Iptraf. Pode ser estranho um scaneamento /8 mas é incontestável. Então, com todo o respeito, afirmaram coisas com base no achismo.
- Marketing? Não tenho empresa e não faço qualquer serviço de forense para fora do Governo Federal. E fui convidado pelo Serpro, na época, para dar a palestra que eles citaram. Mais um furo de quem resolveu falar sem base…
- Bem, escrevi isso aqui como esclarecimento, uma vez que as informações postadas no referido fórum estão públicas na Internet. []s a todos.
Tags:cracker, forense, Forense computacional, hacker, intrusão defacement, invasão, Linux, Rede, redes, Segurança, ssh, tcpdump
Bem, estou montando alguns casos para aulas de forense computacional. Já fiz dois introdutórios, disponíveis em http://eriberto.pro.br/forense. Mas eu precisava de algo voltado para uma invasão em rede. Então, montei a isca.
Dia 30 jul. 10
16:00 h
Comecei a montar uma máquina com Debian Squeeze para servir de base para uma máquina virtual vulnerável (usando Xen 4). Depois, criei a máquina virtual. A máquina base (real) possui uma senha de root forte e só está com o serviço ssh rodando. A máquina virtual possui ssh com senha fácil para root e um usuário test com senha fácil também. Tem um servidor de páginas Apache, PHP5, tudo com configuração default e, o mais importante, um monitor samhain enviando mails, para a minha conta falsa no GMail, a cada ocorrência anormal.
17:00 h
A máquina virtual está pronta e operando na Internet. Está disfarçada em uma máquina de uma rede atacadista. É importante ressaltar que não houve qualquer tipo de divulgação a respeito das máquinas (real e virtual) e que não houve registro em DNS. Teoricamente, ninguém deveria chegar em tais máquinas, a não ser por scaneamento. Ou seja: quem chegar é bandido! A máquina virtual tem IP terminado por 131 e a real 132.
18:47 h
O samhain envia um e-mail dizendo, dentre outras coisas, que o arquivo /etc/shadow foi alterado às 18:42 h (21:42 UTC). Veja:
CRIT : [2010-07-30T18:47:18-0300] msg=<POLICY [ReadOnly] C-------T->, path=</etc/shadow>, ctime_old=<[2010-07-30T19:36:20]>, ctime_new=<[2010-07-30T21:42:17]>, mtime_old=<[2010-07-30T19:36:20]>, mtime_new=<[2010-07-30T21:42:17]>, chksum_old=<B48D594D9879AB0B364DEC764A1322BD08A6F07BB1729B31>, chksum_new=<A394EE8F4C333D45B50D74DCFC78D70AD8F18DE76082D7C3>
.
Nessa hora eu estava a caminho do shopping.
22:30 h
Cheguei do shopping e vi a mensagem do samhain. Batata! Não consigo mais logar no servidor como root. A senha foi trocada. Só tenho acesso à maquina real.
Na verdade, eu poderia tirar a virtual do ar e montá-la em um diretório para ver o seu conteúdo ou trocar a senha de root novamente. Mas, não é o caso. Preciso de um caso forense e vou deixar a máquina quieta por mais uns 2 ou 3 dias. Essa é a parte mais legal. Como perdi o acesso à máquina, só conhecerei um pedacinho da história. Então, terei que realmente fazer uma forense para descobrir tudo o que ocorreu. Um ponto chave será a memória. Até a senha de root (e outras) deve estar lá dentro.
A partir da máquina real, rodando IPtraf, constatei as seguintes situações:
- As máquinas 200.220.199.8 (Brasil) e 202.140.34.82 (Índia) conectadas por ssh.
- A máquina atacada está se conectando à porta 6667 da máquina 208.83.20.130. Ou seja: instalaram um cliente de IRC na máquina e conectaram.
- O site original do Apache continua intacto.
- Há um IP terminado por 182, na máquina atacada, conectando na porta 80 de 75.125.252.78. Ou seja: alguém levantou um novo IP e o está utilizando. Ao tentar entrar no site da 75.125.252.78, via browser local, recebi: Bad Request (Invalid Hostname).
.
Bem, coloquei um tcpdump, na máquina real, gravando tudo o que for ou vier da porta 6667 externa. O meu objetivo é logar alguma conversa de chat para descobrir o canal e o nick dos atacantes. Com isso, talvez eu consiga a senha de root. Vamos esperar. Também coloquei outro tcpdump rodando para logar tudo o que trafegar de/para 75.125.252.78.
Dia 31 jul. 10
00:53 h
A situação se mantém inalterada. Os dois atacantes continuam conectados. Mas as coisas estão meio paradas. Acho que foram dormir e deixaram as conexões estabelecidas para não as perderem. Faz sentido. Vou dormir também. Amanhã continuo. Boa noite para quem está acompanhado.
01:02 h
Opa! Em tempo! Alguém criou o IP final 180 e conectou na 80 de 221.232.247.43. Esse IP gera uma tela estranha no browser. O 200.220.199.8 se foi. Só resta o 202.140.34.82. Resolvi gravar todo o tráfego destinado a qualquer porta 80. Agora sim, vou dormir.
07:30 h
Alvorada!!! Fui ver a situação. Era a seguinte:
- Às 06:25 h o logrotate da máquina tentou atuar e não conseguiu, enviando o seguinte mail (desviado para o GMail):
/etc/cron.daily/logrotate:
error: error accessing /var/log/apache2: No such file or directory
error: apache2:1 glob failed for /var/log/apache2/*.log
error: found error in /var/log/apache2/*.log , skipping
error: error accessing /var/log/samhain: No such file or directory
error: samhain:1 glob failed for /var/log/samhain/*.log
error: found error in /var/log/samhain/*.log , skipping
- Ou seja: o diretório de logs foi apagado. Nisso já ficou óbvio que o Samhain foi retirado do ar… Mas o importante aconteceu: ele deu o primeiro alerta.
- O site original do Apache continua intacto.
- A senha de root permanece alterada e desconhecida para mim.
- Não houve tráfego na porta 80.
- No chat, porta 6667, foi capturado tráfego relevante e os atacantes falam em espanhol. Já sei qual é o canal. Neste momento, há 28 nicks logados no canal, dos quais, 19 são operadores.
- Foi criado um usuário oracle na máquina (vi isso pelo tráfego no chat).
- A máquina continua logada como cliente em 208.83.20.130:6667.
- Foi criada a porta 25 sobre o IP final 131. Então, instalaram um servidor de e-mail, provavelmente para fazer spam. Passei a logar também o tráfego de portas 25 na máquina real.
- A máquina 118.161.245.67 (Taiwan) está conectada na porta 25.
- A máquina 206.125.46.134 (USA) deu um Syn na 22 do IP final 131, recebeu um Syn-Ack e mandou um Rst. Está scaneando portas. Provavelmente Nmap. Observe que whois interessante:
AirlineReservations.Com, Inc. AIRLINERES-CALPOP-COM (NET-206-125-40-0-1) 206.125.40.0 - 206.125.47.255
LA Data Center CP-809973-001 (NET-206-125-46-128-1) 206.125.46.128 - 206.125.46.159
- Foi criada uma porta 3128 na máquina, sobre o IP final 180. Provavelmente, temos um proxy para esconder navegação na Internet.
- A máquina 118.168.138.210 (Taiwan) está conectada nessa porta.
- Hum… A máquina 113.213.248.181 (Japão) enviou um Syn para a porta 445 e recebeu um Rst. Porta fechada. O cara estava procurando portas abertas.
- Alguém fez uma conexão no socket 70.39.70.186 a partir do IP final 182. Um site de relógios?
- As máquinas 85.105.188.189 (Turquia), 94.28.207.39 (Russia) e 212.87.127.16 (Bélgica) tentaram um Syn na 23 do IP final 131 e receberam um Rst. Porta fechada.
08:50 h
- Só agora terminei a análise publicada no horário anterior.
- Há um novo canal no IRC. Este tem 42 nicks e 13 operadores. Mas parece ser um canal normal, não de hackers. Estão falando coisas banais e abertamente.
- Bem, estou satisfeito. Fizeram tudo o que eu queria. Até apagaram os logs. Hora de tirar o zumbi do ar. Vou tomar banho e vou retirar a máquina do ar. Antes vou fazer todos os procedimentos de coleta de dados de memória e máquina. Vou fazer o que está descrito na palestra de forense, disponível em http://eriberto.pro.br/palestras.
10:05 h
- Cheguei na cena do crime. Imediatamente, fiz o dump de memória. Como usei Xen, foi fácil:
# xm dump-core vm0-superatacado memoria.dd
- Colhi os dados essenciais na máquina ainda viva. Usei netcat para copiar os arquivos via rede. Agora posso fazer isso porque já colhi a memória. Um exemplo:
Máquina de destino: # netcat -l -p 53000 > free
Máquina de origem: # free -m | netcat <ip_de_destino> 53000
- A seguir, tirei a máquina virtual do ar usando o comando xm destroy, para evitar que ela gravasse algo no disco, superpondo dados.
- O último passo foi gerar uma imagem do disco, usando o dcfldd (veja este post).
Matando a sua curiosidade…
Apenas para matar a sua curiosidade, numa rápida investigação de memória, olha o que encontrei:
# strings memoria.dd |egrep "Accepted"|grep root|sort -n
Jul 30 18:01:06 superatacado sshd[1160]: Accepted password for root from 190.120.229.185 port 34031 ssh2
Jul 30 18:01:06 superatacado sshd[1160]: Accepted password for root from 190.120.229.185 port 34031 ssh2
Jul 30 18:05:42 superatacado sshd[1356]: Accepted password for root from 190.120.229.185 port 59465 ssh2
Jul 30 18:07:53 superatacado sshd[1579]: Accepted password for root from 189.235.242.88 port 49316 ssh2
Jul 30 18:08:55 superatacado sshd[1759]: Accepted password for root from 190.120.229.185 port 48439 ssh2
Jul 30 19:51:35 superatacado sshd[16537]: Accepted password for root from 189.235.242.88 port 49576 ssh2
- 190.120.229.185 – Panamá!
- 189.235.242.88 – México.
Outra:
# strings memoria.dd |egrep chauthtok|sort -n
Jul 30 18:24:25 superatacado passwd[5629]: pam_unix(passwd:chauthtok): password changed for test
Jul 30 18:42:17 superatacado passwd[8377]: pam_unix(passwd:chauthtok): password changed for root
Lembre-se: eles apagaram os logs e, depois, constatei que derubaram também os serviços syslogd e klogd. É por isso que só consegui colher esses dados na memória. Com certeza, haverá muita coisa sobre isso na superfície do disco também.
O fim
Bem, agora é trabalhar em cima das evidências. Vou fazer uma rápida forense para descobrir algumas coisas. Uma delas são as senhas utilizadas para root, sites etc. É bem possível que eu encontre isso na memória. No entanto, já decidi aperfeiçoar o processo. Isso quer dizer que, em breve, farei tudo novamente para ter um material melhor. Quero que seja um caso mais incrementado. Por exemplo: o dump de memória, mesmo comprimido, ficou muito grande. Tenho que trabalhar com uma memória menor para as pessoas poderem fazer download.
Mas valeu muito a experiência.
[]s!
Tags:cracker, forense, Forense computacional, hacker, intrusão defacement, invasão, Linux, Rede, redes, Segurança, ssh, tcpdump
Hoje, eu tentava debugar um problema em um servidor. Com o entra e sai da minha sala, telefone tocando, chefe trazendo documentos etc., enquanto reaproveitava uma linha anterior (tecla seta para cima), pensando ter dado um # ls /var/lib, na verdade, dei um # rm -rf /var/lib. Começou a saga…
Os primeiros sentimentos
A coisa começa num abstrato formato de p-q-p emanando no cérebro. Depois vem a necessidade de incorporar Airton Sena para ser bem rápido. Tratava-se do roteador de borda mas, como tudo estava na memória da máquina e ela não usava swap, havia uma enorme possibilidade da rede não cair enquanto eu agisse. Então, calma Eriberto. Você consegue!
O que é o /var/lib?
O /var/lib é um diretório essencial do sistema que contém, dentre outras coisas, a lista de pacotes instalados e parte do sistema APT. Sem ele, não tem apt-get. Então, no desespero, a primeira coisa que fiz foi dar um # apt-get update, para ver do que ele iria reclamar. Fui criando os diretórios não encontrados. Em determinado momento, um arquivo não foi encontrado. Com o comando touch, criei um arquivo vazio com o nome solicitado. No fim, o APT funcionou (apt-cache e apt-get). Mas tinha algo ruim… A base do sistema é criada durante a instalação do Debian e eu não poderia refazê-la com perfeição a partir de um bando de apt-gets…
A nova solução
Bem, rapidamente pensei e resolvi criar e copiar uma estrutura básica de /var/lib para dentro da máquina. Poderia fazer essa cópia via rede, pois a máquina acidentada tinha ssh e rsync ativos. Então, em outra máquina, criei um Debian básico com debootstrap:
# mkdir /tmp/lenny
# debootstrap lenny /tmp/lenny http://ftp.us.debian.org/debian
A seguir, com rsync -av, copiei todo o conteúdo de /tmp/lenny/var/lib/ para dentro do /var/lib da acidentada. Ufa! Estrutura básica montada. Agora, na base de dados do APT (e dpkg), que fica em /var/lib, só existiam os pacotes básicos . Em outras palavras, para o Debian, ele era um recém-nascido. Assim, eu precisava reinstalar todos os pacotes preexistentes. Mas eu não tinha uma lista de pacotes instalados. Agora sei que é importante ter uma relação gerada com dpkg -l dentro do meu backup. Vou implementar isso.
Para descobrir os pacotes necessários, segui a seguinte ordem:
- Inicialmente, para garantir que a lista de pacotes instalados vinda da outra máquina (dentro do conteúdo do /var/lib) estava batendo, mandei o sistema reinstalar cada um dos pacotes listados. Escrevi a seguinte linha para fazer isso:
# for i in $(dpkg -l|grep ^ii|cut -d" " -f3); do apt-get install --reinstall -y $i; done
- Depois, instalei os pacotes básicos, que sempre instalo, como mc, rcconf, less, ntpdate, tcpdump etc.
- Instalei o kernel, pois esse é o mais básico. Usei o linux-image-2.6-686.
- Fiz um # netstat -tunlp para ver os serviços que estavam rodando. Esses são muito importantes, porque podem vir a ter falha de segurança um dia e precisam estar na base de dados do APT para poderem ser atualizados.
- Semelhante ao passo anterior, com base no conteúdo de /etc/init.d, instalei pacotes. Para isso, escrevi a seguinte linha:
# for i in $(ls /etc/init.d); do echo -e '\n' $i; apt-get install $i; done
- Depois de reinstalar o daemons com base no /etc/init.d, fiz um novo # netstat -tunlp para ver se não havia algum serviço de rede indesejado no ar. A seguir, outra verificação, agora incluindo os serviços locais, com # ps ax.
- Agora, o grande final. Eu precisava reinstalar todos os pacotes que tivessem nomes de executáveis, exceto o que eu já tinha instalado. A solução:
# for i in $(ls /bin; ls /sbin; ls /usr/bin; ls /usr/sbin); do echo -e '\n' $i; apt-get install $i; done
- Com a linha anterior, alguns pacotes foram instalados, outros dados como já instalados e vários nomes dados como não existentes. Houve mensagens citando pacotes virtuais e substitutos. Assim, depois de tudo feito, rodei novamente o comando com um egrep mágico e um 2> para desviar erros para o lixo. Veja:
# for i in $(ls /bin; ls /sbin; ls /usr/bin; ls /usr/sbin); do echo -e '\n' $i; apt-get install $i 2> /dev/null; done | egrep -A 5 -B 5 '(virtual|substituem|S\/n)'
- Nesta última linha eu obtive resultados que foram tratados um a um, individualmente.
Bem, foi isso. Espero que este post, um dia, ajude alguém.
Tags:Debian, desastres, Linux, pacote, pacotes
Hoje cedo, por volta das 06:30h, quando acabei de editar uma das duas palestras que vou ministrar aqui no FISL, postei no Twitter (http://twitter.com/eribertomota) que ia tentar dar um overview sobre as mesmas hoje no meu blog. Então, farei isso agora.
Ambas as palestras ocorrerão no dia 23 de julho de 2010 (amanhã). Uma será às 10h e a outra às 20h.
Palestra 1
Análise e controle de tráfego em redes TCP/IP com tcpdump
23 de julho, 10h, sala 41E (fisl 6)
Nesta palestra vou mostrar a importância dos gerentes de rede conhecerem protocolos, encapsulamentos e modelo OSI. Isso é essencial para quem precisa encontrar problemas que envolvem o bloqueio de tráfego ou mau funcionamento. Serão mostrados os conceitos básicos sobre IP, TCP, UDP e ICMP. Com a ferramenta tcpdump aplicada nos pontos corretos, será possível descobrir erros de configuração em roteadores, pontos de bloqueio em firewalls e até mesmo cabos com defeito.
Uma palestra ESSENCIAL para que administra uma rede. Vários tráfegos capturados com tcpdump serão exibidos e explicados. São tráfegos relativos aos problemas que ocorrem no dia-a-dia. Até mesmo mensagens ocultas emitidas por bancos de dados sobre problemas de conexão serão tratadas na palestra.
O sumário a ser utilizado:
- A análise de tráfego
- A estrutura de um protocolo
- O protocolo IP
- O protocolo TCP
- O protocolo UDP
- O protocolo ICMP
- O modelo OSI
- Técnica de uso do tcpdump na análise de tráfego
- Considerações finais
- Conclusão
Dois exemplos de ideias que serão tratadas:
- A ida de uma flag TCP Syn, seguido da volta de uma flag Rst, significa que a porta do servidor está fechada.
- Sabia que é sempre o cliente quem inicia uma conexãow
A palestra estará disponível para download, a partir das 23h de hoje, em http://www.eriberto.pro.br/palestras.
Palestra 2
Gerenciamento de memória virtual no Kernel Linux
23 de julho, 20h, sala 41C (fisl 3)
Esta palestra mostrará como funciona o sistema de gerenciamento de memória no Kernel Linux. Será tratado o esquema básico de funcionamento da memória virtual (RAM + Swap). Algumas experiências práticas mostrarão, ao vivo, a memória em ação.
É fato que grande parte dos usuários não sabem analisar o uso da memória. Isso já começa pela correta interpretação do resultado do comando free. Observe:
eriberto@cygnus:~$ free -m
total used free shared buffers cached
Mem: 2015 974 1040 0 53 632
-/+ buffers/cache: 288 1726
Swap: 399 0 399
No resultado anterior, qual o total de memória livre? Bem, garanto que não é 1040 MB. Mas para chegar ao resultado correto, é necessário saber conceitos como buffer-cache. Também serão abordados aspectos sobre o funcionamento do polêmico swap.
O sumário a ser utilizado:
- Modelo von Neumann
- Causas de esgotamento da memória RAM
- Memória virtual e uso do swap
- Sistema buffer-cache
- Gerência do uso de memória
- Tamanhos mínimos e máximo do swap
- Swap em arquivo versus swap em partição
- O mito dos 4 GB
- Ferramentas de análise de memória
- Conclusão
Dois exemplos de ideias que serão tratadas:
- Qual o tamanho ideal de swap? (não é o dobro da RAM)
- Sabia que um processador lento pode causar falta de memória?
A palestra já está disponível para download em http://www.eriberto.pro.br/palestras.
Tags:análise de tráfego, buffer, buffer-cache, cache, eriberto, FISL 11, FISL11, gerenciamento de memória, memória virtual, swap, tcpdump
Gostaria de deixar aqui a dica sobre o site do amigo Marcelo Lau, que é um renomado professor em algumas faculdades de São Paulo.
No seu site há diversos trabalhos acadêmicos, de alunos orientados por ele ou por outros professores conhecidos, sobre segurança e forense computacional. Vale a pena conferir, pois todo o material lá existente já foi avaliado pelo Lau. E o melhor: tem trabalhos escritos pelo próprio Lau. É muita coisa mesmo! Alguns exemplos:
- Técnicas Utilizadas para Efetivação e Contenção das fraudes sobre Internet Banking no Brasil e no Mundo.
- Perícia Forense Computacional – ataques, identificação da autoria, leis e medidas preventivas.
- A aceitação da prova eletrônica no âmbito criminal.
- Segurança em Dispositivos de Armazenamento Portáteis: um estudo dos riscos envolvendo os pendrives.
O site é http://www.datasecurity.com.br/usp.html.
Tags:apostilas, computador, cracker, data security, datasecurity, firewall, Forense computacional, hacker, Lau, Linux, Mrcelo Lau, Rede, redes, Segurança, trabalhos acadêmicos, Windows
Depois de algum tempo, o Xen 4 engrenou no Debian Squeeze sem tantos malabarismos. A mágica do APT-GET acontece novamente.
Depois de passar um dia ralando para fazer tudo funcionar e me adaptar aos novos dispositivos e malícias, escrevi um artigo no meu wiki sobre o assunto. Comecei no dia 15 de junho mas só tive tempo para terminar hoje. Assim sendo, para quem precisar, fica aqui a URL:
http://www.eriberto.pro.br/wiki/index.php?title=Xen_4.0_no_Debian_Squeeze
ou
http://tiny.cc/xen_squeeze
Tags:6.0, Debian, Dom0, DomU, Ext4, hvc0, Linux, máquina virtual, sistema operacional, SO, Squeeze, virtual machine, virtualização, VM, Xen, Xen 4, xvda1
