5.3 Execução e Resultados obtidos
5.3.3 Captura, Detecção e Contramedidas
Após a inicialização de todos os protótipos e consequentemente configuração do NIDIA domain e User domain, podemos então fazer a simulação de um ataque ao sistema do usuário final.
No processo de simulação, o sistema do usuário é submetido a um ataque de rede baseado em conteúdo. Os ataques de rede baseados em conteúdo fazem uso do campo de dados de um pacote TCP/IP (payload) [34]. O objetivo principal neste tipo de ataque é conseguir acesso privilegiado para capturar/destruir/adulterar informações importantes, implantar um software para atacar outras máquinas utilizando a vítima como um “zumbi” ou utilizar o poder de processamento desta máquina para atividades não autorizadas. Dentre as formas de se efetivar esses ataques utilizando o payload, escolhemos para uso do procedimento de simulação a técnica de adivinhação de senha. Existem diversos programas disponíveis na Internet, para executar este tipo de ataque. Entre os programas encontrados, podemos citar: o Legion, CyberCop Scanner e NTInfoScan. No nosso caso, apesar de estudarmos o uso destes programas, não utilizamos nenhum destes programas. Para nossa simulação de ataque fizemos a modificação de um pacote capturado do sistema do usuário final, incluindo neste, palavras-chave geralmente recorrentes neste tipo de ataque. Desta forma, o pacote modificado que partirá do usuário final chegará ao IDS-NIDIA Remoto para ser analisado. O IDS-NIDIA remoto através do seu processo de análise irá procurar no pacote recebido pela existência de palavras que identifiquem a ocorrência de um ataque.
Neste processo de simulação, o IDS-Client está em execução no sistema do usuário final. Sendo assim, os dados do sistema do usuário final estão sendo capturados e enviados ao IDS-Proxy. O IDS-Proxy recebe estes dados através do seu Web service, IDSProxyWS. A Figura 5.17 apresenta uma mensagem SOAP, capturada pelo IDSProxyWS, contendo
informações capturadas do sistema do usuário final. Esta mensagem foi capturada no momento em que o usuário acessava o site http://www.terra.com.br19.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<e:Envelope xmlns:d="http://www.w3.org/2001/XMLSchema"
xmlns:e="http://schemas.xmlsoap.org/soap/envelope/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <e:Body> <n0:setMessage xmlns:n0="http://systinet.com/wsdl/br/idsproxyws/pck/"> <n0:msg
i:type="d:string"><html lang="pt"><head><title>Terra - Qual é a sua?</title><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><script type="text/javascript" language="javascript1.1"
src="http://www.terra.com.br/ads/capa/tag_comercial.js"></script><script type="text/javascript"
language=JavaScript><!—“Login incorrect” </n0:msg> </n0:setMessage> </e:Body> </e:Envelope>
Figura 5.17: Dados capturados no formato SOAP
A mensagem em formato SOAP recebida pelo IDSProxyWS é encaminhada ao AgentProxy. O IDSProxyWS encaminha esta mensagem por meio de um socket embutido em seu serviço sendMessage. A mensagem ao chegar no Agentproxy é então transformada em mensagem ACL. A Figura 5.18 apresenta uma mensagem ACL, transformada a partir da mensagem SOAP apresentada na Figura 5.17.
(INFORM
:sender ( agent-identifier :name AgentProxy@PC-MAURO:1099/JADE :addresses (sequence http://PC-MAURO:7778/acc ))
:receiver (set ( agent-identifier :name SMA1@192.168.2.25:1099/JADE ) )
:content “<html lang="pt"><head><title>Terra - Qual é a sua?</title><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><script type="text/javascript" language="javascript1.1"
src="http://www.terra.com.br/ads/capa/tag_comercial.js"></script><script type="text/javascript"
language=JavaScript><!—Login incorrect" :language fipa-sl :ontology Messagem-ontology )
Figura 5.18: Dados capturados no formato ACL
A mensagem transformada em formato ACL pelo AgentProxy é encaminhada ao agente SMA do IDS-NIDIA Remoto.
O agente SMA é responsável pela formatação e pela checagem inicial dos dados capturados:
• Da rede local por meio do agente NetSensor; • Do usuário final por meio do IDS-Client.
Isto é realizado através do comportamento SMABehaviour. O comportamento SMABehaviour verifica o número de ocorrências das palavras-chave (armazenadas no arquivo de recurso chaves.txt) dentro da mensagem recebida. Esta verificação é feita através de expressões regulares. A contagem do número de palavras é enviada para o agente
SEA. O trecho de código na Lista de Código 5.9 apresenta um fragmento do método action do comportamento SMABehaviour.
/**
public void action () {
. . .
// get state for Agent myAgent.getState(); // receive the message
ACLMessage msg = myAgent.receive (mt); . . .
try {
enum_chaves = tabela_chaves.keys();
//read the message and count keywords found in the message while (enum_chaves.hasMoreElements()) {
chave = (String) enum_chaves.nextElement(); p = Pattern.compile(chave);
mensagem.setDadosStr (mensagem.getDadosStr()); m = p.matcher (mensagem.getData());
while (m.find()) {
cont_chaves = (Integer) tabela_chaves.get(chave);
tabela_chaves.put(chave, new Integer(cont_chaves.intValue() + 1)); }
}
enum_chaves = tabela_chaves.keys(); //write result in file arq_count try { dados_arqcont.writeBytes(resultado); dados_arqcont.writeByte(13); dados_arqcont.writeByte(10); . . . }
Lista de Código 5.9: Trecho do método action – SMABehaviuor (fragmento)
De posse deste conteúdo, o agente SEA provê o treinamento da rede neural usando o algoritmo de BackPropagation para gerar o vetor de contagem de palavras-chave e o grau de severidade do conteúdo. Estes dados e o identificador da conexão são enviados ao agente MCA. O agente MCA é responsável pela tarefa de administrar as vulnerabilidades encontradas durante o processo de análise.
Os dados capturados e analisados pelo agente SEA quando recebidos pelo agente MCA são encaminhados para o agente BAM para que este possa identificar a real ocorrência de um ataque.
O agente BAM identifica uma possível vulnerabilidade no sistema. O agente BAM através do comportamento BAMBehaviour recebe os dados enviados pelo agente MCA e aplica um filtro nos dados recebidos para identificar a similaridade com as informações armazenadas na base IIDB. Através da análise comparativa entre os dados recebidos e as informações sobre padrões de intrusão armazenada no IIDB, o agente BAM informa ao agente MCA se a conexão de onde os dados foram obtidos é de um atacante ou não. O trecho de código na Lista de Código 5.10 apresenta um fragmento do método action do comportamento BAMBehaviour.
public void action () { ACLMessage msg = myAgent.receive (mt); String Resultado; if (msg != null) { try { ContentElement ce = manager.extractContent (msg); String remetente = null;
if (ce instanceof Message) { Message mensagem = (Message) ce;
remetente = mensagem.getagenteOrigem(); if (!(remetente.indexOf("MCA") < 0)) {
String palavrasChave = mensagem.getEntrada (); Filtrador Filtra = new Filtrador();
Resultado = Filtra.recebeConexaoSuspeita(palavrasChave); // send data go back for the MCA
mensagem.setNomeAtaque (Resultado); mensagem.setagenteOrigem("BAM"); this.envia_dados (mensagem, "MCA"); } } } catch (Exception e) { System.out.println("Error!"); } ... }
Lista de Código 5.10: Trecho do método action - BAMBehaviuor (fragmento)
O Agente BAM ao detectar que o ataque ocorreu retorna ao agente MCA. O agente MCA, então, consulta na base de estratégias e obtém as contramedidas apropriadas a serem tomadas. A notificação e as contramedidas são enviadas para o LSIA e para o AgentProxy. O LSIA avisa o Administrador do Sistema NIDIA e AgentProxy encaminha a informação para o IDSProxyWS para que o IDS-Client possa ser notificado e receber as contramedidas.
A Figura 5.19 apresenta a notificação recebida pelo IDS-Client.
A Figura 5.19 apresenta o resultado da captura do pacote formatado por nós no processo de simulação de ataque. Na nossa simulação, indicamos na mensagem enviada ao IDS-NIDIA Remoto, o IP da maquina que estava tentando descobrir a senha do usuário final. Este IP é usado na Contramedida a ser tomada pelo IDS-Client. Uma das contramedidas armazenadas no banco de estratégias é encerrar a comunicação com este IP. Esta contramedida é tomada pelo IDS-Client, inibindo todos os pacotes que vem deste IP suspeito. A facility Countermeasures executa esta ação e recusa todos os pacotes que são oriundos deste IP.