Consumo

systat 1
No prompt dele digite
:ifstat
Ou
systat -if 1
e dentro dele digitar
:scale mbit

FreeBSD: Trocar banner do MSN Messenger

É simples! Basta você ter instalado o squid, e na sua conf adicionar as seguintes linhas:
# vim /etc/squid/squid.conf
# Banner anuncio do msn
acl ADSAdClien url_regex ADSAdClien
http_access deny ADSAdClien
deny_info http://remontti.com.br/msn.html ADSAdClien
Salve, reinicie o serviço
# /etc/init.d/squid restart
Agora basta você alterar a linha deny_info para o endereço do seu banner, poder http://ipdoserve…. crie uma html, coloque uma imagem ou então uma animação flash, com a dimensão 236 x 62.
Abra seu messenger… uuuualáááá! Simples não? Negamos ADSAdClien e direcionamos a pagina de erro p/ nosso banner.

O parafuso certo

A algum tempo atrás eu li um texto num blog que achei legal, pois passava uma mensagem importante para nós que atuamos como gestores…
Infelizmente não guardei a fonte para poder dar os devidos créditos, mas mesmo assim gostaria de deixar a mensagem aqui para vocês.
O parafuso certo…
Um especialista em informática, foi chamado para consertar um computador muito grande e extremamente complexo, que valia em torno de 12 milhões de reais.
Sentado na frente do monitor, o especialista mexeu em algumas teclas, balançou a cabeça, murmurou algo para ele mesmo, pegou uma pequena chave de fenda do bolso, deu a volta no equipamento e apertou um minúsculo parafuso.
Então, ligou o computador e o mesmo funcionou perfeitamente.
O presidente da empresa se mostrou surpreso e satisfeito e se ofereceu para pagar o serviço à vista.
- Quanto te devo? – Perguntou.
O especialista respondeu:
- São mil reais pelo serviço.
O presidente, indignado, perguntou:
- Mil reais? Mil reais por alguns minutos de trabalho? Mil reais só para apertar um simples parafuso? Eu sei que meu computador vale 12 milhões de reais, mas mil reais por 5 minutos do seu trabalho é muito dinheiro. Vou pagar somente se você me mandar uma fatura detalhada que justifique o valor.
O especialista concordou e foi embora.
Na manhã seguinte, o presidente recebeu a fatura.
Leu o documento com cuidado, balançou a cabeça e a pagou na hora.
A fatura dizia:
SERVIÇOS PRESTADOS
Apertar um parafuso – R$ 1,00
Saber qual parafuso apertar – R$ 999,00

http://www.ebrandi.eti.br/

WAN LAN DMZ

suponhamos que vc tenha um bloco de ips /24 uma classe C inteira.

por exemplo.
200.200.200.0/24

pra facilitar o entendimento, vamos subnetar esse bloco em duas subredes

200.200.200.0/25
rede -a 200.200.200.0-127/25
rede -b 200.200.200.128-255/25

ambiente

firewall com 3 interfaces..

Lan Wan e DMZ

interface wan - 200.200.200.2 gw 200.200.200.1

interface DMZ 200.200.200.129 servidores 200.200.200.130-254

lan - 192.168.0.0/24 por exemplo..

sendo assim, vc fica com ips válidos na Wan e na DMZ, roteados pelo firewall
que possui uma interface em cada um. devido a isso vc consegue tratar as
requisições para e da DMZ pelo firewall, criando seus filtros.

FONTE: http://eng.registro.br/pipermail/gter/2009-January/021462.html

FreeBSD: Buscar arquivos maiores que X (x=tamanho)

Procurando arquivos maiores que 1GB

find / -size +1G

FreeBSD: Mudar timezone

Comando: tzsetup

FreeBSD: Sistemas de Ports com wget

Em /etc/make.conf adicione as seguintes opções:

FETCH_CMD=wget
FETCH_BEFORE_ARGS=-nc --progress=bar --read-timeout=60
DISABLE_SIZE=yes

-nc --> replace any files that previously downloaded, rather then clobber it
--progress=bar --> use bar to indicate download process
--read-timeout=60 --> should the internet line break in the halfway of downloading, retry for 60 seconds only. The default is 900 seconds.

FreeBSD: Atualizar BIND via ports

#
# named. It may be possible to run named in a sandbox, man security for
# details.
#
named_enable="YES" # Run named, the DNS server (or NO).
named_program="/usr/sbin/named" # path to named, if you want a
different one.
named_flags="-u bind" # Flags for named
named_pidfile="/var/run/named/pid" # Must set this in named.conf as well
named_chrootdir="/var/named" # Chroot directory (or "" not to
auto-chroot it)
named_chroot_autoupdate="YES" # Automatically install/update chrooted
~ # components of named. See
/etc/rc.d/named.
named_symlink_enable="YES" # Symlink the chrooted pid file

Se você trocar o parametro named_program pra "/usr/local/sbin/named"
provavelmente será o suficiente.

FreeBSD: Envenenamento de Cache no BIND 9 - Atualização

FONTE: FreeBSD Brasil

Recentemente foram publicados dois alertas de segurança oficiais do BIND 9, o CVE-2007-2925 e o CVE-2007-2926 de 24 de Julho. A FreeBSD Brasil LTDA não compartilha da classificação de risco médio, oficialmente publicada pelo ISC, e considera, em especial o problema descrito no CVE-2007-2926 de alto risco, e recomenda fortemente atualização imediata de todos os servidores de nomes de seus clientes.

Recentemente foram publicados dois alertas de segurança oficiais do BIND 9, o CVE-2007-2925 e o CVE-2007-2926 de 24 de Julho, que podem ser observados em referência oficial neste endereço. A FreeBSD Brasil LTDA não compartilha da classificação de risco médio, oficialmente publicada pelo ISC, e considera, em especial o problema descrito no CVE-2007-2926 de alto risco, e recomenda fortemente atualização imediata de todos os servidores de nomes de seus clientes para a versão 9.3.4-P1, em produção.
Nenhum dos dois problemas de segurança permite execussão arbitrária de comandos ou exploração ao sistema, seja remota ou localmente. Todavia, o problema afeta a natureza principal do serviço de nomes, a validação e integridade das respostas em solicitações (queries) de nomes. Dessa forma, através de ataques de envenenamento de cache, é possível que um servidor de nomes BIND 9 vulnerável responda de forma adulterada informações, enviando domínios para outros endereços, de forma distinta da resposta de autoridade inicial.

O primeiro problema é uma vulnerabilidade na geração de queries de identificação em análises criptográficas, que possibilita com estatísticas de sucesso de chance de 8 pra 1 de adivinhar 50% de todos os ID de consultas ao servidor. Isso torma o envenenamento de cache muito fácil.

Esse bug afeta apenas servidores de nomes recursivos. O que não é na verdade, um grande alívio, já que 90% dos servidores de nomes atual como recursivos, fazendo a resolução de nomes de outros domínios, e não exclusivamente como encaminhadores (forwarders) ou como servidores de autoridade. Ainda os servidores de autoridade podem ser afetados por este problema, quando atuando como servidores primário (slave name servers) ao enviar notificação de mudança nos domínios, para os servidores slave, que por sua vez se atuarem como resolvedores recursivos podem estar vulneráveis, e completar a corrente, afetando o servidor master. Esse segundo tipo de exploração é apenas teórica, mas possível.

Como o ataque acontece.

A essência primária é que o atacante deve ter uma zona de internet adequadamente configurada e de autoridade plena. Dessa forma esse servidor fará a resposta por qualquer consulta sobre essa sua zona (domínio). A segunda etapa é, teoricamente, mais difícil. Algum cliente de um servidor de nomes vulnerável deve fazer uma requisição sobre a zona de internet de quem realiza o ataque. Se o servidor de nomes é mal configurado e resolve DNS recursivamente a qualquer estação, realizar o ataque é extremamente simples.

A partir desse ponto a principal proteção contra envenenamento de cache DNS, passa a ser explorada. Essa proteção conta com a impossibilidade prática de prever o ID formal da próxima transação DNS, que é um ID de 16 bits. Se for possível prever o ID de próximas transações/consultas, é possível responder com esse ID futuro ao servidor, e ele fará cache da resposta, a resposta a uma consulta ainda não realizada.

Devido a um problema de engenharia de software na implementação da criação de números aleatóreos do BIND 9, o ID das transações que são final par (número final par) são seguidos de quase dez outros IDs das transações seguintes, calculados com base no número par conhecido da consulta alteriormente realizada.

Assim, o atacante desempenha um ataque conhecido como encadeiamento de respostas canônicas (apelidos CNAME) para terminar o ID de uma transação de forma simples, rápida e eficiente. Esse procedimento consiste-se na consulta a um servidor, fazendo esse servidor realizar uma consulta ao próprio servidor DNS de quem faz o ataque, através de um domínio sobre o qual o atacante detém autoridade. O servidor de autoridade em questão recebe a consulta, e portanto passa a conhecer o ID da transação. Se tal ID for número de final par, uma resposta é enviada, e esta resposta é de um registro DNS do tipo CNAME, que aponta para outro nome do próprio domínio (zona) que o atacante detém autoridade. Assim o servidor de nomes recursivo automaticamente fará outra consulta, e esta por sua vez, com um nov ID de transação.

Ao determinar a lógica das requisições, com duas ou três consultas no máximo, todos os próximos ID passam ser conhecidos, podendo estes ser até 8 dos próximos 10 (já que 2 consultas foram utilizadas durante o ataque). Sendo assim, há chances das próximas consultas não serem de ID final par, mas sim, final ímpar. Todavia, a probabilidade de ser par é 50%. Então sobre as próximas 8 consultas, ao menos 4 possivelmente estarão entre as respostas que agora o servidor atacante pode enviar, mesmo as consultas ainda não tendo sido feitas.

O servidor de nomes vulnerável fará cache dessas respostas, e as enviará quando as queries acontecer, resultando em respostas que potencialmente apontam para endereços que não são a informação correta, mas sim, a informação cacheada adulterada (envenenada). O ataque conta ainda com a performance do servidor sendo atacado, pois a velocidade de processamento faz diferença, para garantir que as consultas de CNAME acontecam logo depois da consulta original. Assim sendo um servidor de nomes sobrecarregado e que responde milhares de requisições simultâneas, do tipo recursivas, torna o ataque menos fácil. Porém, não prevê que ele aconteça.

A segunda condição todavia, passa a ser cada vez mais explorada recentemente. Alguns worm começam a se espalhar, e pior, mensagens de SPAM e também URLs furtivas em websites e em mensagens de e-mail estão apontando para zonas de nomes afim de desempenhar tal ataque, e usuaŕios passam a, sem ter consciência, fazer consultas sobre zonas nocivas em seus servidores de nomes recursivo.
Não há solução para o problema, a não ser modificações no código. Portanto, a atualização para a última versão do BIND 9 é imperativa.

Curiosamente, 10 anos atrás, Theo De Raadt, hoje líder do Projeto OpenBSD previu que o BIND 9 pudesse ser explorado de tal maneira, e fez uma variação do algorítimo de criação dos ID de transações, usando geraçao linear dos números aleatórios, com LCG (Linear Congruential Generation) , que não é vulnerável a este problema. O Projeto FreeBSD ao importar os novos fontes do BIND 9 passa a aplicar também uma pequena variação do LCG, para evitar problemas futuros de mesma natureza.

Para complementar, um outro problema, teoricamente menor, ajuda a exploração ser mais viável. O BIND 9 não valida a autorização de consulta à informações cacheadas, e permite que mesmo estações sem permissão de recursão possam tirar proveito de informações já cacheadas por outros hosts com privilégio de recurssão. Felizmente para evitar tal problema, basta uma pequena modificação na configuração, adicionando ao bloco options do named.conf(5) a entrada

allow-query-cache { };

Apontando para as mesmas redes/estações que tem privilégio de recursão. Esse último problema todavia, afeta apenas série 9.4 e 9.5 do servidor de nomes.
Resolução do Problema

Para resolver o(s) problema(s), atualize seu servidor de nomes para uma dessas versões:

BIND 9.2.8-P1
BIND 9.3.4-P1
BIND 9.4.1-P1
BIND 9.5.0a6.
No FreeBSD o BIND 9.3.4-P1 já foi incorporado, e foi feito MFC da correção, com as devidas customizações e padronização para o sistema aplicados. Para atualizar, siga as instruções:

Sincronize os fontes de seu sistema com o mais recente, usando csup (se for FreeBSD 6.2) ou cvsup:

cvsup -g -L 2 -h cvsup2.freebsd.org /usr/share/examples/cvsup/stable-supfile (FreeBSD anterior ao 6.2)
Ou

cvsup -g -L 2 -h cvsup2.freebsd.org /usr/share/examples/cvsup/stable-supfile (FreeBSD 6.2-RELEASE ou superior)

Após completa a sincronia, recompile o named(8) e o instale:

# cd /usr/src/lib/bind
# make clean
# make
# make install



# cd /usr/src/usr.sbin/named
# make clean
# make
# make install
Em seguida reinicie o sistema de nomes:
# /etc/rc.d/named restart
Ou
# killall -HUP named
Confira a versão do novo daemon de nomes:

# /usr/sbin/named -v
BIND 9.3.4-P1
E após ter reiniciado o serviço confira se ele levantou-se adequadamente, em /var/log/messages, os indícios de sucesso serão como este:

Jul 30 15:30:05 dns1 named[66932]: starting BIND 9.3.4-P1 -u bind -t /var/named
Confira em seguida com sockstat -4l e faça queries (consultas) com nslookup(1) e dig(1) para conferior se o serviço foi plenamente restabelecido.

Clientes FreeBSD Brasil

Todos os clientes Service Level Agrement de nível 2 ou superior já tiveram seus servidores de nomes principais atualizados. Pedimos por gentileza que todos entrem em contato conosco caso existem outros servidores de nomes em uso, que não conhecemos, nos informe, para que os atualizemos também, ou atualizem seguindo as instruções acima.

Clientes de outros níveis de suporte se não conseguirem atualizar como acima entrem em contato também. Se preferirem nos informe explicitamente, que atualizaremos.

Correções Binárias

Clientes FreeBSD Brasil podem também fazer atualização binária usando o bspatch(1). Para isso, disponibilizamos neste endereço:

Área de Download Portal Corporativo
Os diff binários das principais versões do bind para a versão corrigida. Para facilitar, os patch binários tem seu nome padronizado, chama-se:

named_X.Y.Z_9.4.3_P1
Onde X.Y.Z variará de acordo com a versão original. Por exemplo, named_9.3.1-9.4.3_P1 representa o patch binário da versão 9.3.1 para 9.4.3_P1. Faça download de seu patch de acordo com a versão adequada. Para descobrir qual sua versão digite

named -v

Para aplicar a correção, você deve seguir as seguintes instruções:

Faça backup de seu named atual:

mv /usr/sbin/named /usr/sbin/named.old

E com bspatch(1) aplique o patch binário

bspatch /usr/sbin/named.old /usr/sbin/named /tmp/named_X_Y

Redefina as permissões com chmod 555 /usr/sbin/named e reinicie o serviço. Teste, como mencionado na atualização por fontes.

Mais detalhes ou revisões futuras dessa nota de segurança podem sempre ser observadas no Portal Corporativo, neste endereço

glTail Visualize os log de uma maneira diferente

Exibir dados e estatísticas em tempo real de qualquer arquivo de log em qualquer servidor com o SSH, de forma intuitiva e de entretenimento.
RECURSOS
Em tempo real
Vários arquivos de log em vários servidores
Layout configurável
Vários analisadores de arquivo de log
(Apache combinada, Rails, IIS, Postfix/spamd/clamd, Nginx, Squid, PostgreSQL, PureFTPD, MySQL, TShark, o qmail/vmpop3d)
Eventos personalizados
Mostrar a taxa, total ou média
Se você pode 'cauda' ele, você pode visualizar
Escrito em Ruby usando o net - ssh, Tâmia & ruby-opengl
Grátis! (GPLv2)

FreeBSD: ifstated

Ifstated para Dois Links
#Explicação ao ifstated para não haver mais duvidas !

#Ativa o Log no /var/log/messages
loglevel debug

# Seta o estado inicial sendo assim ele executara o segundo estado abaixo
init-state link1_down

# Variável para definir o método de teste
# E criado uma rota estatica para o site resgistro.br saindo pelo primeiro link
rede_link1='"ping -c 5 -i 1 -t 5 -q 200.160.2.3 > /dev/null" every 20'

# Primeiro estado, se nao pingar ele vai executar este script que troca a rota default
# e carrega o arquivo de pf-link2.conf
state link1_up {

if ! $rede_link1
{
run "/bin/sh /usr/local/bin/link2.sh"
set-state link1_down
}
}

# O Segundo estado, ja e executado logo de inicio quando o link1 esta UP
# colocando o default gateway, setando uma rota estática para o ip do registro.br
# e carregando o arquivo de pf.conf padrão
state link1_down {

if $rede_link1
{
run "/bin/sh /usr/local/bin/link1.sh"
set-state link1_up
}
}

# Quando voltar a pingar o site resgistro.br indica que o link voltou a funcionar
# e o primeiro estado fica sendo o em execução

FreeBSD: PostgreSQL

Synopsis

This post will describe the steps required to complete the initial configuration of the PostgreSQL DBMS on a system running FreeBSD. Configuring the basic configuration of PostgreSQL and creating an initial super-user will be covered; performance tuning, database administration, and Structured Query Language (SQL) will not be covered in this post.

Installation

Configure and install the PostgreSQL v8.4.x DBMS from the ports collection. The default port configuration will work just fine, although you may consider enabling the OPTIMIZED_CFLAGS option for better performance.

# cd /usr/ports/databases/postgresql84-server
# make config
# make install clean


Configuration

Enable PostgreSQL to start at system boot in /etc/rc.conf.

# echo 'postgresql_enable="YES"' >> /etc/rc.conf


Initialize the PostgreSQL database cluster for the first time. NOTE: The following command will create the initial database cluster in the /usr/local/pgsql/data directory by default.

# /usr/local/etc/rc.d/postgresql initdb
/usr/local/etc/rc.d/postgresql initdb
The files belonging to this database system will be owned by user "pgsql".
This user must also own the server process.

The database cluster will be initialized with locale C.
The default text search configuration will be set to "english".

fixing permissions on existing directory /usr/local/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 40
selecting default shared_buffers ... 28MB
creating configuration files ... ok
creating template1 database in /usr/local/pgsql/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.

Success. You can now start the database server using:

/usr/local/bin/postgres -D /usr/local/pgsql/data
or
/usr/local/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start


Configure PostgreSQL to listen for database connections on all system IP addresses by adding the following line to /usr/local/pgsql/data/postgresql.conf.

listen_addresses = '*'


Configure PostgreSQL to use password hash authentication for all hosts and users connecting from the local network by adding the following line to the /usr/local/pgsql/data/pg_hba.conf file. NOTE: Replace 10.0.1.0/24 with your own network.

host all all 10.0.1.0/24 md5


Start the PostgreSQL DBMS for the first time and add a new super-user (with database and role creation rights) by executing the following commands.

# /usr/local/etc/rc.d/postgresql start
# su pgsql
$ createuser -sdrP username
Enter password for new role: ******
Enter it again: ******

$ exit


Testing

The PostgreSQL DBMS should now be up and running with the newly created super-user. Using a PostgreSQL client, such as pgadmin3 connect to the PostgreSQL server from another system using the username and password of the role previously created. New database schemas, roles, procedures, etc can now be created using the super-user.

References

PostgreSQL: Documentation Manuals: PostgreSQL 8.4.
PGAdmin – PostgreSQL Administrator.

FreeBSD: Montar drive ntfs

mount_msdosfs -o large /dev/da0s1 /mnt/