Mostrando postagens com marcador seguranca_de_rede. Mostrar todas as postagens
Mostrando postagens com marcador seguranca_de_rede. Mostrar todas as postagens

quarta-feira, 7 de julho de 2010

IPFW - Criação de regras no IPFIREWALL

Para este artigo foi utilizado o FreeBSD 7.2 e o IPFW2.

Se o seu servidor FreeBSD ainda não tem o IPFW compilado no kernel, então acesse o link abaixo e veja como configura-lo e instala-lo em seu kernel:


Inicialmente é bom informar as duas formas de funcionamento do firewall IPFW, no que diz respeito ao tratamento que é dado aos pacotes que trafegam por ele.

Os modos em que o IPFIREWALL pode funcionar são:

Modo Filtro de pacotes:

- Restringir o tráfego baseado no endereço IP de origem ou destino, através das portas de comunicação TCP ou UDP.


Modo Firewall stateful:

- Herda as característica do firewall em modo filtro de pacotes e implementa o filtro por estado da sessão; Nesse caso o firewall armazena os estados das conexões e aplica o filtro de bloqueio ou permissão para o pacote passante com base nesses estados. O firewall armazena em uma tabela os detalhes das conexões existentes (IP de origem, IP de destino, porta de origem, porta de destino, tempo restante para essa conexão na tabela stateful)  que estão sendo efetuadas no momento e inspeciona o tráfego evitando que pacotes ilegítimos tenham acesso a serviços de rede ganhando mais velocidade e segurança, evitando, por exemplo, técnicas hacker como: ip spoofing.

Construção do conjunto de regras(Ruleset):

Primeiramente será apresentado o conjunto de regras que são pré-definidas para o IPFW, essas são regras que já vem prontas para serem utlizadas no Firewall.

Ruleset pré-definidas:

A variável do /etc/rc.conf que gerencia qual o conjunto de regras pré-definidas será carregada pelo firewall é a firewall_type=" " . Exitem 5 tipos de regras pré-definidas disponíveis:

"OPEN" -  O firewall permiti todo tráfego em suas interfaces, ou seja, não bloqueia nenhuma tráfego.

"CLIENT" - Essa definição de tipo de firewall (firewall_type) permite todo o tráfego proveniente da rede local (por exemplo, uma rede interna atrás de NAT) pra ela mesma. Bloqueia pacotes fragmentados, permite que mensagens de email, resoluções de nomes (DNS) e NTP sejam enviadas pra dentro e fora da rede, e não permite nenhuma máquina que esteja fora da rede interna iniciar conexões TCP com máquinas dentro da rede. Se a rede estiver por trás de uma implementação básica de NAT sem nenhuma opção de proxie carregada isso já seria impossível. Esse tipo de firewall funciona com política aberta ou fechada, definida no kernel, ou seja, não faz diferença se você colocou IPFIREWALL_DEFAULT_TO_ACCEPT ou IPFIREWALL_DEFAULT_TO_DENY como padrão.

"SIMPLE" - Esse tipo de firewall é uma contradição. Apesar do nome SIMPLE, ele é muito mais complexo que a definição CLIENT, e requer que o usuário tenha algum conhecimento nos padrões RFC de Internet pra poder entender suas definições de regras de firewall. Essa regra vai evitar spoofing (técnica onde uma máquina se faz passar por outra, alterando seu endereçamento IP) não permitindo a entrada de nenhum pacote que tenha um endereço de retorno igual ao endereço de qualquer host dentro da rede interna. Vai bloquear todos os pacotes endereçados como de redes privadas, conforme definido na RFC 1928, evitando o tráfego pra dentro ou fora da rede, e vai bloquear ainda todas as redes não-roteaveis, conforme definido no Internet-Drafts da IETF (disponível em http://www.ietf.org/internet-drafts/draft-manning-dsua-03.txt). Esse tipo de firewall vai permitir tráfego de e-mail, de WWW, de DNS, e NTP, e vai permitir também pacotes fragmentados, e em relação às conexões TCP iniciadas por hosts fora da rede, o firewall não vai apenas bloquear, como na definição CLIENT, vai também logar todas essas tentativas.

"CLOSED" - Tecnicamente essa definição não é um conjunto de regras de firewall, porque não adiciona nenhuma regra. Na verdade, aqui acontece tudo que nós insistimos que você deve evitar, ou seja, estabelece uma política fechada, negando todo e qualquer tráfego da rede (exceto o tráfego via lo0 que nós vimos anteriormente que é controlado por padrão). Essa definição simplesmente desabilita todos os serviços IP na rede, a não ser que no seu kernel você tenha adicionado a regra de política aberta. Então, ajustar o firewall pra CLOSED vai ser necessário em casos *extremos* onde você prefere (ainda que temporariamente) tirar toda a sua rede de funcionamento. Ou seja, não defina como padrão no rc.conf.

"UNKNOWN" - Desabilita o carregamento de regras do ipfirewall.

Agora iremos abordar a construção do conjuto de regras personalizaveis para o IPFW utilizaremos neste momento o modo filtro de pacotes. Para isso é necessário criar um arquivo onde será colocado as nossas regras, que será onde o IPFW irá ler as mesmas. Para isso iremos criar o arquivo de regras, como mostra abaixo:

# mkdir -p /tools/firewall

# touch /tools/firewall/rules.fw

Iremos editar o arquivo rules.fw:
# vi /tools/firewall/rules.fw

Agora iremos começar a escrever as nossas regras, mas como é a sintaxe para se escrever as regras no IPFIREWALL?
Abaixo uma breve explicação sobre a sintaxe das regras do IPFW:
CMD [número_regra] [prob probalilidade] ação [log [logamount número] ] corpo_regra

CMD =
add, delete(Os mais utilizados)


add: adicionar uma nova regra ao firewall;
delete: deletar uma regra do firewall;

[número_regra]
=
Quando um pacote entra no firewall ele é comparado com a primeira regra no conjunto de regras e avança uma regra de cada vez, que se deslocam de cima para baixo do conjunto em ordem crescente do número de seqüência das regras. Quando o pacote se adequa a seleção de parâmetros de uma regra, o campo de ação é executada e a busca do conjunto de regras termina para o pacote. Isto é referido como "o primeiro que se adequa ganha" do metodo de procura. Se o pacote não corresponde a nenhuma das regras, ele é pego pela regra padrão obrigatório IPFW, número 65.535, que nega todos os pacotes e descarta-los sem qualquer resposta de volta para o remetente, a não ser que se coloque na regra para que o IPFW envie uma mensagem de resposta.
O número de regras varia de 1 a 65535 e indica a sequência em que as regras serão processadas, sendo que a regra de número 65535 é a padrão utilizada pelo firewall, ou seja exclusiva do firewall, essa regra padrão pode ser aceitar tudo(tcp, udp e ip) de qualquer lugar para qualquer lugar ou negar tudo(todos os protocolos tcp, udp e ip) de qualquer lugar para qualquer lugar. Essa regra é especificada antes da compilação do firewall é uma linha que você especifica no kernel IPFIREWALL_DEFAULT_TO_ACCEPT ou IPFIREWALL_DEFAULT_TO_DENY.


[prob probabilidade]
=
Uso opcional, Define uma probabilidade para aplicar a regra. Varia de 0 a 1.

ação =
"allow, accept, pass e permit"
Tem a mesma função, aceitar pacote que chegam ao firewall e que se adequem a regra. E a leitura das regras termina.

"deny, drop
"
Tem a mesmo função, descartar pacotes silenciosamente(sem enviar resposta ao remetente) que correspondem a regra. E a leitura das regras termina.

"check-state"- Checa o pacote contra um conjunto de regras dinâmicas, isto é para modo statefull do firewall que ainda iremos ver.

"count" - Todos os pacotes que combinarem com uma regra cuja ação seja "count", determinará que o ipfirewall incremente o contagem de pacotes, ou seja, a saída de "ipfw show" indicará mais uma ocorrência de pacotes nessa regra. Motivos estatísticos óbvios. O processamento das regras do firewall continuam a buscar por outras regras que combinem com os pacotes.

"divert porta" - Redireciona o pacote para a porta especificada, utilizando um socket "divert". Pode ser especificado número ou nome, veja /etc/services.

"fwd ip[,porta]" - Sinônimo de forward, encaminha o pacote para o ip especificado. Se o ip for local será encaminhado para a porta especificada, se o ip não for local a porta será ignorada. O pacote não é alterado, e isto inclui o ip de destino, então se o pacote for encaminhado para outro host provavelmente será rejeitado. Caso seja encaminhado para um ip local, desta máquina, o socket que irá receber o pacote terá o seu endereço alterado para coincidir com o endereço de destino do pacote, aceitando desta forma o mesmo.

"pipe número" - Passa o pacote através de um "pipe" dummynet, para controle de tráfego.

"queue número" - Passa o pacote para uma "queue" dummynet, para controle de tráfego utilizando WF2Q+.

"reset" - Quando um pacote encontra uma regra com essa ação, o pacote é bloqueado, e o ipfirewall tenta enviar um sinal (flag) de TCP Reset (RST) pro endereço de origem do pacote. O processamento das regras pra esse pacote termina. Como esse tipo de regra apenas se aplica pra pacotes TCP, o protocolo especificado na regra deve ser "tcp", para que apenas tais pacotes sejam processados por essa regra, e não todos (proto "all") os protocolos de pacotes IP.

"skipto " - Todos os pacotes que combinem com uma regra cuja ação seja "skipto " vão fazer com que o ipfirewall(4) continue processando esse pacote e buscando ocorrência nas regras que sejam de ordem maior ou igual ao indicado pela ação.

"reject" - Essa ação é pouco utilizada atualmente. Quando um pacote combina com uma regra cuja ação seja "reject", então o ipfirewall(4) bloqueia esse pacote e responde com uma mensagem ICMP do tipo "host unreachable", dando a impressão que a máquina se encontra fora da rede. Essa é uma forma não silenciosa de negar o tráfego pelo firewall, contudo, assim como a ação "reset", essa ação também aumenta o uso da sua banda de rede.

"tee porta" - Aceita o pacote e envia uma cópia do mesmo para a porta especificada, via socket "divert".

"unreach código" - Descarta o pacote, e tenta enviar uma resposta "ICMP unreachable" com o código especificado. O código deve ser entre 0 e 255, ou alguma destas palavras chave: net, host, protocol, port, needfrag, srcfail, net-unknown, host-unknown, isolated, net-prohib, host-prohib, tosnet, toshost, filter-prohib, host-precedence ou precedence-cutoff.

[log [logamount número]] =
Uso opcional, caso mencionada a palavra log, cada vez que um pacote coincidir com esta regra será feito um log através do syslog.

corpo_regra =
Contém uma ou mais exigências que o pacote precisa coincidir para a regra ser atendida. Essa especificação pode incluir endereço ip de origem, endereço ip de destino, porta de origem, porta de destino, protocolo, interface de rede de entrada, interface de rede de saída etc. O corpo da regra pode possuir uma ou mais opções. Essas opções podem ser precedidas de "not", como negação, ou serem agrupadas em blocos OR, entre chaves, por exemplo: { dst-port 50 or dst-port 51 or not src-port 52 }. Descreveremos cada uma dela abaixo:

"dst-ip endereço" - Endereço IP de destino do pacote.
"dst-port porta" - Porta(s) de destino do pacote. Se for especificada mais de uma porta, separar por vírgula (50, 51, 52), ou em faixa de portas (50-60).
"established"
Se o pacote tiver os bits RST ou ACK.
"frag"
fragmentos de pacotes, não sendo o primeiro fragmento.
"gid grupo"
Pacotes TCP ou UDP enviados ou recebidos pelo grupo. O grupo pode ser especificado pelo nome ou pelo GID.
"icmptypes tipo"
Tipo(s) de pacotes ICMP. Se for mais de um, separar por vírgula. Os tipos podem ser: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) e address mask reply (18).
"in | out"
Pacotes de entrada ou de saída. Note que isto significa que os pacotes estão entrando ou saindo da máquina, então mesmo que um pacote venha da rede interna, estará entrando na máquina antes de sair.
"keep-state"
Quando um pacote coincidir com uma regra que tiver esta opção, será criada uma regra dinâmica, cujo comportamento será coincidir o tráfego bidirecional entre este ip/porta de origem e ip/porta de destino, no mesmo protocolo. A regra dinâmica expira após um certo tempo. Dessa forma, pode-se definir uma regra "check-state" anterior a esta, liberando este fluxo de pacotes, e teremos um firewall "stateful".
"limit {ip-origem | porta-origem | ip-destino | porta-destino} número"
Serão permitidas apenas o número especificado de conexões com os parâmetros especificados.
"mac mac-destino mac-origem"
Pacotes com o endereço MAC de destino e/ou de origem especificados. Se não for especificado algum deverá ser usada a palavra "any", para coincidir com todos os endereços.
"proto protocolo"
Pacotes com o protocolo (IP) especificado. Veja /etc/protocols.
"recv interface | xmit interface | via interface"
Pacotes recebidos pela interface de rede especificada (recv xl0), pacotes transmitidos pela interface especificada (xmit fxp0), ou pacotes passando pela interface, independentemente de entrar ou sair (via xl0). Quando xmit for utilizado é requerida a opção "out", já que o pacote estará saindo.
"setup"
Pacotes com o bit SYN mas sem o bit ACK.
"src-ip endereço"
Endereço IP de origem do pacote.
"src-port porta"
Porta(s) de origem do pacote.
"tcpflags flags"
Flags dos pacotes TCP, separadas por vírgula. As possíveis são: fin, syn, rst, psh, ack e urg. A negação pode ser feita por um "!".
"uid usuário"
Pacotes TCP ou UDP enviados ou recebidos pelo usuário. O usuário pode ser especificado pelo username ou pelo UID.
"vrrevpath"
Pra pacotes de entrada, é feita uma consulta ao endereço de origem na tabela de roteamento. Se a interface na qual o pacote entrou é a mesma de saída especificada pela rota, então a regra coincide. Isto pode ser utilizado para criar regras anti-spoofing. Os pacotes de saída não são submetidos à verificação.
PARA UMA LEITURA MAIS AVANÇADA ACESSE OS FONTES DO TEXTO ACIMA:
http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO

http://www2.unijui.tche.br/~heini/freebsd/ipfw2.html

Exemplos práticos:
### Liebrar udp da rede 192.168.0.0/24  para a rede 192.168.1.0/24
add 00100 allow udp from 192.168.0.0/24 to 192.168.1.0/24 in
### Regra para o INPUT do trafego SSH
add 00200 allow tcp from any to 192.168.1.1/32 22 in
### Regras para o INPUT do VNC da rede 192.168.1.0/24 para VNCs na rede 192.168.1.0/24
add 00300 allow tcp from 192.168.1.0/24 to 192.168.0.0/24 5900 in setup
### Bloquear todos os pacotes vindo de qualquer lugar para qualquer lugar e logar os mesmo
add 64534 deny log all from any to any
Resumindo a sintaxe das regras no IPFW:

# O comando entre colchetes é opcional
command   [rule number]   action   proto   from   source[port]   to   destination[port] [Complemento: in,out,via... etc]

segunda-feira, 28 de junho de 2010

Snorby - Instalação do frontend para snort

Utilizei para esta implementação o snorby 1.1.3 , ambos sobre o FreeBSD 7.2, mais detalhes sobre essa aplicação:

- Snorby 1.1.3:

O snorby é um dos frontends utilizados para visualizar os alertas gerados pelo snort, ele também contém gráficos e estatisticas dos alertas coletados pelo snort. Possui uma interface bastante intuitiva e moderna. Conheça-o http://snorby.org/.

Particulamente gostei muito deste frontend, ele ainda esta em fase de desenvolvimento, mas já dar para utiliza-lo em produção. Veja o report bug do mesmo com a identificação de erros e suas devidas correções e ferramentas a serem implementadas: http://github.com/mephux/Snorby/issues.

O Snorby é desenvolvido utilizando a linguagem de programação ruby on rails para plataforma web. Outro ótimo frontend é o BASE(http://base.secureideas.net/) fork do antigo ACID ambos são desenvolvidos utilizando a ligaugem de programação php.

Vamos para a instalação:

- Programas/dependênias para instalação do Snorby(Instalaremos através do ports):

git-1.7.1 Distributed source code management tool
mysql-client-5.5.4 Multithreaded SQL database (client)
mysql-server-5.5.4 Multithreaded SQL database (server)
ruby18-gems-1.3.7 Package management framework for the Ruby language
ruby18-iconv-1.8.7.248,1 An iconv wrapper class for Ruby

- E através do gem(Gerenciador de pacote do ruby) instalaremos outros pacotes:

- prawn
- rake
- rails
- dbd-mysql
- mysql

- E finalmente através do git:

- Snorby

- Vamos a instalação dos programas e dependencias(No configure do make não marque as opções que aparecerão desmarcadas e deixe as que já estão marcadas):

Instalação do mysql:

# cd /usr/ports/databases/mysql55-server/ && make install clean

Instalação do git:

# cd /usr/ports/devel/git/ && make install clean

Instalação do ruby-gems:

# cd /usr/ports/devel/ruby-gems/ && make install clean

Instalação do ruby-iconv:

# cd /usr/ports/converters/ruby-iconv/ && make install clean

- Instalação dos pacotes através do gem:

# gem install prawn


# gem install rake


# gem install rails


# gem install dbd-mysql


# gem install mysql

Vamos instalar o aplicativo Snorby, instale o mesmo na pasta /usr/local/www então siga o passo a passo:
OBS.: O git utiliza uma porta especifica para realizar o download verifique o seu firewall.

# cd /usr/local/www/ && git clone git://github.com/mephux/Snorby.git

Pronto se tudo ocorreu sem problemas o servidor já se encontra com o snorby instalado, iremos para os pré-requisitos de seu funcionamento:

- Primeiro: Configure o seu snort com banco mysql.

- Segundo: O snorby terá um banco, criado automaticamente pelo rake setup(comando que veremos mais adiante);

- Terceiro : O mysql deve estar iniciado e com permissões de acesso para usuário e seu banco de dados snorby, pois, agora será utilizado somente um único banco que armazenará informações tanto do snort quanto do snorby.

- Quarto: O banco snorby/snort é criado automaticamente pelo rake setup(comando que veremos mais adiante) no localhost ou seja na máquina em que foi instalado o snorby. Não consegui descobri onde alterar essa config.

OBS.: Der permissão para o usuário do banco snorny, para o host localhost, exemplo:

na console do mysql:

GRANT ALL PRIVILEGES ON snorby.* TO snorby@'localhost' IDENTIFIED BY 'senhaDoBDSnorby' WITH GRANT OPTION;

- Após estes passos iremos configurar dois arquivos do Snorby que se encontram em /usr/local/www/Snorby/config, são eles o database.yml e email.yml;

# cp /usr/local/www/Snorby/config/database.yml.example /usr/local/www/Snorby/config/database.yml


# cp /usr/local/www/Snorby/config/email.yml.example /usr/local/www/Snorby/config/email.yml

- Configure os mesmos, o database.yml configura aonde será instalado o banco de dados do snorby e o email.yml confgs para enviar alertas para o email.

Vamos ao processo de confguração automatica do Snorby(Instale os requerimentos adicionais do gem, ele irá informa na console quais são os requerimentos, para carregar o Snorby)

ATENÇÂO: Nessa versão do snoby(1.1.3) a instalação automática só é executada com sucesso se for configurado no arquivo database.yml o BD como localhost e dada as devidas permissões para o usuário que você passa neste mesmo arquivo citado. Aqui onde trabalho configurei como localhost depois instalei o snprby e após instalação executei o script mysql do snorby em outro servidor mysql da minha rede e depois fiz os devidos apontamentos database.yml para o servidor mysql remoto da minha rede.

# cd /usr/local/www/Snorby && rake gems:install


# cd /usr/local/www/Snorby && rake snorby:setup RAILS_ENV=production

Se for a primeira instalação execute também:

# cd /usr/local/www/Snorby && rake snorby:update RAILS_ENV=production


# cd /usr/local/www/Snorby && rake snorby:reset RAILS_ENV=production # ALL DATA WILL BE LOST

Start Snorby:

# ruby18 script/server -e production -b 127.0.0.1 -p 80 -d

-b = bind address [Default: loopback]
-p = port number [Default: 3000]
-e = environment
-d = Run server as daemon

The default User Name and Password for Snorby:

User: snorby
Password: admin

FONTE:

http://github.com/mephux/Snorby

http://wiki.github.com/mephux/Snorby/snorby-recipe-with-barnyard2-unified2-and-apache-jjc


Fiz um script para colocar na inicialização do sistema operacional o snorby, como é FreeBSD este script deve ser colocado em /usr/local/etc/rc.d/:

#!/bin/sh
#
# $FreeBSD: snorby
#

# PROVIDE: snorby
# BY: Leonardo Couto Conrado
# IN: 11.06.2010

. /etc/rc.subr

name="snorby"

rcvar="`set_rcvar`"

load_rc_config $name

: ${snorby_enable="NO"}
: ${snorby_port_listen="80"}
: ${snorby_bind_addr="127.0.0.1"}
: ${snorby_environment="production"}


command="cd /usr/local/www/Snorby && /usr/local/bin/ruby18"
command_args="script/server -e ${snorby_environment} -b ${snorby_bind_addr} -p ${snorby_port_listen} -d"
procname="/usr/local/bin/ruby18"
pidfile="/var/run/${name}.pid"

run_rc_command "$1"

E no /etc/rc.conf colocamos as seguintes linhas:

#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
# SNORBY
#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
snorby_enable="YES"
snorby_port_listen="80"
snorby_bind_addr="127.0.0.1"
snorby_environment="production"

Pronto agora já temos o snorby instalado e na inicialização do SO.

segunda-feira, 21 de junho de 2010

Snort - Instalação

Utilizei para esta implementação o snort 2.8.6 , ambos sobre o FreeBSD 7.2, mais detalhes sobre essa aplicação:

- Snort 2.8.6:

http://conteudoopensource.blogspot.com/2010/06/snort-snort-286-em-modo-promiuscuo.html

O snort pode ser utilizado tanto para detectar ataques(IDS colocando-o em modo promiscuo utilizando por exemplo o port mirror no switch) quanto também para detectar e bloquear os ataques(IPS colocando-o no modo in-line no gateway, firewall de sua rede.), neste tutorial estou utilizando o snort em modo promiscuo realizei um port mirror da porta dos gateways da rede e os alertas estão sendo registrados em um banco mysql.

Bem, vamos dar o start-up em nosso assunto principal que é a instalação do snort:

OBS.: Para utilizar o output(alertas e logs) direcionado para banco de dados mysql, vc antes deverá instalar o mysql e suas bibliotecas.

1) Baixe o snort http://www.snort.org/downloads. Descompacte o tallbar(arquivo tar.gz) do snort;

2) Dentro da pasta descompactada, iremos iniciar a configuração, compilção e instalação:

-> Configure com output para DB mysql:


#./configure --with-mysql --with-mysql-includes=/usr/local/include/mysql --with-mysql-libraries=/usr/local/lib/mysql --prefix=/usr/local/snort


# make


# make install


3) Criar estruturas de diretórios do snort

# mkdir /usr/local/etc/snort

Na pasta descompactada do snort, copie os arquivos do diretório conforme abaixo:

# cp /home/leonardo.conrado/snort-2.8.6/etc/* /usr/local/etc/snort/


4) Copiar as rules que deve ser baixados do site snort.org(Vc deve se cadastrar antes) e coloque-as em /usr/local/snort/rules(crie a pasta rules se não existir)

# cp /home/leonardo.conrado/snortrules-snapshot-2860/* /usr/local/snort/rules

5) Configurar o snort, conforme abaixo:

# vi /usr/local/etc/snort/snort.conf

Configure as principais variáveis, veja os exemplos já configurado:

###################################################
# Step #1: Set the network variables. For more information, see README.variables
###################################################
# Setup the network addresses you are protecting
var HOME_NET [192.168.1.0/24]

# List of DNS servers on your network
var DNS_SERVERS [192.168.0.60/32,187.84.92.1,187.84.92.2/32]

# List of web servers on your network
var HTTP_SERVERS [192.168.0.64/32]

# List of sql servers on your network
var SQL_SERVERS [192.168.0.65/32]

# List of SMTP servers on your network
var SMTP_SERVERS 187.84.92.99

# Path to your rules files (this can be a relative path)
# Note for Windows users: You are advised to make this an absolute path,
# such as: c:\snort\rules
var RULE_PATH /usr/local/snort/rules/rules
var SO_RULE_PATH /usr/local/snort/rules/so_rules
var PREPROC_RULE_PATH /usr/local/snort/rules/preproc_rules

###################################################
# Step #6: Configure output plugins
# For more information, see Snort Manual, Configuring Snort - Output Modules
###################################################

# syslog
output alert_syslog: LOG_AUTH LOG_ALERT

# pcap
# output log_tcpdump: tcpdump.log

# database
output database: alert, mysql,user=snort password=senhaBancoSnortmysql dbname=snort host=192.168.0.65

output database: log, mysql,dbname=snort username=snort password=senhaBancoSnortmysql host=192.168.0.65

###################################################
# Step #7: Customize your rule set
# For more information, see Snort Manual, Writing Snort Rules
###################################################
…

Para debugar habilitei também o output dos alertas e logs do snort para o syslog e sua saida esta sendo escrita no /var/log/messages.
6) Para testar inicie o snort, acompanhe a saída e se ocorrer algum erro a inicialização será interrompida e vc poderá verificar qual o motivo para o erro:

# /usr/local/snort/bin/snort -c /usr/local/etc/snort/snort.conf


Para coloca-lo na inicialização do S.O e setar alguns parametros como interface que o snort irá escutar, coloca o seu processo em back ground etc, então criei um script para o rc.d(lembrando que neste caso estou utilizando o FreeBSD). Abaixo o script snort dentro da pasta /usr/local/etc/rc.d:

#!/bin/sh
Exp $

# PROVIDE: snort
# REQUIRE: DAEMON
# BEFORE: LOGIN
# KEYWORD: shutdown

. /etc/rc.subr

name="snort"

rcvar="`set_rcvar`"

load_rc_config $name

: ${snort_enable="YES"}
: ${snort_if_listen="re0"}
: ${snort_config_file="/usr/local/etc/snort/snort.conf"}

command="/usr/local/sbin/snort/${name}"
command_args="-q -D -i ${snort_if_listen} -c ${snort_config_file}"
procname="/usr/local/sbin/snort/snort"
pidfile="/var/run/${name}_${snort_if_listen}.pid"

run_rc_command "$1"


Já no arquivo /etc/rc.conf, ahbilito o mesmo para carregar na inicialização e seto alguns parametros:

#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
# SNORT
#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
snort_enable="YES"
snort_if_listen="re1"
snort_config_file="/usr/local/etc/snort/snort.conf"


Pronto! Agora você já possui o snort na inicialização...

Observações:

- No arquivo snort.conf habilite rules/regras que sejam relevantes a sua rede, por exemplo, você não precisa deixar habilitada a regra para serviços mysql se você não possui nenhum servidor mysql em sua rede... Outra coisa importante também, é definir bem as váriaveis do seu arquivo snort.conf, para que se tenha um bom filtro e que se colete alertas que realmente sejam importantes para a segurança de sua rede e também para se evitar logs que sejam falsos positivo.

- Sempre mantenha suas regras atualizadas, para autmatizar essa atualização de regras utilizo o aplicativo oinkmaster pesquise como instala-lo e configura-lo é bastante simples.

- Utilize as regras do Emerging Threats que é uma comunidade de projetos open sources que desenvolve assinaturas/regras para o snort e que também possui outros projetos open sources ligados a segurança da informação. Conheça http://www.emergingthreats.net/index.php/about-et-mainmenu-43.html

- Existe um arquivo na pasta etc do snort chamado threshold.conf lá você poderá colocar limites para alertas que são gerados com muita frequência ocasionando em alto output se preferir você poderá suprimi-los também utilizando este arquivo threshold.conf.

quarta-feira, 16 de junho de 2010

Snort - Introdução ao IDS/IPS Snort

O Snort é um sistema de detecção de invasão baseado em rede (SDIR) de código fonte aberto, possuindo muitos recursos. Ele é sniffer que tem como diferencial a capacidade de inspecionar o payload do pacote, área que contém os dados do mesmo, fazendo o registros dos pacotes, além de detectar as invasões.

O Snort é um sistema avançado capaz de detectar quando um ataque
está sendo realizado e, baseado nas características do ataque, alterar ou remodelar sua configuração de acordo com as necessidades, e até avisar ao administrador do ambiente sobre o ataque.

Considera-se o Snort um SDI ligthweight, ou seja, ele pode ser colocado em funcionamento com muito pouco esforço tanto no sentido computacional quanto no sentido configuração e suporte.
Um característica marcante do Snort é a facilidade de criação de assinaturas de ataques. Profissionais da área de segurança da informação sabem da velocidade que os eventos ocorrem no mundo virtual. A prontidão, exatidão e rapidez são assuntos essenciais em se tratando de segurança. Como o Snort é um sistema de código aberto e apresenta linguagem fácil de criação de assinaturas, permite a pronta criação e adição de uma nova assinatura de ataque por parte do
administrador.

O Snort é uma ótima ferramenta, mas como todo aplicativo deve ser bem implementada. Devem ser aplicadas somente as assinaturas de ataques relevantes a realidade da rede. Por exemplo, não é necessário monitorar ataque a banco de dados MySQL se ele não se encontra em uso, o que ocasionaria apenas alertas irrelevantes. Além disso o banco de assinaturas deve estar constantemente atualizado evitando assim que ataques passem desapercebidos. O administrador tendo esses cuidados evita ou minimiza os falsos positivos e falsos negativos.

O profissional responsável pela rede deve certificar-se que o sistema onde o Snort esta operando é o mais seguro possível, ou seja, deve-se esta atendo a segurança do sistema operacional onde o Snort esta rodando. Uma invasão à máquina SDI invalida qualquer alerta do mesmo.
O Snort é um sistema que não requer grandes recursos de hardware. Os recursos de hardware necessário para o sistema operacional em uso atende ao Snort.

O Snort foi projetado para ser executado em uma grande gama de sistemas entre eles Linux, FreeBSD, NetBSD, OpenBSD, Solaris, MacOS, Windows, entre outros.

Existem alguns programas opcionais que podem ser instalados para melhorar/facilitar a administração do sistema. Cita-se os aplicativos para o mundo Linux. Os softwares são:

http://www.snort.org/downloads/additional-downloads/

FONTE: http://www.ginux.ufla.br/files/mono-BrunoSantos.pdf

segunda-feira, 31 de maio de 2010

IPFW - Instalação do IPFW com suporte ao IPFW2(+IPv6) sobre FreeBSD

Se ainda não conhece o IPFW leia o artigo com a introdução do mesmo no link abaixo:
http://conteudoopensource.blogspot.com/2010/05/introducao-ao-ipfw-instalando.html

Dica:
Esse processo do make para recompilar e instalar o novo kernel modificado, exige um pouco de memória RAM em torno de 292 MB, para não acabar utilizando o swap, se não houver memória suficiente o processo será morto pelo kernel e lançará uma excessão ocasionando na parada da instalação do novo kernel. Outro ponto importante é do espaço livre em disco utilize pelo menos 5 GB para a participação do seu FreeBSD.

O IPFW2 já vem nativo apartir da versão 5x do FreeBSD, não sendo necessária nenhuma modificação no kernel(inclusão do options IPFW2 no kernel) do sistema para utilizar o mesmo. A inclusão desse aopção acontecia apenas na versão 4x e anteriores do FreeBSD.

Utilizando para este artigo o FreeBSD 7.2


# cd /usr/src/sbin/ipfw

se o diretorio acima não existir você precisará instalar esses src's através do comando sysintall:

# sysinstall

Navegue pelo menu do sysinstall configure > distributions e marque a opção:

[ X ] ports

depois em configure > distributions > src maque as opções:

[ X ] base
[ X ] lib
[ X ] sbin
[ X ] sys

# vi /etc/make.conf

---> Insira:
IPFW2=true

Voltando ao userland :

# cd /usr/src/sbin/ipfw/

Recompile o ipfw:

# make clean


# make -DIPFW2


# make -DIPFW2 install

Recompile a libalias:

# cd /usr/src/lib/libalias/


# make clean


# make -DIPFW2


# make -DIPFW2 install

Vamos agora modificar o nosso kernel padrão(GENERIC) fazendo uma cópia do kernel default:

# cd /usr/src/sys/i386/conf/
# cp GENERIC NOME_DO_SEU_SERVIDOR


# vi NOME_DO_SEU_SERVIDOR

---> Procure a linha ident no kernel que foi copiado(NOME_DO_SEU_SERVIDOR) e modique-a colocando ao invés de:

ident GENERIC

para:

ident NOME_DO_SEU_SERVIDOR

Coloque essas linhas no final do kernel copiado(NOME_DO_SEU_SERVIDOR):

options IPFIREWALL
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=1000
options IPDIVERT
options DUMMYNET

-->salve e saia.

Vamos agora compilar e instalar o novo kernel(este passo é bastante demorado):

# cd /usr/src/

Compilando o kernel.

# make buildkernel KERNCONF=NOME_DO_SEU_SERVIDOR

Instalando o novo kernel.

# make installkernel KERNCONF=NOME_DO_SEU_SERVIDOR

Se tudo ocorreu bem, já temos o nosso kernel modificado bastando apenas reiniciar a máquina para utiliza-lo:

# reboot

Depois de reiniciar verifique que já estamos usando o novo kernel:

# uname -a

Instale um outro aplicativo que irá ajudar o ipfw a calcular os endereços de rede e host que são definidos no arquivo de regras do ipfirewall na forma "Ciderizada"(CIDR ex.: 189.87.34.2/21). Com isso você irá obter uma melhor perfomance no firewall:

# cd /usr/ports/net-mgmt/ipcalc/ && make install clean

Iremos configurar o rc.conf, para iniciar o firewall no boot e suas regras que serão pre-definidas por você, para isso basta editar /etc/rc.conf:

# vi /etc/rc.conf

-->Insira as seguintes linhas:

#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
# FIREWALL IPFW COM SUPORTE AO IPFW2 E IPV6
#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
firewall_enable="YES"
firewall_type="/tools/firewall/ipfw.rules"
firewall_quiet="NO"
firewall_logging="YES"

--> Onde firewall_type é seu arquivo de regras, falerei mais sobre as regras em outra postagem...

Iremos agora ativar o log
Crie os aquivo de log:

# mkdir /var/log/ipfw && touch /var/log/ipfw/ipfw.log

Depois configure o syslog:

# vi /etc/syslog.conf

--> Insira no final deste arquivo as linhas:
!ipfw
*.* /var/log/ipfw/ipfw.log

salve e saia e depois na shell enviei um hungup para o syslog:

# killall -HUP syslogd

quarta-feira, 26 de maio de 2010

pfSense - Introdução

Se estiver projetando a implantação de um servidor que contenha os serviços como: routing, daemon para roteamento RIP ,OSPF e BGP, Firewall, proxy, VPN, DHCP relay, DHCP server, DNS forwarder, DDNS, PPPoE server, Balanceamento de carga, Fail Over com carp, IDS, Traffic Graph por endereço IP entre outros .... você irá encontrar tudo isso e muito mais com o software opensource pfSense.

pfSense é livre, um open source customizado baseado na distribuição do S.O FreeBSD, adaptado para ser usado como um firewall e roteador.

Além de ser um poderoso firewall e roteador com uma plataforma flexível , ele inclui uma longa lista de ferramentas e um sistema de packages permitindo futuras expansabilidades, sem falar do potencial de segurança em termos de vulnerabilidades para a distribuição base. pfSense é um projeto popular com mais de 1 milhão de downloads desde seu início, e comprovada em inúmeras instalações que vão desde a proteção de pequenas redes domésticas e um Xbox até para grandes corporações, universidades e outras organizações protegendo milhares de dispositivos de rede.

Este projecto começou em 2004 como um fork do projeto m0n0wall, mas com foco para a instalação no PC ao invés do enfoque de software embarcado do m0n0wall. pfSense também oferece uma imagem incorporada para instalações em Compact Flash, porém não é o foco principal.

sexta-feira, 14 de maio de 2010

IPFW - Introdução ao IPFW sobre FreeBSD

O IPFW ou IPFIREWALL é o filtro de pacotes nativo do FreeBSD, sendo também chamado de IPFW, que é a interface para controle do IPFIREWALL. O IPFIREWALL faz o monitoramento de cada pacote em cada conexão feita à máquina, determinando por meio das regras definidas pelo IPFW qual é o tratamento dado a estes pacotes. As regras são lidas de cima para baixo, e podem determinar se o pacote será liberado, bloqueado, encaminhado etc.

Atualmente podemos ativar o suporte a IPFW2. O IPFW2 é uma nova versão do IPFW, com maior flexibilidade no formato das regras e algumas funcionalidades a mais, entre elas: suporte a regras não específicas para TCP ou UDP com número de porta, suporte a blocos OR, keepalives para sessões stateful e filtragem por cabeçalho MAC.

Seguidores