MAL - Memória Auxiliar do Lutieri

quinta-feira, fevereiro 08, 2007

Família BSD

Estou eu lendo o handbook do FreeBSD afim de descobrir mais sobre esse S.O. tão bem falado. Estou querendo conhecer outros firewalls.

Li algo que me considerei importante:

  • OpenBSD: para quem tem como prioridade a segurança;
  • FreeBSD: para quem tem como prioridade a performance;
  • NetBSD: para quem tem como prioridade a portabilidade.

Atualmente estou estudando o FreeBSD. De repente, como sou meio tarado por segurança eu acabe migrando pro OpenBSD.

Mais informações sobre as diferenças entre eles pode ser encontrado nessa lista:

http://www.fug.com.br/historico/html/freebsd/2006-07/msg00209.html

Marcadores:

quarta-feira, fevereiro 07, 2007

Gtalk liberado para poucos

Introdução:

Recentemente postei a respeito do bloqueio do Gtalk integrado no Gmail. Consegui bloquear o acesso.
Não demorou uma semana e tem gente aqui na empresa que arrumou uma justificativa pra usar o mesmo... hehehe
assim como já tiveram aqueles que justificaram o uso do google earth.. uaheua mas enfim.. eu só executo ;-)

Meu cenário:


                                                          `.....`    
``` `..
`- -
````````````` ```` `-`
- - .` `.`
- LAN - `. . Internet -
- - .. `.
- - : -`
```````:````` - `.
- .` ...``````.`
- `.````..` ````
- .```````````````- ````-
- - - -
- - - -
- - FIREWALL - -
..````````````````.: + -```````````````````-
- Proxy(Squid) -
- ` `````` -
- -
- -
.```````````````.


O desenho eu coloquei só porque achei bunitinho e dá um outro ar ao blog =)

Como as coisas funcionam:

Todas as conexões são encaminhadas para o proxy. Ele por sua vez, acessa o conteúdo na "rua" e devolve pra quem fez a solicitação. Portanto, os clientes que estão atrás do proxy não tem contato direto com a internet. Isso todos sabemos =)

Portanto para bloquear o Gtalk quando se está usando um proxy é só negar na Chain OUTPUT o acesso a chatenabled.mail.google.com(acho que é isso). Com isso o proxy não vai conseguir consultar a internet.


Problema:

Como eu disse no início eu preciso fazer a liberação o Gtalk para algumas criaturinhas aqui, lê-se usuários. =)


Façamos uma análise:

Quem acessa a internet é o Squid e não o cliente diretamente. certo?! sim.

Quando alguém quiser teclar no GTalk no pacote tcp o endereço de origem vai ser o do próprio squid ex.: 200.1.2.3 e o endereço de destino vai ser chatenabled.mail.google.com (64.233.185.189) por exemplo.
Pense comigo como eu vou poder liberar para um determinado IP se eu não tenho o IP de origem(do host na lan)?!? Quem tem o ip de origem é o squid, mas isso não me ajuda. A não ser que eu criasse um ACL no squid pra bloquear. Mas eu já tentei e não dá.

Se fosse na chain FORWARD(fosse só gateway e não proxy) era beleza. O IP de origem seria, por exemplo, 192.168.1.10 e o de destino seria chatenabled.mail.google.com(64.233.185.189). Perfeito!!!!


Pus-me a pensar:

...Não demorou muito, me imaginei um pacote tcp e logo achei uma solução.


Ressaltando:

Vou falar de novo para que fiquei bem claro: Todas as conexões são enviadas para o proxy sendo assim se eu bloquer a chain OUTPUT ninguém vai ter acesso ao Gtalk já que o proxy atende todo mundo.


A solução(vamos ser práticos):

No navegador do usuário devemos configurar o acesso ao endereço do Gtalk para que não seja usado proxy. Lá na configuração do navegador onde vai o endereço do proxy tem um espaço pra colocar os endereços que não devem passar pelo proxy(conexão direta com a internet). Coloca lá o endereço do Gtalk(chatenabled.mail.google.com).

Agora sim.. o navegador vai tentar conectar diretamente com a internet. Vamos ter esse pacote na chain FORWARD. Agora sim teremos um host da rede fazendo a solicitação diretamente ao endereço que deseja acessar.

Portanto, crie uma regra liberando esse host ao acesso. Ex:

iptables -A FORWARD -s 192.168.1.10 -d chatenabled.mail.google.com -j ACCEPT

Como o netfilter é stateful não precisa se preocupar criando uma regra pro pacote voltar.



Resumo:

No navegador sete para que não seja usado proxy para o endereço:
chatenabled.mail.google.com.

No firewall crie a regra liberado o host que pode ter acesso ao gtalk:
iptables -A FORWARD -s 192.168.1.10 -d chatenabled.mail.google.com -j ACCEPT
E a chain OUTPUT deve continuar negando para todos.


Espero ter conseguido expressar-me.

Marcadores: , ,

Backup da MBR

Apresento-lhes a Estrutura do Master Boot Record(MBR):


Gerenciador de boot(grub, lilo...)
Master Partition Table Assinatura
446 bytes 16 bytes 16 bytes 16 bytes 16 bytes 2 bytes


Ta aí o motivo pelo qual não podemos ter mais do que 4 partições primárias em um disco. Mas isso não é interessante agora....

Tanto o gerenciador de boot quanto a tabela de particionamento do HD são salvos no primeiro setor do HD, a famosa trilha MBR, que contém apenas 512 bytes. Destes, 446 bytes são reservados para o setor de boot, enquanto os outros 66 bytes guardam a tabela de partição.

Caso qualquer 1 dos 66 bytes da tabela de particionamento sejam subscritos ou danificados, você perde acesso a todas as partições do HD. O HD fica parecendo vazio, como se tivesse sido completamente apagado. Mas os dados continuam lá no HD.

Eu fiz um teste da seguinte maneira: Com o cfdisk apaguei a única partição que existia no disco. Salvei, sai, desliguei a máquina, religuei entrei novamente no cfdisk e recriei a partição ocupando todo o disco novamente. E tcharã!!! tudo estava como antes.... todos os arquivos e pastas no seu devido lugar =D

Hora do backup:

Você pode fazer um backup da trilha MBR do HD. Assim você vai poder recuperar tudo caso ocorra qualquer eventualidade. Para isso, use o comando:

# dd if=/dev/hda of=backup.mbr bs=512 count=1

O comando acima vai fazer uma cópia dos primeiros 512 bytes do "/dev/hda" no arquivo "backup.mbr".

execute também um dump das partições com sfdisk:

# sfdisk -d /dev/hda > backup.sf



Nos dois exemplos acima estou supondo que o disco a ser feito o backup seja o 1º disco do 1º canal IDE. Mude de acordo com o seu caso. Se não sabe qual é nem deveria tá mexendo com partição ;-)


Hora do restore:

Para restaurar um backup feito com o dd use:

# dd if=backup.mbr of=/dev/hda

Para restaurar um backup feito com o sfdisk use:

# sfdisk --force /dev/hdb < backup.sf


Que fique bem claro: o comand dd faz o backup de toda a trilha mbr do HD. Ele pega tanto o gerenciador de boot quanto a tabela de partições. Já o comando sfdisk faz um backup só da tabela de partições.

Lembre-se que o backup vai armazenar a tabela de particionamento atual. Sempre que você reparticionar o HD, não se esqueça de atualizar o backup.

Apartir daqui está descrita uma informação que eu achei importante mas nunca testei. Não me responsabilizo por nada -)



Caso o pior aconteça, a tabela de particionamento seja perdida e você não tenha backup, ainda existe uma esperança. O gpart é capaz de recuperar a tabela de partição e salvá-la de volta no HD na maioria dos casos. Você pode executá-lo dando boot pelo CD do Kurumin.

Você pode baixá-lo no: http://www.stud.uni-hannover.de/user/76201/gpart/#download

Baixe o "gpart.linux" que é o programa já compilado. Basta marcar a permissão de execução para ele:

# chmod +x gpart.linux


No Kurumin você pode instala-lo pelo apt-get: apt-get install gpart

Execute o programa indicando o HD que deve ser analisado:

# ./gpart.linux /dev/hda


(ou simplesmente "gpart /dev/hda" se você tiver instalado pelo apt-get)

O teste demora um pouco, pois ele precisará ler o HD inteiro para determinar onde começa e termina cada partição. No final ele exibe um relatório com o que encontrou:

Primary partition(1)
type: 007(0x07)(OS/2 HPFS, NTFS, QNX or Advanced UNIX)
size: 3145mb #s(6442000) s(63-6442062)
chs: (0/1/1)-(1023/15/63)d (0/1/1)-(6390/14/61)r
Primary partition(2)
type: 131(0x83)(Linux ext2 filesystem)
size: 478mb #s(979964) s(16739730-17719693)
chs: (1023/15/63)-(1023/15/63)d (16606/14/1)-(17579/0/62)r
Primary partition(3)
type: 130(0x82)(Linux swap or Solaris/x86)
size: 478mb #s(979896) s(17719758-18699653)
chs: (1023/15/63)-(1023/15/63)d (17579/2/1)-(18551/3/57)r

Se as informações estiverem corretas você pode salvar a tabela no HD usando o parâmetro "-W":

# gpart -W /dev/hda /dev/hda


Veja que é preciso indicar o HD duas vezes. Na primeira você indica o HD que será vasculhado e em seguida em qual HD o resultado será salvo. Em caso especiais, onde você tenha dois HDs iguais por exemplo, você pode gravar num segundo HD, com em: "gpart -W /dev/hda /dev/hdc"

O gpart não é muito eficiente em localizar partições extendidas (hda5, hda6, etc.) em boa parte dos casos ele só vai conseguir identificar as partições primárias (hda1, hda2, hda3 e hda4). Nestes casos, você pode usar o cfdisk ou outro programa de particionamento para criar manualmente as demais partições (apenas crie as partições e salve, não formate!). Se você souber indicar os tamanhos aproximados, principalmente onde cada uma começa, você conseguirá acessar os dados depois.


créditos: Por Carlos E. Morimoto
Fonte: http://www.dicas-l.com.br

Novamente eu peguei esse texto na net e fiz algumas modificações que tornam o entendimente mais simples.


Arrivederci!

Timeout no shell

Encontrei há muito tempo atrás um servidor que após dois minutos de inatividade no shell ele desconctava o usuário. Procurei por isso na configuração do ssh, já que era assim que eu conectava mas acabei vendo que era um recurso do próprio GNU/Linux.

É simples, é só setar o valor de segundos de timeout na variável de ambiente TMOUT.

Pode ser setado em /etc/bashrc ou /etc/profile:

export TMOUT=3600

Fonte: http://www.pcs.usp.br/~jkinoshi/bs/b000927.html
Autor: Renato Murilo Langona

au revoir!

Pendrive e Gnome: "cannot mount volume"

Plugei meu pendrive no gentoo com Gnome e retornou e seguinte erro:

cannot mount volume

Só isso... Me pareceu Windows.. simplesmente disse que não fez e deu... Sem maiores detalhes...

Solução edite o /etc/fstab e acrescente:

/dev/sda1 /mnt/pendrive auto defaults,users,noauto 0 0

No meu caso só tenho uma partição no Pen e ele detecta como sda1 e monto ele em /mnt/pendrive. A opção noauto é pra não tentar montar na inicialização do sistema.


Feito...

PHP Error: Allowed memory size of 8388608 bytes exhausted...

O sarg é muito bom, tem vários tipos de relatório e tal... mas infelizmente aqui na empresa o coitadinha tava abrindo as perninhas, ou como diriam meus colegas de Bagé: Tava queimando óleo.

O nosso access.log, do squid, fica com cerca de 30 a 60 Megabytes. Imagina o que é 60 Mb só de texto!!! Pois é, depois de algumas tentativas frustradas, entre elas compilação, troca de versão, split em arquivos, os erros como segmentation fault continuavam então decidi procurar outra ferramenta para fazer relatórios de acesso.

Nesse momente vim a conhecer o MySar(http://giannis.stoilis.gr/software/mysar/). Não vou abordar a instalação dele aqui. Se bem que é simples. Para os interessados tem um tutorial no VOL(http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=5221).

O MySar usa banco de dados Mysql e vai guardando os registro lá. Depois ele monta os relatórios com PHP. Como os registros estão em um banco há várias vantegens. Uma delas por exemplo é um espécie de daemon que roda de minuto em minuto adicionando os registros do accees.log para o banco. Então você tem o relatório de acesso quase que instantaneamente. E não força o processador e HD já qua são adicionados registros de pouco a pouco(minuto a minuto). O sarg já pegava o arquivo de log e fazia o relatório todo de uma vez... aí que ele se perde quando o arquivo é muito grande. Mas enfim.. testem que é bom.

Pois bém aqui na empresa o acesso a internet é muito usado. Trafega pelo proxy cerca de 7,5 Gb/dia. Desses quase 8 Gb 20% está no cache ;-)

Pois bem... são adicionados cerca de 1300 registros do arquivo de log do squid para o banco do Mysar por minuto. Minha base de dados está crescendo muito.

Numa dessas eu estava nagevando pelo relatório, que usa SQL, lógicamente, e retornou o erro do título desse post.

Os scripts SQL necessitam de uma certa quantidade de memória para executar. E como minha consultas estã retornando muitos registros essa quantidade de memória excedeu.

Pra resolver é simples:

Em um script php que faz a query você pode usar isto:

ini_set("memory_limit","12M");


Nesse caso esse script em específico vai ter o limite de 12Mb para usar. Caso não seja o suficiente pode-se ir aumentando até o chegar no tamanho ideal. Ou pega e aumenta de vez lah pros 30Mb.


Se for um script que você não conhece, de outra pessoa, ou for interessante que essa alteração se replique para todos os demais scripts, pode ser setado esse valor no php.ini:

memory_limit = 12M

Lembre-se que ao invés de simplesmente aumentar a quantidade de memória o script pode ser reprogramado. Faça uma busca por "tunning sql querys". Pode ser melhor.

A dica eu tirei daqui.

Conexões SSH sem senha[atualizado]

É possível fazer logon no serviço SSH de um servidor remoto atráves de chaves(keys).


Nesse post, para melhor entendimento, vou tratar o esquema de autenticação como sendo cliente/servidor. Teremos o seguinte:

  • Um servidor onde está rodando o daemon do SSH, esperando por conexões.
  • Um cliente, uma estação qualquer, apartir da qual faremos a conexão ao servidor.

Vamos iniciar a configuração na máquina servidora:


Edite o arquivo de configuração do sshd, normalmente em: /etc/ssh/sshd_config

Confirme se a opção PubkeyAuthentication está setada como yes. Senão faça isso.

PubkeyAuthentication yes

Pronto!! No servidor é só isso.

Agora devemos criar uma chave pública, vá até o micro com o qual você costuma efetuar a conexão remota e execute como usuário:


A configuração na máquina cliente:


Gerando a chave localmente:

$ ssh-keygen -t dsa -b 1024

A opção -t especifica o tipo da chave a ser criada. Use rsa caso esteja usando o protocolo de versão 1 no servidor ou use dsa caso use o protocolo versão 2 no servidor. rsa é a padrão caso não especificado.

A opção -b especifica o número de bits da chave a ser criada. Para chaves RSA o tamanho mínimo é de 768 bits and o padrão é 2048. Geralmente, 2048 bits é considerado o suficiente. As chaves DSA precisam ser exatamente 1024 bits.

Vão ser feitas algumas perguntas durante a criação da chave pode ir confirmando com enter. Não vamos alterar nada.

Agora você tem sua chave de acesso e você deve enviá-la para o servidor com o qual você se conecta, para isto usaremos o ssh-copy-id.

$ ssh-copy-id -i ~/.ssh/id_dsa.pub usuario@IPdoServidor
Nas últimas versões me parece que não existe mais o comando ssh-copy-id. Portanto pode ser usado o comando genérico:
$ scp ~/.ssh/id_dsa.pub usuario@IPdoServidor:~/.ssh/authorized_keys

Substitua usuario pelo usuário usado na conexão com a outra máquina e IPdoServidor pelo IP da máquina remota.

Pronto, agora basta testar e conectar ao servidor.

$ ssh usuario@maquinaIP

Você deverá conectar-se sem precisar digitar a senha.

* Para garantir a segurança você deverá tomar cuidado com a chave gerada no seu diretório HOME na pasta .ssh, pois se um mal intencionado copia-la poderá logar-se na máquina remota sem utilizar a senha.



Encontrei esse tutorial aqui. Tomei a liberdade de modificar e deixá-lo mais mastigado.
Outra fonte:
http://www.debian-administration.org/articles/530


Feitoooo!!!!

Marcadores:

segunda-feira, fevereiro 05, 2007

Bloquear GTalk no Gmail

Hip hip urra! Finalmente consegui executar o título desse post.

Eu já havia encontrado a informação diretamente da fonte:

http://mail.google.com/support/bin/answer.py?answer=34330&topic=8407


mas, porém, contudo, entretanto, todavia eu não havia colocado em prática ainda. Hoje encontrei essa dica no VOL:

http://www.vivaolinux.com.br/dicas/verDica.php?codigo=7010

Inseri as regras no meu firewall e tal e analisei que b.mail.google.com é o mesmo ip do que o chatenabled.mail.google.com portanto não precisa ter os dois já que apontam pro mesmo IP.

Outra coisa: As regras de FORWARD também não são necessárias. Se você já está bloqueando no INPUT e/ou OUTPUT não precisa bloquear na chain FORWARD também. Não faz sentido(a não ser que você não tenha um proxy nessa máquina). Se essa máquina onde tá o firewall é só gateway da rede ai precisa colocar o FORWARD do contrário só o INPUT ou OUTPUT.

Mais uma coisa: Se você bloquear no INPUT os pacotes vão sair e não vão poder voltar e se você bloquear no OUTPUT os pacotes não vão poder nem sair. Então pra que bloquear nos dois?!?

Resumindo o tele-post de hoje se você tem um proxy rodando:

iptables -A OUTPUT -d chatenabled.mail.google.com -j DROP
ou

iptables -A INPUT -d chatenabled.mail.google.com -j DROP

Resumindo o tele-post de hoje se você NÃO tem um proxy rodando:

iptables -A FORWARD -d chatenabled.mail.google.com -j DROP

[]'s

header_access no squid podem atrapalhar sua vida

No dia 22 de Janeiro desse ano eu postei a configuração que é usada no squid para que não seja exibido o IP interno, a versão do squid ... naquelas páginas do tipo whatismyip.

Porém ao longo do tempo descobri que algumas daquelas mudanças não são muito interessantes.

Por exemplo:

header_access User-Agent deny all
header_replace User-Agent Nutscrape/2.0 (CP/M; 8-bit)


Eu estava usando essa configuração para evitar que seja enviado o navegador do usuário para qualquer página que ele acesse. Porém tive um problema um uma página que é acessada aqui na empresa(ons.org.br). Nessa página e em outras várias existe um javascript que carrega a folha de estilos de acordo com o navegar do usuário. Porém eu estava enviando como sendo o meu navagador o Nutscrape. Como não era premeditado que alguém tivesse esse navegador, por motivos óbvios, a página e alguns campos de formulários acabavam ficando fora de formatação, tamanho pequeno.. enfim...

A solução foi comentar as linhas acima citadas.


Outra coisa:


Em um outro site que eu acesso ele requer autenticação feita através do apache(.htaccess).
Eu inseria meu nome e senha de usuário corretamente porém o login não era efetuado.

Solução:

Tive que comentar a seguinte linha no squid.conf

header_access WWW-Authenticate deny all

Pronto. Por algum motivo que eu ainda não descobri o squid deve negar alguma coisa e a autenticação não é efetuado com sucesso.


[]'s



Chat with Lutieri G. B.

Subscribe in a reader