As máquinas estão tomando decisões :-)

E isso me preocupa!

Pra quem tem aquelas idéias maluca de que as canetas BIC são sondas alienígenas e que o mendigo na esquina do seu emprego na verdade é um agente da CIA disfarçado e mais do que isso: Acha que as máquinas vão dominar o mundo. Olha o que o FreeBSD me aprontou essa semana.

Como falei no post anterior tive problemas com o pftpx, bom na verdade ele não tinha nada de errado. Mas até eu descobrir isso eu já havia atualizado ele. Me surpreendi com a tomada de decisões do SO. Tive que reinstalar uma lib e quando fui remover ela:

# make deinstall
===> Deinstalling for devel/libevent
===> Deinstalling libevent-1.2
pkg_delete: package 'libevent-1.2' is required by these other packages
and may not be deinstalled (but I'll delete it anyway):
pftpx-0.8_1
#

Prestaram atenção no detalhe entre parênteses?!?!

Apesar de tudo é um SO decidido. :-)

Mas se é pra falar sério mesmo eu digo que só vou acreditar que as máquinas vão dominar o mundo no dia que elas se acharem muito gordas e acharem que precisam de uma dieta.

Feliz Natal!!

Pftpx: server refused connection


Dec 20 15:56:05 sdfirewall pftpx[38984]: #951 server refused connection
Dec 20 15:56:15 sdfirewall pftpx[38984]: #952 server refused connection
Dec 20 15:56:26 sdfirewall pftpx[38984]: #953 server refused connection
Dec 20 15:56:37 sdfirewall pftpx[38984]: #954 server refused connection
Dec 20 15:56:47 sdfirewall pftpx[38984]: #955 server refused connection
Dec 20 15:56:59 sdfirewall pftpx[38984]: #956 server refused connection
Dec 20 15:57:10 sdfirewall pftpx[38984]: #957 server refused connection


Essa é a mensagem que apareceu ontem várias e várias vezes no meu firewall. Pois bem, pensei que fosse uma mensagem do pftpx reportando algum erro. Mas depois descobri que não. Essa mensagem é do servidor ftp onde meu cliente estava tentando conectar. Que podemos ver, por sinal, que o servidor não estava aceitando conexões.

Como descobri de onde vinha essa mensagem:

Bom, quem me conhece sabe que eu gosto de ver o que está acontecendo por trás do panos. Tanto é que uso Unix/Linux :-) Cansei de viver na tentativa e erro com o Sr. Janelas.

Olhando o manual do pftpx vi alguns parâmetros que iriam me ajudar nessa empreitada. Resumindo, iniciei o pftpx com os seguintes parâmetros:

pftpx -D 7 -d

O "-D 7" é nível de debug máximo, mas não encontrei os logs detalhados em lugar algum. Portanto resolvi adicionar o "-d" que roda o processo em foreground e então voilá!

No freebsd para adicionar esse parâmetros é só setar o a seguinte variável no /etc/rc.conf

pftpx_flags="-D 7 -d"

E reiniciar o serviço:

/usr/local/etc/rc.d/pftpx restart

Consegui ver que tinha um cliente que tentava conectar a cada 10 segundos +- em um server ftp qualquer. Acredito que seja vírus, spyware ou alguém dessa família. Vejam o que tive no log.


Starting pftpx.
listening on 127.0.0.1 port 8021
#1 accepted connection from 172.16.21.17
#1 FTP session 1/100 started: client 172.16.21.17 to server 58.254.39.26 via proxy 201.42.xx.xx
#1 server refused connection
#1 ending session
#2 accepted connection from 172.16.21.17
#2 FTP session 1/100 started: client 172.16.21.17 to server 58.254.39.26 via proxy 201.42.xx.xx
#2 server refused connection
#2 ending session
#3 accepted connection from 172.16.21.17
#3 FTP session 1/100 started: client 172.16.21.17 to server 58.254.39.26 via proxy 201.42.xx.xx
#3 server refused connection
#3 ending session
#4 accepted connection from 172.16.21.17
#4 FTP session 1/100 started: client 172.16.21.17 to server 58.254.39.26 via proxy 201.42.xx.xx
#4 server refused connection
#4 ending session
#5 accepted connection from 172.16.21.17
#5 FTP session 1/100 started: client 172.16.21.17 to server 58.254.39.26 via proxy 201.42.xx.xx
#5 server refused connection
#5 ending session

Pode-se ver nesse log a mensagem que tava me enchendo e enchendo meus logs :-)
Quando o cliente tenta conectar nesse server 58.254.39.26 a conexão não é aceita. :-)

Mensages de ARP repetitivas no FreeBSD


Dec 14 18:50:07 sdfirewall kernel: arp: 172.16.2.13 moved from 00:14:4f:45:41:b3 to 00:14:4f:45:41:b2 on em0


Essa mensagem ali aparece várias vezes no syslog. Portanto resolvi sumir com ela. No meu caso acredito não ser importante pois esses dois endereços de hardware(MAC's) são do mesmo servidor. Em um porta ethernet tenho um endereço classe C e na outra porta tenho esse endereço classe B. Bom de qualquer maneira, é o mesmo servidor e com certeza não é spoofing. Eu ficaria preocupado se um dos MAC's fosse de outra máquina.

Acredito que seja algo com o switch mas não estou disposto a procurar.

Pra solucionar temporariamente é só esconder as mensagens :-)
Achei em um fórum a ajuda.


Retorna a descrição da diretiva:

#sysctl -d net.link.ether.inet.log_arp_movements

Retorna:

net.link.ether.inet.log_arp_movements: log arp replies from MACs different than the one in the cache

Para ver o valor atual executa-se:

#sysctl net.link.ether.inet.log_arp_movements

Provavelmente estará setado em 1. Que ativa o log dos movimentos ARP.

Para alterar o valor:

sysctl net.link.ether.inet.log_arp_movements=0

Pronto! Sem mensagens de movimentos ARP

:-D

Fonte de pesquisa:
link:http://www.derkeiler.com/Mailing-Lists/FreeBSD-Security/2004-01/0071.html

Rapidinhas do pfctl [atualizado]

Por mim eu colocava todo o pfctl.man aqui. Mas por hora apenas o mais usado.

Ultimamente tive problemas ao carregar as regras. Como sempre gosto de saber o que está acontecendo nos bastidores. Portanto segue como ativar o modo versoso do pf:

pfctl -vvf /etc/pf.conf

Existem, ainda, algumas alternativas que podem ajudar a diagnosticar onde está o problema. Como por exemplo carregar primeiro as regras de NAT e redirecionamento e depois as de filtragem. Segue exemplos:

pfctl -f /etc/pf.conf Carrega o arquivo pf.conf
pfctl -nf /etc/pf.conf Analisa o arquivo, mas não o carrega
pfctl -Nf /etc/pf.conf Carrega apenas as regras NAT do arquivo
pfctl -Rf /etc/pf.conf Carrega apenas as regras de filtragem do arquivo

No momento que eu estava escrevendo essa nota, artigo ou seja lá como quiser chamar, eu estava tentando descobrir pra que raios servia a opcão -g do pfctl. No manual apenas diz que inclui na saída informacões úteis pra debug. Pois bem, achei uma utilidade.

Quando você está usando o tcpdump pra capturar o tráfego que passa pelo PF com o comando:

tcpdump -n -e -ttt -i pflog0

você vai ter informacões, da captura, como essa. Interrompendo nossa transmissão:
Essa interface eh padrão no openbsd no freebsd eh necessário compilar o kernel com ela ativa. Na versao 7.1-RELEASE e provavelmente apartir da 7?!?! a interface pflog0 jah estah compilada como modulo. Portanto para usar basta:

kldload pflog

E caso voce esteja capturando alguns pacotes que exibem o seguinte

tcp 40 [bad hdr length 0 - too short, <>

tente o comando:

tcpdump -s 1600 -n -e -ttt -i pflog0

Dica tirada daqui:
http://www.freebsd.org/cgi/man.cgi?query=pflogd&sektion=8


Continuamos com nossa transmissão normal:

Sep 17 17:07:37.443421 rule 14/0(match): pass in on fxp0: 55.66.77.88.14373 > 66.92.15.252.22: S 3920978973:3920978973(0) win 5840 (DF)

Isso diz que esse pacote coincidiu com a regra #14. Pois bem, é aí que entra o nosso amigo -g. Com o comando: pfctl -g -s rules. São exibidas as regras e os números que o PF alocou pra cada uma.


Existe também um modo de debug que pode ser usado. Ele é ativado através da opcão -x. E pode ter os seguintes valores:

none - Don't generate debug messages.
urgent - Generate debug messages only for serious errors.
misc - Generate debug messages for various errors.
loud - Generate debug messages for common conditions.

Exemplo: pcftl -x urgent
Essas mensagens vão para /var/log/messages


Alguns comandos que você vai usar 90% do tempo:

pfctl -d	Diable the packet filter
pfctl -e	Enable the packet filter
pfctl -Fa -f /etc/pf.conf	Flush all (nat, filter, queue, state, info, table) rules and reload from the file /etc/pf.conf
pfctl -s rules	Report on the currently loaded filter ruleset.
pfctl -s nat	Report on the currently loaded nat ruleset.
pfctl -s state	Report on the currently running state table (very useful).
pfctl -v -n -f /etc/pf.conf	This does not actually load any rules, but allows you to check for errors in the file before you do load the ruleset. This is obviously good for testing.

Mais informacões acesse: http://www.openbsd.org/faq/pf/pt/index.html
e http://www.thedeepsky.com/howto/newbie_pf_guide.php