Mais um artigo publicado em mídia digital 🙂
Tem até a foto na Home de Segurança: http://convergecom.com.br/tiinside/seguranca/
19/01/2015
16/01/2015
Troubleshooting One Arm NAT
Esse post é dedicado aos colegas “retardados” que me trouxeram o caso.
Situação: Servidores da rede interna devem chegar a uma rede remota usando um NAT específico, isso seria trivial se o tráfego para a rede remota não fosse roteado pela mesma interface que chega o tráfego de origem, ou seja, o pacote deve entrar e sair pela mesma interface (caminho não ótimo, já que o servidor da rede local poderia enviar o pacote diretamente para o gateway usado pelo firewall para a rede remota, porém nesse caso isso não é possível já que não ocorreria o NAT nesse fluxo).
Topologia para facilitar a visualização:
Agora vamos ao que interessa, primeiro criamos uma regra liberando o tráfego da port2 para a port2, com os IPs de origem e destino adequados, após criar a regra e definir o NAT com IP Pool testamos com ping e não temos resposta, logo vamos ao debug sniffer:
FG01 # diag sniffer packet any 'host 192.168.10.63' interfaces=[any] filters=[host 192.168.10.63] 3.423153 192.168.10.63 -> 172.16.0.160: icmp: echo request 3.423189 192.168.10.63 -> 172.16.0.160: icmp: echo request 3.423266 192.168.10.7 -> 192.168.10.63: icmp: type-#5 4.427205 192.168.10.63 -> 172.16.0.160: icmp: echo request 4.427239 192.168.10.63 -> 172.16.0.160: icmp: echo request 4.427309 192.168.10.7 -> 192.168.10.63: icmp: type-#5 ... 9.984483 192.168.10.63.54077 -> 172.16.0.160.443: syn 2201610154 9.984565 192.168.10.63.54077 -> 172.16.0.160.443: syn 2201610154 9.984623 192.168.10.7 -> 192.168.10.63: icmp: type-#5
Na captura acima fiz dois testes, o primeiro com ping (icmp echo request) e o segundo com um telnet na porta 443 (https).
Note o pacote “estranho” icmp type 5, como alguns de vocês podem imaginar deve estar ocorrendo um ICMP redirect pois o FW está enviando o pacote para um gw na mesma rede que o host de origem.
Confirmando o que significa icmp type 5 a partir da fonte: RFC792
The gateway sends a redirect message to a host in the following
situation. A gateway, G1, receives an internet datagram from a
host on a network to which the gateway is attached. The gateway,
G1, checks its routing table and obtains the address of the next
gateway, G2, on the route to the datagram's internet destination
network, X. If G2 and the host identified by the internet source
address of the datagram are on the same network, a redirect
message is sent to the host. The redirect message advises the
host to send its traffic for network X directly to gateway G2 as
this is a shorter path to the destination. The gateway forwards
the original datagram's data to its internet destination.
Ok, a descrição acima bate com o esperado. Agora como resolver isso ?
Pesquisando no CLI Guide (http://docs.fortinet.com/d/fortigate-fortios-5.2-cli-reference) alguma coisa relacionada a ‘redirect’ achei o seguinte na página 484:
“Under some conditions, it is undesirable to have enable traffic routed back on the same interface. In that case, set allow-traffic-redirect to disable.”
Ou seja, exatamente a situação enfrentada, tráfego entra e sai pela mesma interface, vamos habilitar o comando:
config system global
set allow-traffic-redirect disable
end
Testamos:
FG01 # diag sniffer packet any 'port 443' interfaces=[any] filters=[port 443] 6.316107 192.168.10.63.47071 -> 172.16.0.160.443: syn 3467548287 6.316225 192.168.10.51.47071 -> 172.16.0.160.443: syn 3467548287 6.317751 172.16.0.160.443 -> 192.168.10.51.47071: syn 2754869133 ack 3467548288 6.317767 172.16.0.160.443 -> 192.168.10.63.47071: syn 2754869133 ack 3467548288 6.317994 192.168.10.63.47071 -> 172.16.0.160.443: ack 2754869134 6.318009 192.168.10.51.47071 -> 172.16.0.160.443: ack 2754869134 6.318276 192.168.10.63.47071 -> 172.16.0.160.443: fin 3467548288 ack 2754869134 6.318308 192.168.10.51.47071 -> 172.16.0.160.443: fin 3467548288 ack 2754869134 6.319294 172.16.0.160.443 -> 192.168.10.51.47071: fin 2754869134 ack 3467548289 6.319306 172.16.0.160.443 -> 192.168.10.63.47071: fin 2754869134 ack 3467548289 6.319517 192.168.10.63.47071 -> 172.16.0.160.443: ack 2754869135 6.319526 192.168.10.51.47071 -> 172.16.0.160.443: ack 2754869135
E observando o comportamento no diag debug flow:
2014-12-09 13:16:31 id=20085 trace_id=101 func=print_pkt_detail line=4373 msg="vd-root received a packet(proto=6, 192.168.10.63:58746->172.16.0.160:443) from port2. flag [S], seq 29096599, ack 0, win 14600" 2014-12-09 13:16:31 id=20085 trace_id=101 func=init_ip_session_common line=4522 msg="allocate a new session-0000027b" 2014-12-09 13:16:31 id=20085 trace_id=101 func=vf_ip4_route_input line=1596 msg="find a route: flags=01000000 gw-192.168.10.211 via port2" 2014-12-09 13:16:31 id=20085 trace_id=101 func=fw_forward_handler line=670 msg="Allowed by Policy-2: SNAT" 2014-12-09 13:16:31 id=20085 trace_id=101 func=__ip_session_run_tuple line=2520 msg="SNAT 192.168.10.63->192.168.10.51:58746" 2014-12-09 13:16:31 id=20085 trace_id=102 func=print_pkt_detail line=4373 msg="vd-root received a packet(proto=6, 192.168.10.63:58746->172.16.0.160:443) from port2. flag [.], seq 29096600, ack 612563040, win 7300" 2014-12-09 13:16:31 id=20085 trace_id=102 func=resolve_ip_tuple_fast line=4432 msg="Find an existing session, id-0000027b, original direction" 2014-12-09 13:16:31 id=20085 trace_id=102 func=__ip_session_run_tuple line=2520 msg="SNAT 192.168.10.63->192.168.10.51:58746" 2014-12-09 13:16:31 id=20085 trace_id=103 func=print_pkt_detail line=4373 msg="vd-root received a packet(proto=6, 192.168.10.63:58746->172.16.0.160:443) from port2. flag [F.], seq 29096600, ack 612563040, win 7300" 2014-12-09 13:16:31 id=20085 trace_id=103 func=resolve_ip_tuple_fast line=4432 msg="Find an existing session, id-0000027b, original direction" 2014-12-09 13:16:31 id=20085 trace_id=103 func=__ip_session_run_tuple line=2520 msg="SNAT 192.168.10.63->192.168.10.51:58746" 2014-12-09 13:16:31 id=20085 trace_id=104 func=print_pkt_detail line=4373 msg="vd-root received a packet(proto=6, 192.168.10.63:58746->172.16.0.160:443) from port2. flag [.], seq 29096601, ack 612563041, win 7300" 2014-12-09 13:16:31 id=20085 trace_id=104 func=resolve_ip_tuple_fast line=4432 msg="Find an existing session, id-0000027b, original direction" 2014-12-09 13:16:31 id=20085 trace_id=104 func=__ip_session_run_tuple line=2520 msg="SNAT 192.168.10.63->192.168.10.51:58746"
Removi o comando ‘allow-traffic-redirect’ no debug flow abaixo, para comparar como seria o output dessa análise quando o problema ocorre:
2014-12-09 13:19:51 id=20085 trace_id=105 func=print_pkt_detail line=4373 msg="vd-root received a packet(proto=6, 192.168.10.63:44447->172.16.0.160:443) from port2. flag [S], seq 3913655818, ack 0, win 14600" 2014-12-09 13:19:51 id=20085 trace_id=105 func=init_ip_session_common line=4522 msg="allocate a new session-000002d0" 2014-12-09 13:19:51 id=20085 trace_id=105 func=vf_ip4_route_input line=1596 msg="find a route: flags=01000000 gw-192.168.10.211 via port2" 2014-12-09 13:19:54 id=20085 trace_id=106 func=print_pkt_detail line=4373 msg="vd-root received a packet(proto=6, 192.168.10.63:44447->172.16.0.160:443) from port2. flag [S], seq 3913655818, ack 0, win 14600" 2014-12-09 13:19:54 id=20085 trace_id=106 func=init_ip_session_common line=4522 msg="allocate a new session-000002d3" 2014-12-09 13:19:54 id=20085 trace_id=106 func=vf_ip4_route_input line=1596 msg="find a route: flags=01000000 gw-192.168.10.211 via port2"
Lembrando apenas que esse tipo de topologia não é usual e obviamente não é a melhor prática, porém as vezes não temos como mudar a topologia do ambiente e temos que fazer funcionar de “qualquer jeito”. Caso resolvido!
Referências
FortiOS 5.2.0 CLI Reference
RFC 792 – ICMP
24/09/2014
Acesso à Internet usando SSO, múltiplos grupos e SSL Inspection
No último post integramos nosso FGT com o AD para acesso administrativo ao firewall, agora iremos melhorar nossas regras para acesso à Internet agregando o requerimento de autenticação e inspeção “light” do SSL, dessa maneira teremos o controle de usuários, granularidade nos acessos e garantiremos que a política de Web Filter será aplicada corretamente.
Os objetivos hoje são: fazer com que todo acesso seja autenticado de maneira transparente (SSO), que os usuários de Marketing tenham acesso ao YouTube e Facebook (Streaming e Redes Sociais), IT tenha acesso à sites de hacking, usuários VIP possam acessar tudo que não traga risco à segurança da rede ou que possa ser considerado legalmente prejudicial para a imagem da empresa e que os demais usuários somente tenham acesso a um conjunto mínimo de websites, todos relacionados a trabalho.
Após isso iremos ativar o SSL Inspection (para evitar o bypass das políticas) e descobrir como podemos implementar esta tecnologia sem causar caos na rede 🙂
Embora já tenhamos feito a integração com o AD fazendo com que o FGT realizasse o pooling (no post anterior) agora iremos instalar o agente no DC. Durante a instalação é possível selecionar o modo de funcionamento do agente. Para escolher corretamente precisamos ter alguns conceitos em mente, podemos configurar o SSO com agente das seguintes maneiras:
- DC Agent (ambientes grandes, links lentos – mínimo 64Kbps, alta rotatividade de IPs)
- NetAPI (ambientes pequenos, links rápidos, baixa rotatividade de IPs)
- WinSecLog Polling (ambientes grandes, links rápidos, alta rotatividades e MACs logando no AD)
- WinSecLog WMI Polling (ambientes grandes, links rápidos, alta rotatividades e MACs logando no AD, melhor performance do que o anterior porém requer configurações adicionais nos DCs)
No agente também é possível customizar alguns parâmetros como o cache de grupos (minimizando o impacto em CPU e memória no server), tanto via GUI quanto pelo registro em:
64bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Fortinet\FSAE\collectoragent
32bit: HKEY_LOCAL_MACHINE\SOFTWARE\Fortinet\FSAE\collectoragent
O DC Agent é instalado no DC, Collector Agent é instalado em qualquer máquina membro do AD. Múltiplos DC Agents podem enviar a informação para um Collector que envia para o FGT. Em nosso cenário iremos utilizar o modo DC Agent e o Collector no mesmo servidor.
Após instalação do agente (o executável deve ser o adequado para a versão do FOS rodando no FGT, neste lab usei FOS 5.0.9 e FSSO Agent 4.3.0157, OS W2K8 R2 STD) vamos configurá-lo:
- Show Monitored DCs
- Select DC to Monitor…
- DC Agent Mode
- Selecione o DC, o agente em DC Mode será instalado e o servidor será reiniciado
Agora voltamos para a configuração no FGT, é esperado que o LDAP Server já esteja configurado de acordo com este post:
Autenticação LDAP para acesso administrativo ao FortiGate.
Bônus: Confira o que acontece ao apertar o botão “Test” em User & Device, Authentication, LDAP Servers, <servidor>
Download: ldap_test.pcap, altere a extensão para PCAP para visualizar o conteúdo no Wireshark.
Vamos criar um novo SSO Server e indicar quais grupos do AD podem ser utilizados nas regras, é importante lembrar que nesse primeiro momento iremos somente indicar quais grupos iremos utilizar e somente após essa configuração iremos criar os grupos locais no FGT (que efetivamente serão usados nas regras) e associá-los aos grupos do AD correspondentes.
config user fsso # User & Device::Authentication::Single Sign-On
edit "FSSO DC Agent Mode"
set ldap-server "baldur"
set password ENC THcsYGLMwna8Z6+7qv9AJpT5vrW...
set server "10.0.1.10"
next
end
config user adgrp
edit "CN=Information Technology,OU=HQ,DC=ad,DC=deadpackets,DC=com"
set server-name "FSSO DC Agent Mode"
next
edit "CN=Marketing,OU=HQ,DC=ad,DC=deadpackets,DC=com"
set server-name "FSSO DC Agent Mode"
next
edit "CN=VIP,OU=HQ,DC=ad,DC=deadpackets,DC=com"
set server-name "FSSO DC Agent Mode"
next
edit "CN=Domain Users,CN=Users,DC=ad,DC=deadpackets,DC=com"
set server-name "FSSO DC Agent Mode"
next
end
Ok, tudo configurado! Ao verificar o status da comunicação com o agente vemos um nada animador “X”…
Após conferir que a senha configurada no agente está igual à configurada na configuração do SSO Server testamos a comunicação entre o FGT e o Collector (que nesse caso está no mesmo servidor que o DC Agent) na porta TCP/8000.
LAB-DC # exec telnet 10.0.1.10 8000 Timeout!
Após criação da regra no firewall do Windows no AD podemos ver que a conexão é estabelecida com sucesso.
LAB-DC # exec telnet 10.0.1.10 8000 Z? ?? FSSO 4.3.0157j0xAr<??4bz?FFSAE_SERVER_10001 LAB-DC # LAB-DC # diag debug ena LAB-DC # diag debug authd fsso server-status LAB-DC # 2014-09-18 01:35:14 Server Name Connection Status Version ----------- ----------------- ------- 2014-09-18 01:35:14 FSSO DC Agent Mode connected FSSO 4.3.0157
E o status na GUI também reflete isso:
Procedemos com a criação dos grupos:
config user group # User & Device::User::User Groups
edit "Marketing-FSSO"
set group-type fsso-service
set member "CN=Marketing,OU=HQ,DC=ad,DC=deadpackets,DC=com"
next
edit "VIP-FSSO"
set group-type fsso-service
set member "CN=VIP,OU=HQ,DC=ad,DC=deadpackets,DC=com"
next
edit "Domain Users-FSSO"
set group-type fsso-service
set member "CN=Domain Users,CN=Users,DC=ad,DC=deadpackets,DC=com"
next
end
Para o grupo de IT inicialmente não vamos criar um novo grupo, vamos tentar aproveitar o grupo já existente “Information Technology-FW” (e não vai ter o resultado esperado).
Após a criação dos grupos vamos criar os perfis de Web Filter adequados, cada um de acordo com as restrições definidas inicialmente.
config webfilter profile # Security Profiles::Web Filter::Profiles
edit "WF-DOMAIN-USERS"
set ovrd-perm bannedword-override urlfilter-override fortiguard-wf-override contenttype-check-override
config override
set ovrd-user-group ""
end
config ftgd-wf
unset options
config filters
edit 83
set category 143
next
edit 1
set category 142
next
edit 2
set category 140
next
edit 3
set category 141
next
edit 4
set action block
set category 83
next
edit 5
set action block
set category 5
next
edit 6
set action block
set category 1
next
edit 7
set action block
set category 6
next
edit 8
set action block
set category 12
next
edit 9
set action block
set category 3
next
edit 10
set action block
set category 4
next
edit 11
set action block
set category 62
next
edit 12
set action block
set category 59
next
edit 13
set action block
set category 7
next
edit 14
set action block
set category 9
next
edit 15
set action block
set category 64
next
edit 16
set action block
set category 2
next
edit 17
set action block
set category 15
next
edit 18
set action block
set category 11
next
edit 19
set action block
set category 66
next
edit 20
set action block
set category 57
next
edit 21
set action block
set category 13
next
edit 22
set action block
set category 8
next
edit 23
set action block
set category 14
next
edit 24
set action block
set category 63
next
edit 25
set action block
set category 67
next
edit 26
set action block
set category 65
next
edit 27
set action block
set category 16
next
edit 28
set action block
set category 24
next
edit 29
set action block
set category 19
next
edit 30
set action block
set category 75
next
edit 31
set action block
set category 76
next
edit 32
set action block
set category 72
next
edit 33
set action block
set category 25
next
edit 34
set action block
set category 26
next
edit 35
set action block
set category 61
next
edit 36
set action block
set category 86
next
edit 37
set action block
set category 17
next
edit 38
set action block
set category 29
next
edit 39
set action block
set category 18
next
edit 40
set action block
set category 77
next
edit 41
set action block
set category 82
next
edit 42
set action block
set category 71
next
edit 43
set action block
set category 85
next
edit 44
set action block
set category 54
next
edit 45
set action block
set category 30
next
edit 46
set action block
set category 28
next
edit 47
set action block
set category 58
next
edit 48
set action block
set category 20
next
edit 49
set action block
set category 40
next
edit 50
set action block
set category 33
next
edit 51
set action block
set category 69
next
edit 52
set action block
set category 34
next
edit 53
set action block
set category 55
next
edit 54
set action block
set category 35
next
edit 55
set action block
set category 36
next
edit 56
set action block
set category 70
next
edit 57
set action block
set category 87
next
edit 58
set action block
set category 48
next
edit 59
set action block
set category 80
next
edit 60
set action block
set category 38
next
edit 61
set action block
set category 78
next
edit 62
set action block
set category 39
next
edit 63
set action block
set category 79
next
edit 64
set action block
set category 42
next
edit 65
set action block
set category 37
next
edit 66
set action block
set category 44
next
edit 67
set action block
set category 46
next
edit 68
set action block
set category 47
next
edit 69
set action block
set category 68
next
edit 70
set action block
set category 23
next
edit 72
set category 53
next
edit 73
set category 49
next
edit 74
set category 31
next
edit 75
set category 43
next
edit 76
set category 51
next
edit 77
set category 52
next
edit 78
set category 50
next
edit 79
set category 41
next
edit 80
set category 81
next
edit 81
set category 56
next
edit 82
set category 84
next
edit 71
set action block
next
end
end
next
end
config webfilter profile # Security Profiles::Web Filter::Profiles
edit "WF-IT"
set ovrd-perm bannedword-override urlfilter-override fortiguard-wf-override contenttype-check-override
config override
set ovrd-user-group ""
end
config ftgd-wf
unset options
config filters
edit 91
set category 143
next
edit 1
set category 142
next
edit 2
set category 140
next
edit 3
set category 141
next
edit 71
set action block
set category 83
next
edit 72
set action block
set category 5
next
edit 73
set action block
set category 1
next
edit 74
set action block
set category 6
next
edit 75
set action block
set category 12
next
edit 90
set category 3
next
edit 76
set action block
set category 4
next
edit 77
set action block
set category 62
next
edit 78
set action block
set category 59
next
edit 12
set action block
set category 7
next
edit 13
set action block
set category 9
next
edit 14
set action block
set category 64
next
edit 15
set action block
set category 2
next
edit 16
set action block
set category 15
next
edit 17
set action block
set category 11
next
edit 18
set action block
set category 66
next
edit 19
set action block
set category 57
next
edit 20
set action block
set category 13
next
edit 21
set action block
set category 8
next
edit 22
set action block
set category 14
next
edit 23
set action block
set category 63
next
edit 24
set action block
set category 67
next
edit 25
set action block
set category 65
next
edit 26
set action block
set category 16
next
edit 27
set action block
set category 24
next
edit 28
set action block
set category 19
next
edit 29
set action block
set category 75
next
edit 30
set action block
set category 76
next
edit 31
set action block
set category 72
next
edit 32
set action block
set category 25
next
edit 33
set action block
set category 26
next
edit 34
set action block
set category 61
next
edit 35
set action block
set category 86
next
edit 36
set action block
set category 17
next
edit 37
set action block
set category 29
next
edit 38
set action block
set category 18
next
edit 39
set action block
set category 77
next
edit 40
set action block
set category 82
next
edit 41
set action block
set category 71
next
edit 42
set action block
set category 85
next
edit 43
set action block
set category 54
next
edit 44
set action block
set category 30
next
edit 45
set action block
set category 28
next
edit 46
set action block
set category 58
next
edit 47
set action block
set category 20
next
edit 48
set action block
set category 40
next
edit 49
set action block
set category 33
next
edit 50
set action block
set category 69
next
edit 51
set action block
set category 34
next
edit 52
set action block
set category 55
next
edit 53
set action block
set category 35
next
edit 54
set action block
set category 36
next
edit 55
set action block
set category 70
next
edit 56
set action block
set category 87
next
edit 57
set action block
set category 48
next
edit 58
set action block
set category 80
next
edit 59
set action block
set category 38
next
edit 60
set action block
set category 78
next
edit 61
set action block
set category 39
next
edit 62
set action block
set category 79
next
edit 63
set action block
set category 42
next
edit 64
set action block
set category 37
next
edit 65
set action block
set category 44
next
edit 66
set action block
set category 46
next
edit 67
set action block
set category 47
next
edit 68
set action block
set category 68
next
edit 69
set action block
set category 23
next
edit 79
set category 53
next
edit 80
set category 49
next
edit 81
set category 31
next
edit 82
set category 43
next
edit 83
set category 51
next
edit 84
set category 52
next
edit 85
set category 50
next
edit 86
set category 41
next
edit 87
set category 81
next
edit 88
set category 56
next
edit 89
set category 84
next
edit 70
set action block
next
end
end
next
end
config webfilter profile # Security Profiles::Web Filter::Profiles
edit "WF-MARKETING"
set ovrd-perm bannedword-override urlfilter-override fortiguard-wf-override contenttype-check-override
config override
set ovrd-user-group ""
end
config ftgd-wf
unset options
set category-override 143
config filters
edit 83
set category 143
next
edit 1
set category 142
next
edit 2
set category 140
next
edit 3
set category 141
next
edit 4
set action block
set category 83
next
edit 5
set action block
set category 5
next
edit 6
set action block
set category 1
next
edit 7
set action block
set category 6
next
edit 8
set action block
set category 12
next
edit 9
set action block
set category 3
next
edit 10
set action block
set category 4
next
edit 11
set action block
set category 62
next
edit 12
set action block
set category 59
next
edit 13
set action block
set category 7
next
edit 14
set action block
set category 9
next
edit 15
set action block
set category 64
next
edit 16
set action block
set category 2
next
edit 17
set action block
set category 15
next
edit 18
set action block
set category 11
next
edit 19
set action block
set category 66
next
edit 20
set action block
set category 57
next
edit 21
set action block
set category 13
next
edit 22
set action block
set category 8
next
edit 23
set action block
set category 14
next
edit 24
set action block
set category 63
next
edit 25
set action block
set category 67
next
edit 26
set action block
set category 65
next
edit 27
set action block
set category 16
next
edit 28
set action block
set category 24
next
edit 29
set action block
set category 19
next
edit 30
set action block
set category 75
next
edit 31
set action block
set category 76
next
edit 32
set action block
set category 72
next
edit 33
set category 25
next
edit 34
set action block
set category 26
next
edit 35
set action block
set category 61
next
edit 36
set action block
set category 86
next
edit 37
set action block
set category 17
next
edit 38
set action block
set category 29
next
edit 39
set action block
set category 18
next
edit 40
set action block
set category 77
next
edit 41
set action block
set category 82
next
edit 42
set action block
set category 71
next
edit 43
set action block
set category 85
next
edit 44
set action block
set category 54
next
edit 45
set action block
set category 30
next
edit 46
set action block
set category 28
next
edit 47
set action block
set category 58
next
edit 48
set action block
set category 20
next
edit 49
set action block
set category 40
next
edit 50
set action block
set category 33
next
edit 51
set action block
set category 69
next
edit 52
set action block
set category 34
next
edit 53
set action block
set category 55
next
edit 54
set action block
set category 35
next
edit 55
set action block
set category 36
next
edit 56
set action block
set category 70
next
edit 57
set action block
set category 87
next
edit 58
set action block
set category 48
next
edit 59
set action block
set category 80
next
edit 60
set action block
set category 38
next
edit 61
set action block
set category 78
next
edit 62
set action block
set category 39
next
edit 63
set action block
set category 79
next
edit 64
set action block
set category 42
next
edit 65
set category 37
next
edit 66
set action block
set category 44
next
edit 67
set action block
set category 46
next
edit 68
set action block
set category 47
next
edit 69
set action block
set category 68
next
edit 70
set action block
set category 23
next
edit 72
set category 53
next
edit 73
set category 49
next
edit 74
set category 31
next
edit 75
set category 43
next
edit 76
set category 51
next
edit 77
set category 52
next
edit 78
set category 50
next
edit 79
set category 41
next
edit 80
set category 81
next
edit 81
set category 56
next
edit 82
set category 84
next
edit 71
set action block
next
end
end
next
end
config webfilter profile # Security Profiles::Web Filter::Profiles
edit "WF-VIP"
set ovrd-perm bannedword-override urlfilter-override fortiguard-wf-override contenttype-check-override
config override
set ovrd-user-group ""
end
config ftgd-wf
unset options
config filters
edit 16
set category 143
next
edit 1
set category 142
next
edit 2
set category 140
next
edit 3
set category 141
next
edit 4
set action block
set category 83
next
edit 5
set action block
set category 5
next
edit 6
set action block
set category 1
next
edit 7
set action block
set category 6
next
edit 8
set action block
set category 12
next
edit 9
set action block
set category 3
next
edit 10
set action block
set category 4
next
edit 11
set action block
set category 62
next
edit 12
set action block
set category 59
next
edit 17
set category 7
next
edit 18
set category 9
next
edit 19
set category 64
next
edit 20
set category 2
next
edit 21
set category 15
next
edit 22
set category 11
next
edit 23
set category 66
next
edit 24
set category 57
next
edit 25
set category 13
next
edit 26
set category 8
next
edit 27
set category 14
next
edit 28
set category 63
next
edit 29
set category 67
next
edit 30
set category 65
next
edit 31
set category 16
next
edit 32
set category 24
next
edit 33
set category 19
next
edit 34
set category 75
next
edit 35
set category 76
next
edit 36
set category 72
next
edit 37
set category 25
next
edit 13
set action block
set category 26
next
edit 14
set action block
set category 61
next
edit 15
set action block
set category 86
next
edit 38
set category 17
next
edit 39
set category 29
next
edit 40
set category 18
next
edit 41
set category 77
next
edit 42
set category 82
next
edit 43
set category 71
next
edit 44
set category 85
next
edit 45
set category 54
next
edit 46
set category 30
next
edit 47
set category 28
next
edit 48
set category 58
next
edit 49
set category 20
next
edit 50
set category 40
next
edit 51
set category 33
next
edit 52
set category 69
next
edit 53
set category 34
next
edit 54
set category 55
next
edit 55
set category 35
next
edit 56
set category 36
next
edit 57
set category 70
next
edit 58
set category 87
next
edit 59
set category 48
next
edit 60
set category 80
next
edit 61
set category 38
next
edit 62
set category 78
next
edit 63
set category 39
next
edit 64
set category 79
next
edit 65
set category 42
next
edit 66
set category 37
next
edit 67
set category 44
next
edit 68
set category 46
next
edit 69
set category 47
next
edit 70
set category 68
next
edit 71
set category 23
next
edit 72
set category 53
next
edit 73
set category 49
next
edit 74
set category 31
next
edit 75
set category 43
next
edit 76
set category 51
next
edit 77
set category 52
next
edit 78
set category 50
next
edit 79
set category 41
next
edit 80
set category 81
next
edit 81
set category 56
next
edit 82
set category 84
next
edit 83
next
end
end
next
end
Como podem ver a configuração via CLI pode ficar um pouco extensa, por isso é muito mais interessante configurarmos e verificarmos isso via GUI. Alguns detalhes interessantes:
- “Allow” não gera log de Web Filter (a categoria do site não é incluída no log), na CLI isso é refletido pela ausência da categoria explicitamente na configuração
- “Monitor” gera log de Web Filter (populando o campo “Category Description”), na CLI vai existir a definição da categoria, mas sem ação explícita
- “Warning” gera uma tela que avisa que o acesso não é recomendado, mas que deixa o usuário proceder com o acesso (como um reforço da política, mas que não vai impedir o acesso caso ele realmente seja necessário)
Segue o exemplo do como ficaria na GUI o perfil que criamos para “Domain Users”:
Após criação dos perfis de Web Filter vamos associá-los aos grupos na política de firewall.
config firewall policy
edit 3
set srcintf "LAN"
set dstintf "WAN"
set srcaddr "net-10.0.1.0/24"
set action accept
set webcache enable
set fsso enable
set log-unmatched-traffic enable
set identity-based enable
set nat enable
config identity-based-policy
edit 2
set schedule "always"
set logtraffic all
set utm-status enable
set groups "Domain Users-FSSO"
set dstaddr "all"
set service "Web Access"
set webfilter-profile "WF-DOMAIN-USERS"
set profile-protocol-options "default"
next
edit 1
set schedule "always"
set logtraffic all
set logtraffic-start enable
set utm-status enable
set groups "Information Technology-FW"
set dstaddr "all"
set service "Web Access"
set webfilter-profile "WF-IT"
set profile-protocol-options "default"
next
edit 3
set schedule "always"
set logtraffic all
set utm-status enable
set groups "Marketing-FSSO"
set dstaddr "all"
set service "Web Access"
set webfilter-profile "WF-MARKETING"
set profile-protocol-options "default"
next
edit 4
set schedule "always"
set logtraffic all
set utm-status enable
set groups "VIP-FSSO"
set dstaddr "all"
set service "Web Access"
set webfilter-profile "WF-VIP"
set profile-protocol-options "default"
next
end
next
end
Ou de maneira muito mais amigável na GUI:
Ok, tudo configurado agora vamos testar e resolver os problemas (intencionalmente colocados).
Ao logar como hford (Domain Users) e tentarmos acessar a Internet vemos a tela de Firewall Authentication:
Estranho… Ao rever a regra acima notamos que o grupo “Information Technology-FW” é de um tipo diferente dos demais, revendo a configuração dele e comparando com os outros grupos criados recentemente é possível ver que ele é um grupo do tipo “Firewall” enquanto os demais são do tipo “Fortinet Single Sign-On”. A tela de autenticação que nos é apresentada ocorre devido a existência desse grupo na regra que configuramos, portanto para corrigir isso vamos criar um grupo novo para IT, dessa vez como SSO e utilizá-lo na nossa política
config user group
edit "Information Technology-FSSO"
set group-type fsso-service
next
end
</pre>
<pre>config firewall policy
edit 3
config identity-based-policy
edit 1
set groups "Information Technology-FSSO"
end
end
Novo teste, dessa vez não vemos a tela de Firewall Authentication porém ainda não temos acesso, a mensagem de erro “The page cannot be displayed” é exibida. Conferindo os logs no FGT vemos:
LAB-DC # exec log filter field srcip 10.0.1.100 LAB-DC # exec log filter field dstport 80 LAB-DC # exec log display 6 logs found. 6 logs returned. 1: date=2014-09-18 time=16:29:38 logid=0000000013 type=traffic subtype=forward level=notice vd=root srcip=10.0.1.100 srcport=2467 srcintf="port3" dstip=66.171.121.34 dstport=80 dstintf="port2" sessionid=5443 status=deny policyid=3 dstcountry="United States" srccountry="Reserved" trandisp=noop service=HTTP proto=6 duration=0 sentbyte=0 rcvdbyte=0 2: date=2014-09-18 time=16:29:32 logid=0000000013 type=traffic subtype=forward level=notice vd=root srcip=10.0.1.100 srcport=2467 srcintf="port3" dstip=66.171.121.34 dstport=80 dstintf="port2" sessionid=5441 status=deny policyid=3 dstcountry="United States" srccountry="Reserved" trandisp=noop service=HTTP proto=6 duration=0 sentbyte=0 rcvdbyte=0 ....
O bloqueio está ocorrendo na policy id 3, a única maneira disso ocorrer é através do bloqueio pela regra de DENY implícita, se o tráfego chega nela é porque existe algum problema com a identificação do usuário que está tentando navegar. Vamos verificar como está o agente e a lista de usuários identificados no FGT.
LAB-DC # diag debug authd fsso list ----FSSO logons---- Total number of logons listed: 0, filtered: 0 ----end of FSSO logons----
E no agente:
O usuário logado é identificado porém o FGT não parece reconhecer esta informação. Veja também que os grupos do usuários aparecem no formato “Domínio/Grupo” diferente da maneira de como fizemos os filtros de grupo, no formato ““CN=Marketing,OU=HQ,DC=ad,DC=deadpackets,DC=com”. Lendo o capítulo de autenticação do Handbook é possível notar que quando utilizamos a informação do servidor LDAP na configuração do SSO Server (como nós fizemos) é necessário configurar o agente no modo “Advanced” para que envie a informação dos grupos da maneira correta, basta alterar em “Set Directory Access Information”:
Limpe o cache de usuários (Show Logon Users, Clear User Cache) e faça login novamente, verifique como a informação dos grupos que esse usuário pertence é apresentada em outro formato:
e ao verificar no FGT temos a informação correta, coerente com o que é exibido no agente:
LAB-DC # diag debug authd fsso list ----FSSO logons---- IP: 10.0.1.100 User: HFORD Groups: CN=DOMAIN USERS,CN=USERS,DC=AD,DC=DEADPACKETS,DC=COM Workstation: ALEXANDR-BD97B3.AD.DEADPACKETS.COM MemberOf: Domain Users-FSSO Total number of logons listed: 1, filtered: 0 ----end of FSSO logons----
Essa mesma informação pode ser vista na GUI em User & Device::Monitor::Firewall, ative a opção “Show all FSSO Logons” no canto superior direito.
Uma vez garantido a identificação dos usuários vamos testar o acesso com hford (IT) e… SUCESSO!
Realizando os demais podemos constatar que todos tem o resultado esperado: Pornografia bloqueado com sucesso, Redes Sociais idem… porém ao tentar entrar no Facebook usando HTTPS conseguimos acessar! Isso ocorre porque não ativamos a inspeção do SSL, seguimos para a configuração:
Perfil de SSL Inspection:
config firewall deep-inspection-options # Policy::SSL/SSH Inspection
edit "https-only" # Na versão 5.0.9 esse perfil já existe por padrão
config https
set ports 443
end
config ftps
set ports 990
set status disable
end
config imaps
set ports 993
set status disable
end
config pop3s
set ports 995
set status disable
end
config smtps
set ports 465
set status disable
end
config ssh
set ports 22
set status disable
end
next
end
Alteração na regra de firewall:
config firewall policy
edit 3
config identity-based-policy
edit 2 # Ou simplesmente ative a opção "SSL/SSH Inspection"
set deep-inspection-options "https-only" # e selecione o perfil "https-only"
end
end
Alteração no perfil de Web Filter
conf webfilter profile edit WF-DOMAIN-USERS set options https-url-scan # Idem a desabilitar a opção "Scan Encrypted Connections" via GUI end
Teste novamente e tudo funciona como esperado!
Agora replicamos as alterações acimas para os outros grupos (na política de firewall e no perfil do Web Filter), e fazemos os testes novamente, segue log de resultados para o teste com os seguintes websites:
http://www.exploit-db.com (Hacking)
http://www.pornhub.com (Pornography)
http://www.facebook.com (Social Networks)
http://www.fortinet.com (Information Technology, incluído em General Interest – Business)
hford (Domain Users)
jwayne (IT)
rdeniro (Marketing)
ggarbo (VIP)
Como vemos acima todos os testes mostram que os perfis definidos inicialmente estão configurados corretamente e que os bloqueios/liberações estão ocorrendo conforme o esperado, de maneira granular usando os grupos do AD e utilizando categorias que são atualizadas constantemente, minimizando riscos de segurança como os relacionados a acessos indevidos e utilização excessiva de banda.
Referências
User Authentication
Configuring FortiOS v5.0 Webfiltering for HTTPS scanning without SSL Deep Scanning
Technical Note : Allowing FSSO Ports when using Windows Server 2008
24/07/2014
Autenticação LDAP para acesso administrativo ao FortiGate
Após garantir o acesso à Internet no último post, dessa vez iremos explorar algumas opções para melhorar a segurança no acesso ao firewall, assim como a integração com o Domain Controller (AD W2K8 R2) para simplificar o acesso dos administradores.
O objetivo de hoje é fazer com que o acesso administrativo ao firewall seja feito utilizando as mesmas credenciais que o usuário possui na base LDAP (Active Directory). Para alcançar esse objetivo primeiro é necessário criar o servidor LDAP:
config user ldap # User & Device:Authentication:LDAP Servers
edit "baldur"
set server "10.0.1.10"
set cnid “cn"
set dn "DC=ad,DC=deadpackets,DC=com” # dn para ad.deadpackets.com
set type regular
set username “_svcFGT” # Usuário com direito de leitura no AD
set password D3@dPacket$!#
next
end
Após a configuração você pode testar a mesma usando o botão “Test” na GUI ou via CLI com a sintaxe abaixo:
FortiGate-VM64 # diag test authserver ldap baldur _svcFGT D3@dPacket$!# authenticate '_svcFGT' against 'baldur' succeeded! Group membership(s) - CN=Domain Users,CN=Users,DC=ad,DC=deadpackets,DC=com
Ok, conexão com AD validada! Agora seguimos criando o grupo no FGT que irá fazer a referência ao grupo do AD que deverá ter acesso, queremos que somente usuários do grupo “Information Technology” tenham acesso administrativo no firewall.
config user group # User & Device:User:User Groups
edit "Information Technology-FW"
set member "baldur"
config match
edit 1
set server-name "baldur"
set group-name "CN=Information Technology,OU=HQ,DC=ad,DC=deadpackets,DC=com"
next
end
next
end
Finalmente, basta criar um usuário de administração que fará a referência ao grupo de IT remoto.
config system admin # System:Admin:Administrators
edit "IT"
set remote-auth enable
set accprofile "super_admin"
set wildcard enable
set remote-group "Information Technology-FW"
next
end
Agora testamos. Um usuário do grupo de administração é o John Wayne que naturalmente ao tentar logar usou seu nome de usuário ‘jwayne’ e… falha.
Voltamos ao debug, testamos com o próprio usuário via CLI:
FortiGate-VM64 # diag test authserver ldap baldur jwayne D3@dPacket$!# authenticate 'jwayne' against 'baldur' failed!
Revendo a configuração do servidor LDAP nota-se que estamos utilizando o parâmetro ‘cn’ para a consulta, utilizando o ADSI Edit no AD investigamos a que valor corresponde essa chave para o usuário jwayne.
Logo, como o cn corresponde ao nome do usuário no formato ‘John Wayne’ esse deve ser o valor utilizado, testamos novamente:
FortiGate-VM64 # diag test authserver ldap baldur 'John Wayne' D3@dPacket$!#
authenticate 'John Wayne' against 'baldur' succeeded!
Group membership(s) - CN=Information Technology,OU=HQ,DC=ad,DC=deadpackets,DC=com
CN=Domain Users,CN=Users,DC=ad,DC=deadpackets,DC=com
Sucesso! Porém esse não é o modo que queremos que nossos usuários utilizem, queremos utilizar o nome de usuário no formato “simplificado”, porém qual chave contém esse valor ?
Voltamos ao ADSI Edit e investigando as diversas chaves disponíveis encontramos a ideal:
Portanto para obter o comportamento esperado devemos trocar o parâmetro utilizado para a consulta LDAP.
config user ldap
edit "baldur"
set cnid "sAMAccountName"
end
Repetimos o teste:
FortiGate-VM64 # diag test authserver ldap baldur jwayne D3@dPacket$!#
authenticate 'jwayne' against 'baldur' succeeded!
Group membership(s) - CN=Information Technology,OU=HQ,DC=ad,DC=deadpackets,DC=com
CN=Domain Users,CN=Users,DC=ad,DC=deadpackets,DC=com
e sucesso 🙂
Finalmente vamos visualizar o processo de autenticação para um usuário do grupo “Information Technology” e depois o processo de tentativa e falha de login de um usuário fora desse grupo.
Primeiro iremos ver o processo de login do usuário autorizado, jwayne:
diag debug ena diag debug reset diag debug app fnbamd -1 diag debug ena # Neste momento o usario jwayne realiza o login pela interface Web fnbamd_fsm.c[1391] handle_req-Rcvd auth req 51 for jwayne in Information Technology-FW opt=16385 prot=9 fnbamd_auth.c[232] radius_start-Didn't find radius servers (0) fnbamd_auth.c[588] auth_tac_plus_start-Didn't find tac_plus servers (0) fnbamd_ldap.c[866] resolve_ldap_FQDN-Resolved address 10.0.1.10, result 10.0.1.10 fnbamd_ldap.c[352] start_search_dn-base:'DC=ad,DC=deadpackets,DC=com' filter:sAMAccountName=jwayne fnbamd_ldap.c[1594] fnbamd_ldap_get_result-Going to SEARCH state fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[386] get_all_dn-Found DN 1:CN=John Wayne,OU=HQ,DC=ad,DC=deadpackets,DC=com fnbamd_ldap.c[400] get_all_dn-Found 1 DN's fnbamd_ldap.c[434] start_next_dn_bind-Trying DN 1:CN=John Wayne,OU=HQ,DC=ad,DC=deadpackets,DC=com fnbamd_ldap.c[1642] fnbamd_ldap_get_result-Going to USERBIND state fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[640] start_multi_attribute_lookup-Adding attr 'memberOf' fnbamd_ldap.c[661] start_multi_attribute_lookup-base:'CN=John Wayne,OU=HQ,DC=ad,DC=deadpackets,DC=com' filter:cn=* fnbamd_ldap.c[1698] fnbamd_ldap_get_result-Entering CHKUSERATTRS state fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[789] get_member_of_groups-Get the memberOf groups. fnbamd_ldap.c[699] check_primary_group-starting check... fnbamd_ldap.c[706] check_primary_group-primary group id = 513 fnbamd_ldap.c[720] check_primary_group-number of sub auths 5 fnbamd_ldap.c[739] check_primary_group-base:'DC=ad,DC=deadpackets,DC=com' filter:(&(objectclass=group)(objectSid=\01\05\00\00\00\00\00\05\15\00\00\00\94\9f\a2\23\e8\75\97\81\7f\ad\3c\86\01\02\00\00)) fnbamd_ldap.c[815] get_member_of_groups- attr='memberOf', found 1 values fnbamd_ldap.c[827] get_member_of_groups-val[0]='CN=Information Technology,OU=HQ,DC=ad,DC=deadpackets,DC=com' fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 51 fnbamd_ldap.c[771] get_primary_groups-primary group: CN=Domain Users,CN=Users,DC=ad,DC=deadpackets,DC=com fnbamd_ldap.c[1529] fnbamd_ldap_get_result-Auth accepted fnbamd_ldap.c[1834] fnbamd_ldap_get_result-Going to DONE state res=0 fnbamd_auth.c[2044] fnbamd_auth_poll_ldap-Result for ldap svr 10.0.1.10 is SUCCESS fnbamd_auth.c[2061] fnbamd_auth_poll_ldap-Passed group matching fnbamd_comm.c[146] fnbamd_comm_send_result-Sending result 0 for req 51 fnbamd_fsm.c[311] destroy_auth_session-delete session 51
Com o debug podemos ver claramente que o usuário pertence ao grupo “Information Technology” e que a verificação do grupo foi feita com sucesso.
Agora um usuário espertinho tenta acessar o firewall porém como ele não está no grupo autorizado é esperado que o acesso não seja realizado, vamos verificar:
Debug quando o usuário hford (que pertence ao grupo “Sales”) tenta o acesso ao firewall:
fnbamd_fsm.c[1391] handle_req-Rcvd auth req 53 for hford in Information Technology-FW opt=16385 prot=9 fnbamd_auth.c[232] radius_start-Didn't find radius servers (0) fnbamd_auth.c[588] auth_tac_plus_start-Didn't find tac_plus servers (0) fnbamd_ldap.c[866] resolve_ldap_FQDN-Resolved address 10.0.1.10, result 10.0.1.10 fnbamd_ldap.c[352] start_search_dn-base:'DC=ad,DC=deadpackets,DC=com' filter:sAMAccountName=hford fnbamd_ldap.c[1594] fnbamd_ldap_get_result-Going to SEARCH state fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[386] get_all_dn-Found DN 1:CN=Harrison Ford,OU=HQ,DC=ad,DC=deadpackets,DC=com fnbamd_ldap.c[400] get_all_dn-Found 1 DN's fnbamd_ldap.c[434] start_next_dn_bind-Trying DN 1:CN=Harrison Ford,OU=HQ,DC=ad,DC=deadpackets,DC=com fnbamd_ldap.c[1642] fnbamd_ldap_get_result-Going to USERBIND state fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[640] start_multi_attribute_lookup-Adding attr 'memberOf' fnbamd_ldap.c[661] start_multi_attribute_lookup-base:'CN=Harrison Ford,OU=HQ,DC=ad,DC=deadpackets,DC=com' filter:cn=* fnbamd_ldap.c[1698] fnbamd_ldap_get_result-Entering CHKUSERATTRS state fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[789] get_member_of_groups-Get the memberOf groups. fnbamd_ldap.c[699] check_primary_group-starting check... fnbamd_ldap.c[706] check_primary_group-primary group id = 513 fnbamd_ldap.c[720] check_primary_group-number of sub auths 5 fnbamd_ldap.c[739] check_primary_group-base:'DC=ad,DC=deadpackets,DC=com' filter:(&(objectclass=group)(objectSid=\01\05\00\00\00\00\00\05\15\00\00\00\94\9f\a2\23\e8\75\97\81\7f\ad\3c\86\01\02\00\00)) fnbamd_ldap.c[815] get_member_of_groups- attr='memberOf', found 1 values fnbamd_ldap.c[827] get_member_of_groups-val[0]='CN=Sales,OU=HQ,DC=ad,DC=deadpackets,DC=com' fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 53 fnbamd_ldap.c[771] get_primary_groups-primary group: CN=Domain Users,CN=Users,DC=ad,DC=deadpackets,DC=com fnbamd_ldap.c[1529] fnbamd_ldap_get_result-Auth accepted fnbamd_ldap.c[1834] fnbamd_ldap_get_result-Going to DONE state res=0 fnbamd_auth.c[2044] fnbamd_auth_poll_ldap-Result for ldap svr 10.0.1.10 is SUCCESS fnbamd_auth.c[2056] fnbamd_auth_poll_ldap-Failed group matching fnbamd_comm.c[146] fnbamd_comm_send_result-Sending result 1 for req 53 fnbamd_fsm.c[311] destroy_auth_session-delete session 53
Podemos ver que embora a consulta tenha sido feita com sucesso (pois o usuário e senha estavam corretos) o acesso não foi dado devido a falha na verificação do grupo, como já era esperado.
Finalmente, vamos ver como seria o resultado do debug caso o usuário errasse a senha:
fnbamd_fsm.c[1391] handle_req-Rcvd auth req 83 for hford in Information Technology-FW opt=16385 prot=9 fnbamd_auth.c[232] radius_start-Didn't find radius servers (0) fnbamd_auth.c[588] auth_tac_plus_start-Didn't find tac_plus servers (0) fnbamd_ldap.c[866] resolve_ldap_FQDN-Resolved address 10.0.1.10, result 10.0.1.10 fnbamd_ldap.c[352] start_search_dn-base:'DC=ad,DC=deadpackets,DC=com' filter:sAMAccountName=hford fnbamd_ldap.c[1594] fnbamd_ldap_get_result-Going to SEARCH state fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 83 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 83 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 83 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 83 fnbamd_ldap.c[1490] fnbamd_ldap_get_result-Not ready yet fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 83 fnbamd_ldap.c[386] get_all_dn-Found DN 1:CN=Harrison Ford,OU=HQ,DC=ad,DC=deadpackets,DC=com fnbamd_ldap.c[400] get_all_dn-Found 1 DN's fnbamd_ldap.c[434] start_next_dn_bind-Trying DN 1:CN=Harrison Ford,OU=HQ,DC=ad,DC=deadpackets,DC=com fnbamd_ldap.c[1642] fnbamd_ldap_get_result-Going to USERBIND state fnbamd_fsm.c[1885] auth_ldap_result-Continue pending for req 83 fnbamd_ldap.c[418] start_next_dn_bind-No more DN left fnbamd_ldap.c[1851] fnbamd_ldap_get_result-Auth denied fnbamd_auth.c[2038] fnbamd_auth_poll_ldap-Result for ldap svr 10.0.1.10 is denied fnbamd_comm.c[146] fnbamd_comm_send_result-Sending result 1 for req 83 fnbamd_fsm.c[311] destroy_auth_session-delete session 83 diag debug disable # Não esqueça de desabilitar o debug
E além do debug, podemos também ver os logs de auditoria gerados pelos eventos de logon.
FortiGate-VM64 # exec log filter category ? <category> Category name, press enter for options. FortiGate-VM64 # exec log filter category Available categories: 11: utm-netscan 10: utm-application control 9: utm-dlp 8: utm-voip 6: content 5: utm-spam 4: utm-ips 3: utm-webfilter 2: utm-virus 1: event 0: traffic FortiGate-VM64 # exec log filter category 1 FortiGate-VM64 # exec log display # Log & Report:Event Log:System 4408 logs found. 10 logs returned. 1: date=2014-06-28 time=14:08:21 logid=0100040704 type=event subtype=system level=notice vd="root" action="perf-stats" cpu=0 mem=34 totalsession=3 msg="Performance statistics" 2: date=2014-06-28 time=14:05:17 logid=0100032001 type=event subtype=system level=information vd="root" user="jwayne" ui=https(172.16.86.1) action=login status=success reason=none profile="super_admin" msg="Administrator jwayne logged in successfully from https(172.16.86.1)" 3: date=2014-06-28 time=14:03:21 logid=0100040704 type=event subtype=system level=notice vd="root" action="perf-stats" cpu=0 mem=30 totalsession=3 msg="Performance statistics" 4: date=2014-06-28 time=14:00:13 logid=0100032002 type=event subtype=system level=alert vd="root" user="hford" ui=https(172.16.86.1) action=login status=failed reason="passwd_invalid" msg="Administrator hford login failed from https(172.16.86.1) because of invalid password" 5: date=2014-06-28 time=13:59:00 logid=0103026003 type=event subtype=router level=information vd="root" interface="port3" total=101 used=1 msg="DHCP statistics" 6: date=2014-06-28 time=13:58:20 logid=0100040704 type=event subtype=system level=notice vd="root" action="perf-stats" cpu=0 mem=29 totalsession=63 msg="Performance statistics" 7: date=2014-06-28 time=13:57:36 logid=0100032002 type=event subtype=system level=alert vd="root" user="hford" ui=https(172.16.86.1) action=login status=failed reason="passwd_invalid" msg="Administrator hford login failed from https(172.16.86.1) because of invalid password" 8: date=2014-06-28 time=13:53:21 logid=0100040704 type=event subtype=system level=notice vd="root" action="perf-stats" cpu=0 mem=31 totalsession=18 msg="Performance statistics" 9: date=2014-06-28 time=13:51:49 logid=0100032003 type=event subtype=system level=information vd="root" user="jwayne" ui=https(172.16.86.1) action=logout status=success duration=5 reason=exit msg="Administrator jwayne logged out from https(172.16.86.1)" 10: date=2014-06-28 time=13:51:44 logid=0100032001 type=event subtype=system level=information vd="root" user="jwayne" ui=https(172.16.86.1) action=login status=success reason=none profile="super_admin" msg="Administrator jwayne logged in successfully from https(172.16.86.1)"
Muito bem, agora já temos identificação única de todos os usuários de administração, e quando um deles foi demitido ou novas pessoas forem integradas à equipe basta incluir/remover os respectivos usuários do grupo “Information Technology” no AD.
Além disso, o servidor LDAP configurado também poderá ser aproveitado quando começarmos a configurar políticas de Webfilter baseadas em grupo.
Referências
Verifying that traffic is accepted by a security policy
Troubleshooting Tip : debug flow messages “iprope_in_check() check failed, drop” – “Denied by forward policy check” – “reverse path check fail, drop”
LDAP Attributes from Active Directory Users and Computers
13/06/2014
Lojinha dos Pacotes Mortos – Política de Firewall simples
Continuando a série da Lojinha, iniciado aqui. Neste post nosso analista irá criar as regras iniciais da lojinha.
Em primeiro lugar, antes de sair criando as regras vamos associar nossas interfaces à zonas (para que a configuração não vire uma zona!). Isso vai facilitar a visualização da base de regras no firewall, pois ao invés de visualizarmos regras da interface ‘port3’ para ‘port1’ iremos ver regras da ‘LAN’ para ‘WAN’, muito melhor não ?
Seguindo nossa topologia atual, procedemos à criação das zonas.
Como vemos na topologia acima, temos um mapeamento claro entre portas e o nome da zona, abaixo segue configuração.
config system zone # Ou via Web em System:Network, seta pra baixo do lado de 'Create New', Zone
edit "WAN"
set interface "port1"
set intrazone allow
next
end
Fazemos o mesmo para as demais interfaces, conforme o mapeamento da topologia.
Após ajustarmos esses detalhes, vamos criar uma regra liberando acesso Web (HTTP, HTTPS e DNS) para toda a rede interna, lembrando que nosso analista ainda não conhece muito de segurança e por isso está criando uma regra muito permissiva:
config firewall policy # Policy:Policy:Policy
edit 1
set srcintf "LAN"
set dstintf "WAN"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "Web Access"
set logtraffic all
set nat enable
next
end
config log setting # Ativando log na regra de DENY implícita
set fwpolicy-implicit-log enable
end
Agora iremos ativar o DHCP Server na LAN, assim não teremos que configurar IP estático no nosso WinXP e nem nos próximos computadores que forem comprados para a loja.
config system dhcp server # System:Network:Interfaces:Interface X:DHCP Server
edit 1
set default-gateway 10.0.1.254
set dns-service default
set interface "port3"
config ip-range
edit 1
set end-ip 10.0.1.200
set start-ip 10.0.1.100
next
end
set netmask 255.255.255.0
next
end
Ok, hora de iniciar os testes! Ele executa um ping para o DNS do Google (8.8.8.8) e… dá erro 😦
Hora de iniciar o troubleshooting:
FortiGate-VM64 # exec dhcp lease-list # Primeiro descobrimos qual IP foi servido ao WinXP port3 # Também podemos ver em System:Monitor:DHCP Monitor IP MAC-Address Hostname VCI Expiry 10.0.1.100 00:0c:29:33:8e:a4 alexandr-bd97b3 MSFT 5.0 Sun Jun 15 17:26:39 2014 # Agora criamos o debug e o filtro adequado FortiGate-VM64 # diag debug info # Verificamos como está o debug debug output: disable console timestamp: disable console no user log message: disable CLI debug level: 3 # Ok, agora vamos habilitar o debug, definir o filtro e indicar quantos pacotes iremos avaliar diag debug ena # Habilita o debug diag debug flow show console enable # Habilitamos as mensagens de debug na console diag debug flow filter addr 10.0.1.100 # Filtro da origem diag debug flow trace start 100 # Iremos analisar somente os 100 primeiros pacotes # Após criação do filtro e trace foi feito novamente o teste com ping para 8.8.8.8, segue o que apareceu na console id=13 trace_id=1 msg="vd-root received a packet(proto=1, 10.0.1.100:512->8.8.8.8:8) from port3." id=13 trace_id=1 msg="allocate a new session-00000076" id=13 trace_id=1 msg="find a route: gw-10.200.1.254 via port1" id=13 trace_id=1 msg="use addr/intf hash, len=2" id=13 trace_id=1 msg="Denied by forward policy check" id=13 trace_id=2 msg="vd-root received a packet(proto=1, 10.0.1.100:512->8.8.8.8:8) from port3." id=13 trace_id=2 msg="allocate a new session-00000077" id=13 trace_id=2 msg="find a route: gw-10.200.1.254 via port1" id=13 trace_id=2 msg="use addr/intf hash, len=2" id=13 trace_id=2 msg="Denied by forward policy check" id=13 trace_id=3 msg="vd-root received a packet(proto=1, 10.0.1.100:512->8.8.8.8:8) from port3." id=13 trace_id=3 msg="allocate a new session-00000078" id=13 trace_id=3 msg="find a route: gw-10.200.1.254 via port1" id=13 trace_id=3 msg="use addr/intf hash, len=2" id=13 trace_id=3 msg="Denied by forward policy check" id=13 trace_id=4 msg="vd-root received a packet(proto=1, 10.0.1.100:512->8.8.8.8:8) from port3." id=13 trace_id=4 msg="allocate a new session-00000079" id=13 trace_id=4 msg="find a route: gw-10.200.1.254 via port1" id=13 trace_id=4 msg="use addr/intf hash, len=2" id=13 trace_id=4 msg="Denied by forward policy check" FortiGate-VM64 # diag debug disable # Interrompe a execução do debug FortiGate-VM64 # diag debug reset # Retorna os valores de debug para o padrão
Por padrão o Windows manda 4 pacotes de ping por isso vemos 4 blocos de informação acima (que eu separei com uma linha em branco para facilitar a visualização). Como podemos ver na última linha de cada bloco acima os pacotes estão sendo bloqueados por ausência de regras na política: “Denied by forward policy check”, também poderíamos ver isso facilmente pela interface Web em Log & Report:Traffic Log:Forward Traffic.
Agora basta ajustar a regra para liberar também o ping, aproveitando esse ajuste também iremos criar um objeto de rede para colocar como origem, eliminando um “ANY” da regra existente e tornando o ambiente mais seguro.
config firewall address # Firewall Objects:Address:Addresses
edit "net-10.0.1.100/24"
set associated-interface "LAN"
set comment "Internal Network"
set subnet 10.0.1.0 255.255.255.0
end
config firewall policy
edit 1
set srcaddr "net-10.0.1.100/24"
set service "Web Access" "PING"
end
Após configuração do objeto e da regra realizamos novamente o teste e o debug, agora vendo o ping passar sem problemas.
id=13 trace_id=101 msg="vd-root received a packet(proto=1, 10.0.1.100:512->8.8.8.8:8) from port3." id=13 trace_id=101 msg="allocate a new session-00000909" id=13 trace_id=101 msg="find a route: gw-10.200.1.254 via port1" id=13 trace_id=101 msg="use addr/intf hash, len=2" id=13 trace_id=101 msg="find SNAT: IP-10.200.1.1, port-62464" id=13 trace_id=101 msg="Allowed by Policy-1: SNAT" id=13 trace_id=101 msg="SNAT 10.0.1.100->10.200.1.1:62464" id=13 trace_id=102 msg="vd-root received a packet(proto=1, 10.0.1.100:512->8.8.8.8:8) from port3." id=13 trace_id=102 msg="Find an existing session, id-00000909, original direction" id=13 trace_id=102 msg="SNAT 10.0.1.100->10.200.1.1:62464" id=13 trace_id=103 msg="vd-root received a packet(proto=1, 10.0.1.100:512->8.8.8.8:8) from port3." id=13 trace_id=103 msg="Find an existing session, id-00000909, original direction" id=13 trace_id=103 msg="SNAT 10.0.1.100->10.200.1.1:62464" id=13 trace_id=104 msg="vd-root received a packet(proto=1, 10.0.1.100:512->8.8.8.8:8) from port3." id=13 trace_id=104 msg="Find an existing session, id-00000909, original direction" id=13 trace_id=104 msg="SNAT 10.0.1.100->10.200.1.1:62464"
O teste de acesso à Internet também é feito com sucesso e podemos ver a regra em uso pela coluna “Count”.
Ótimo, Internet funcionando! No próximo post da série iremos integrar com o Active Directory para identificar quem está navegando, assim como ativar algumas funcionalidades de Web Content Filter e depois gerar alguns relatórios com o FortiAnalyzer.
Referências
Verifying that traffic is accepted by a security policy
Troubleshooting Tip : debug flow messages “iprope_in_check() check failed, drop” – “Denied by forward policy check” – “reverse path check fail, drop”
20/05/2014
Lojinha dos Pacotes Mortos – Estudo de Caso (Configuração Inicial)
Iniciarei uma série de posts no estilo “estudo de caso” de uma empresa fictícia, a idéia é simular algumas situações comuns (e outras não tão comuns) que acontecem conforme uma empresa cresce e seu ambiente de segurança fica mais complexo com o tempo.
Todos os labs serão efetuados de maneira progressiva, usarei um FortiGate VM 5.0.7 (a não ser que seja indicado o contrário), a idéia é ajudar a comunidade FTNT criando um material que eventualmente possa servir de referência para diversos cenários.
E toda boa história sempre começa com um:
execute factoryreset
Segunda-feira, é dia de inauguração da Lojinha dos Pacotes Mortos e o firewall acabou de chegar, o pobre atendente por acaso também conhece um pouco de firewall e por isso está encarregado de tornar o equipamento operacional com uma configuração mínima, infelizmente ele não conhece muito de segurança mas está aprendendo 🙂
Ele loga na console do equipamento e começa a configuração:
conf sys int
edit port4
set ip 172.16.86.129/24
end
OK, interface de gerência configurada. Ele testa com ping e… nada. Temos que verificar se a interface correta foi configurada, ele sabe o mac address que a porta deveria ter, então ele checa:
FortiGate-VM64 # conf sys int
FortiGate-VM64 (interface) # edit port4
FortiGate-VM64 (port4) # show # Exibe a configuração dessa porta
config system interface
edit "port4"
set vdom "root"
set ip 172.16.86.129 255.255.255.0
set type physical
set snmp-index 4
next
end
FortiGate-VM64 (port4) # get # Exibe valores dinâmicos associados a porta como mac addr
name : port4
vdom : root
cli-conn-status : 0
mode : static
dhcp-relay-service : disable
ip : 172.16.86.129 255.255.255.0
allowaccess : # Nenhum acesso permitido
fail-detect : disable
pptp-client : disable
arpforward : enable
broadcast-forward : disable
bfd : global
l2forward : disable
icmp-redirect : enable
vlanforward : enable
stpforward : disable
ips-sniffer-mode : disable
ident-accept : disable
ipmac : disable
subst : disable
substitute-dst-mac : 00:00:00:00:00:00
status : up
netbios-forward : disable
wins-ip : 0.0.0.0
type : physical
sflow-sampler : disable
sample-rate : 2000
polling-interval : 20
sample-direction : both
explicit-web-proxy : disable
explicit-ftp-proxy : disable
tcp-mss : 0
inbandwidth : 0
outbandwidth : 0
spillover-threshold : 0
weight : 0
external : disable
devindex : 5
description :
alias :
security-mode : none
device-identification: disable
listen-forticlient-connection: disable
vrrp-virtual-mac : disable
vrrp:
snmp-index : 4
secondary-IP : disable
ipv6:
ip6-mode : static
ip6-allowaccess :
ip6-reachable-time : 0
ip6-retrans-time : 0
ip6-hop-limit : 0
ip6-address : ::/0
ip6-extra-addr:
ip6-send-adv : disable
autoconf : disable
dhcp6-relay-service : disable
macaddr : 00:0c:29:57:25:9a
speed : auto
mtu-override : disable
wccp : disable
drop-overlapped-fragment: disable
drop-fragment : disable
FortiGate-VM64 (port4) #
Realiza a ativacão dos serviços de gerenciamento na interface.
conf sys int
edit port4
set allowaccess ping https ssh http
end
Após incluí-los (e o ping responder como esperado), testa o acesso ssh:
draks@loki:~$ ssh admin@172.16.86.129 The authenticity of host '172.16.86.129 (172.16.86.129)' can't be established. RSA key fingerprint is 5f:01:45:5d:65:55:cc:46:48:8f:78:17:cd:08:87:c5. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '172.16.86.129' (RSA) to the list of known hosts. ssh_rsa_verify: RSA modulus too small: 512 < minimum 768 bits key_verify failed for server_host_key draks@loki:~$
Ah, falta a licença! Acessando via interface web (http, pois https só funcionará após a inclusão da licença) siga o seguinte caminho:
- System:Dashboard:Status (ou seja, tela inicial)
- “License Information”
- Clique em “Update”do lado de “Registration Status”
- Procure pelo arquivo de licença e faça o upload, aguarde enquanto o sistema reinicia
- “License Information”
Ao tentar acessar a GUI (interface web) novamente vemos que o redirect para https já acontece naturalmente, porém como ainda não garantimos o acesso à Internet do equipamento vemos a seguinte mensagem:
“License has already been uploaded, please wait for authentication with registration servers”
Prosseguimos a configuração via ssh para viabilizar o acesso a Internet e registro da licença:
conf sys int
edit port1
set ip 10.200.1.1/24 # Essa interface será nossa WAN1
unset allowaccess # Removendo todos os serviços de gerência associados a ela
set allow ping
next
edit port3
set ip 10.0.1.254/24 # Nossa interface LAN
set allow ping
end
conf router static
edit 0
set dev port1
set gateway 10.200.1.254 # Configuração do default gw do nosso ambiente
end
Ok, agora basta executarmos os testes de ping para o gateway e depois para algum host na Internet qualquer:
FortiGate-VM64 # exec ping 10.200.1.254 PING 10.200.1.254 (10.200.1.254): 56 data bytes 64 bytes from 10.200.1.254: icmp_seq=0 ttl=64 time=0.2 ms 64 bytes from 10.200.1.254: icmp_seq=1 ttl=64 time=7.6 ms --- 10.200.1.254 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.2/3.9/7.6 ms FortiGate-VM64 # exec ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=127 time=17.1 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=127 time=17.1 ms --- 8.8.8.8 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 17.1/17.1/17.1 ms FortiGate-VM64 #
Looks good! Agora verificando o status da licença:
FortiGate-VM64 # get sys stat Version: FortiGate-VM64 v5.0,build3608,140409 (GA Patch 7) Virus-DB: 22.00201(2014-05-18 11:26) Extended DB: 1.00000(2012-10-17 15:46) IPS-DB: 4.00498(2014-05-16 20:39) IPS-ETDB: 0.00000(2001-01-01 00:00) Serial-Number: FGVM0000000XXXXX Botnet DB: 1.00535(2014-05-14 20:31) License Status: Pending # O status ainda não atualizou BIOS version: 04000002 Log hard disk: Available Hostname: FortiGate-VM64 Operation Mode: NAT Current virtual domain: root Max number of virtual domains: 1 Virtual domains status: 1 in NAT mode, 0 in TP mode Virtual domain configuration: disable FIPS-CC mode: disable Current HA mode: standalone Branch point: 271 Release Version Information: GA Patch 7 FortiOS x86-64: Yes System time: Mon May 19 08:58:06 2014 FortiGate-VM64 # exec update-now # Vamos forçar a atualização FortiGate-VM64 # exit Connection to 172.16.86.129 closed. draks@loki:~$ ssh admin@172.16.86.129 FortiGate-VM64 # get sys stat Version: FortiGate-VM64 v5.0,build3608,140409 (GA Patch 7) Virus-DB: 22.00201(2014-05-18 11:26) Extended DB: 1.00000(2012-10-17 15:46) IPS-DB: 4.00498(2014-05-16 20:39) IPS-ETDB: 0.00000(2001-01-01 00:00) Serial-Number: FGVM0000000XXXXX Botnet DB: 1.00535(2014-05-14 20:31) License Status: Valid # Licença válida VM Resources: 1 CPU/1 allowed, 976 MB RAM/1024 MB allowed BIOS version: 04000002 Log hard disk: Available Hostname: FortiGate-VM64 Operation Mode: NAT Current virtual domain: root Max number of virtual domains: 1 Virtual domains status: 1 in NAT mode, 0 in TP mode Virtual domain configuration: disable FIPS-CC mode: disable Current HA mode: standalone Branch point: 271 Release Version Information: GA Patch 7 FortiOS x86-64: Yes System time: Mon May 19 08:58:32 2014 FortiGate-VM64 #
Agora ao abrir a GUI vemos tudo verdinho e registrado, ambiente operacional. No próximo post iremos configurar as regras para que a única estação da Lojinha (um surrado Windows XP SP2) consiga acessar a Internet.
Referências
Fortinet Docs Library
22/10/2013
Listar usuários de um grupo no Active Directory
Para listar rapidamente os usuários de um determinado grupo do AD usar o seguinte comando:
dsquery group -samid nomedogrupo | dsget group -members
Contribuição do Luciano!
05/09/2013
Explicando Cross Site Request Forgery
Este post é uma continuação da série que trata de vulnerabilidades em aplicações Web, iniciada com o “Brute Force HTTP em forms com Hydra”, assume-se que você já tenha o ambiente montado e funcionando.
Ao navegar na seção CSRF é apresentado somente um formulário com a opção de troca de senha para o usuário admin, ao testarmos o formulário vemos que os parâmetros são enviados num GET (tanto pela URL que mudou quanto pelo Burp, podemos ver a URL após o envio do formulário abaixo). Mas e daí?
http://192.168.71.129/dvwa/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change#
Para entender a vulnerabilidade temos que imaginar a seguinte situação: Você, usuário administrador de um site qualquer está logado nele (situação normal do teste), em uma determinada seção desse site você tem a possibilidade de trocar sua senha. O que aconteceria se você copiasse a linha acima, alterasse o parâmetro “password” para uma nova senha qualquer e colasse em uma nova aba ? O processo de alteração de senha ocorreria sem problema nenhum, pois você está logado e o comando é a única coisa necessária para trocar a senha.
É nesse ponto que começa o problema, suponha que você está logado no site e em outra aba do seu browser você está navegando em outros sites, você recebe um email ou clica em uma URL que tenha como argumento o seguinte:
http://192.168.71.129/dvwa/vulnerabilities/csrf/?password_new=EVIL_pass&password_conf=EVIL_pass&Change=Change#
Pronto! Uma vez que você estava logado no site, ao clicar nesse link recebido por email ou em alguma outra página qualquer você enviou um comando ao site para trocar sua senha para “EVIL_pass”.
Tudo isso parece muito improvável de acontecer, mas esse foi apenas o exemplo simplificado. No mundo real teríamos algo mais complexo como o seguinte caso:
Você está num site de e-commerce/banco/forum de discussão, em outra aba você está verificando seus emails ou navegando em outros sites quaisquer, em um desses sites existe uma figura que não abre, você nem percebe isso mas no momento que carregou a página você deu um comando direcionada para o site do e-commerce efetuar uma compra que você não esperava, ou uma transferência de dinheiro de uma conta para outra ou ainda trocou sua senha/postou alguma mensagem no forum. Tudo isso pode acontecer se o site de e-comm/banco/forum estiver vulnerável à CSRF, pois a única identificação que ele está usando é o cookie (e como você mandou o comando o pacote formado já inclui o cookie para o site alvo).
Para testar esse conceito no DVWA iremos criar uma página com o link que devemos fazer com que o usuário legítimo clique (ou carregue de alguma outra maneira mais discreta). Crie um arquivo html com o seguinte conteúdo:
<html> <body> <a href="http://192.168.71.129/dvwa/vulnerabilities/csrf/?password_new=EVIL_pass&password_conf=EVIL_pass&Change=Change#">troca</a> </body> </html>
Logue no DVWA em uma aba, na outra abra o arquivo criado localmente e clique no link, faça logoff e teste a nova senha.
Mas ninguém seria tão idiota para clicar num link desses, certo ? Então vamos tornar nosso PoC mais furtivo.
<html> <body> <img style="display:none;" src="http://192.168.71.129/dvwa/vulnerabilities/csrf/?password_new=EVIL_pass&password_conf=EVIL_pass&Change=Change#"> </body> </html>
Dessa vez estamos abusando do comportamento dos browsers em enviar solicitações para imagens sem que seja necessário a intervenção do usuário, poderíamos usar também um iframe, javascript invocando a imagem ou auto envio do request. Teste da seguinte maneira: Troque a senha do admin para “password”, faça logoff e teste a senha. Abra o novo arquivo html, nada irá aparecer mas o comando já terá sido executado (confira no Burp), faça o logoff no DVWA e teste o acesso com a senha nova (que foi trocada sem a sua intervenção, bastando apenas abrir uma página “em branco”).
Esse tipo de ataque pode ser evitado através do uso de tokens randômicos no próprio formulário, que devem ser enviados no POST junto com os outros parâmetros. Como não temos como descobrir qual é esse parâmetro e ele não vai junto por padrão (diferente do cookie que está associado ao site) não temos como gerar uma requisição que pareça legítima.
Referências
HOW TO EXPLOIT CSFR VULNERABILITY(CSRF TUTORIAL)?
Preventing CSRF and XSRF Attacks
Testing for CSRF (OWASP-SM-005)
CSRF Form Generator
03/09/2013
Command Execution no DVWA
Este post é uma continuação do “Brute Force HTTP em forms com Hydra”, assume-se que você já tenha o ambiente montado e funcionando.
A segunda seção do DVWA trata da execução remota de comandos em um formulário web. Seu uso pretendido é de um simples ping, teste o uso colocando o IP da máquina atacante e note que a página retorna o texto exato de um ping não-interativo (roda durante um tempo e depois para, não precisa de nova interação como por ex. o comando passwd). Vendo a saída desse comando nos faz imaginar que todo o texto colocado no textbox é executado sem filtros no servidor web, para testar isso precisamos combinar dois comandos (o texto esperado e um comando não interativo qualquer à nossa escolha) logo basta usar a seguinte string:
192.168.71.130 | whoami
Que nos retorna o usuário “www-data”, que é o usuário que está rodando o serviço do Apache. A partir desse ponto vários outros comandos “post exploitation” podem ser usados, basta lembrar que você não tem direitos de root (todos os comandos rodam no contexto do usuário www-data) e que o comando deve ser não-interativo (não deve solicitar nada após o início de sua execução).
Veja por exemplo o que acontece quando entramos com a string abaixo.
192.168.71.130 | cat /etc/passwd
Esse tipo de falha acontece pois a string enviada pelo usuário é executada sem nenhuma análise no lado do servidor, idealmente o ping não chamaria diretamente o executável ping do SO e muito menos deixaria o caracter “|” passar para a execução final, deveria acontecer alguma sanitização na entrada para somente permitir a string esperada (nesse caso poderia ser realizado uma máscara para reconhecer um formato de IP, qualquer coisa diferente disso seria descartada).
Referências
Testing for Command Injection
Post Exploitation Command Lists
28/08/2013
Brute Force HTTP em forms com Hydra
Hoje vamos exercitar um pouco algumas habilidades de Web Application Security. Em primeiro lugar obtenha o metasploitable (VM com diversas vulnerabilidades, criada especificamente para facilitar o aprendizado de técnicas de segurança), depois a partir de um linux da sua escolha (kali/bt ou samuraiwtf são algumas boas opções) garanta que você tem conectividade com o metasploitable.
No meu lab o metasploitable está com o IP 192.168.71.129, esse é o IP utilizado nos exemplos abaixo.
Ao navegar no IP do metasploitable você terá 5 opções de aplicações Web vulneráveis, o alvo hoje é um dos módulos do DVWA (Damn Vulnerable Web Application), ao selecionar essa opção você é apresentado à um formulário, o acesso (admin/password) está logo abaixo mas vamos tornar isso mais interessante e não vamos simplesmente utilizar essas credenciais.
A primeira técnica que utilizaremos é um simples brute force no formulário, para isso iremos usar o hydra e para montarmos os parâmetros corretamente podemos analisar o código fonte para obter os nomes dos campos de usuário e senha ou interceptar o pacote num proxy local e visualizar os campos esperados diretamente com um exemplo, iremos utilizar a última opção.
Inicie um proxy local (como o burpsuite, localizado no Kali em Applications, Web Applications, Web Application Proxies, burpsuite), verifique em que porta ele está escutando (Proxy, Options), configure o browser para utilizar o mesmo (localhost:8080, na configuração padrão). Desabilite o intercept (Proxy, Intercept) caso contrário você terá que autorizar manualmente cada pacote que passa por ele.
Acesse a interface web do DVWA, note que no burp suas requisições já devem estar aparecendo em Target, Site Map ou Proxy, History. Entre com qualquer texto nos campos Username e Password do formulário de login, veja como a informação é enviada no Burp.
Note que a informação é enviada através de um POST HTTP, perceba a sintaxe da string: “username=teste&password=teste&Login=Login”, nesse caso eu utilizei a string “teste” tanto como usuário quanto senha. Analizando o resultado da falha do login na tela inicial do DVWA também obtemos uma informação importante, caso o login falhe ele amigavelmente retorna a mensagem “Login failed”, iremos usar essa informação para determinar o sucesso ou falha do nosso brute force.
Já temos a string que caracteriza o envio de usuário e senha, também identificamos um texto que indica se o login falhou (uma mudança na página em relação à situação inicial, antes de efetuarmos qualquer tentativa) agora precisamos de uma wordlist. Usando o kali vamos procurar por alguma lista de senhas e escolher a que possui o maior número de linhas:
wc -l `locate passwords` | sort -nr
Analisando rapidamente o arquivo passwords.lst que está na pasta do nmap vemos que ele está no formato adequado (uma senha por linha) e contém as senhas mais comuns, para o propósito desse exercício essa wordlist é suficiente porém o início do arquivo contém muitos comentários (que serão testados inutilmente durante o processo de brute force) vamos criar uma nova wordlist apenas com o que é interessante:
cat /usr/share/nmap/nselib/data/passwords.lst | grep -v \#\!comment > pass.tx
Agora usamos o que coletamos anteriormente na sintaxe do hydra, iremos testar as senhas da wordlist somente para o username “admin”:
hydra -l admin -P pass.txt 192.168.71.129 http-post-form "/dvwa/login.php:username=^USER^&password=^PASS^&Login=Login:Login Failed"
Rode o comando e em poucos segundos deverá aparecer a seguinte mensagem:
Hydra v7.3 (c)2012 by van Hauser/THC & David Maciejak - for legal purposes only Hydra (http://www.thc.org/thc-hydra) starting at 2013-08-27 22:15:49 [DATA] 16 tasks, 1 server, 5084 login tries (l:1/p:5084), ~317 tries per task [DATA] attacking service http-post-form on port 80 [80][www-form] host: 192.168.71.129 login: admin password: password [STATUS] attack finished for 192.168.71.129 (waiting for children to finish) 1 of 1 target successfuly completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished at 2013-08-27 22:15:58 root@kali:~#
Teste a senha encontrada e veja a tela inicial do DVWA.
Navegue para a primeira seção, chamada “Brute Force” e analise o formulário existente, note a diferença no modo como a informação é enviada pelo Burp (dessa vez as credenciais são enviadas usando o método GET), veja que o texto de falha no login também é diferente. Um detalhe importante ao realizar a tentativa de ataque nesse formulário é que dessa vez o usuário deve estar autenticado para ter acesso ao segundo formulário, logo também precisamos incluir a informação da autenticação no DVWA (através da inclusão da informação do SESSION ID, que encontramos no Cookie e podemos ver facilmente no burp)
Realizando os ajustes de parâmetros necessários baseado nas novas informações obtidas com um teste no burp temos o seguinte resultado:
hydra -l admin -P pass.txt 192.168.71.129 http-get-form "/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect.:H=Cookie: security=low; PHPSESSID=a36c8206f365ecea8315a06bf3559792" Hydra v7.3 (c)2012 by van Hauser/THC & David Maciejak - for legal purposes only Hydra (http://www.thc.org/thc-hydra) starting at 2013-08-27 23:18:51 [DATA] 50 tasks, 1 server, 5000 login tries (l:1/p:5000), ~100 tries per task [DATA] attacking service http-get-form on port 80 [80][www-form] host: 192.168.71.129 login: admin password: password [STATUS] attack finished for 192.168.71.129 (waiting for children to finish) 1 of 1 target successfuly completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished at 2013-08-27 23:18:56 root@kali:~#
Mais uma vez conseguimos obter com sucesso, é importante lembrar que assumimos o nome de usuário “admin”, caso precisassemos testar múltiplas senhas para múltiplos usuários o tempo de brute force aumenta drasticamente, além disso outras medidas de segurança como lockar a conta após X logins sem sucesso, um delay no sistema de login que somente permita novas tentativas após Y segundos de uma tentativa mal sucedida (isso também é conhecido como tarpitting), usar um captcha ou até mesmo abandonar totalmente o uso de senhas (como no caso da autenticação SSH usando chaves públicas) são algumas medidas úteis para combater brute force.
Update 31/07/14: Caso você queira visualizar no Burp as requisições que estão sendo feitas pelo Hydra, basta acrescentar a variável de ambiente abaixo.
root@kali:~# export HYDRA_PROXY_HTTP=http://127.0.0.1:8080
Referências
Metasploitable
DVWA
Kali Linux
Samurai WTF
Dead Packets 