Ativando o Mysql no Slackware 10.X e 11.0
Como todos sabem, o Slackware Linux 10.X e 11.0 já trazem em meio a seus pacotes o MySQL.
O pacote vem instalado, mas não ativado.
A seguir segue uma dica rápida de como ativar:
root@slackware:~# sudo mysql_install_db
root@slackware:~# chown mysql.mysql /var/lib/mysql/ -R
"-R" para dar permissão ao usuário mysql sobre o diretório e subdiretórios do diretório).
root@slackware:~# chmod +x /etc/rc.d/rc.mysqld
root@slackware:~# /etc/rc.d/rc.mysqld start
Agora crie uma senha pra acesso ao BD MySQL:
root@slackware:~# mysqladmin -u root password sua_senha
Rápido, prático e simples como o próprio MySQL.
Créditos:
Rodrigo Ribeiro
http://www.vivaolinux.com.br/dicas/verDica.php?codigo=7613
quarta-feira, 21 de maio de 2008
LILO - Configurar tempo de inicialização
Para os iniciantes que não querem perder tempo esperando a contagem regressiva na inicialização so Linux, basta alterar o timeout no LILO.
Veja como:
*logo no linux como root
*entre na pasta /etc
*edite o arquivo lilo.conf
cd /etc
pico lilo.conf
*na linha 8, onde está timeou = 1200, troque para
timeout = 10
* o tempo está em milesegundos, entao 10 é 1 segundo, se vc colocar 1 não irá funcionar...
* agora, tecle CTRL + X p/ fechar e Y para salvar as alterações
* digite agora lilo (se nao digitar não irá salvar as alterações)
lilo
* é isso, simples e prático... boa sorte
By Eder Závoli
Veja como:
*logo no linux como root
*entre na pasta /etc
*edite o arquivo lilo.conf
cd /etc
pico lilo.conf
*na linha 8, onde está timeou = 1200, troque para
timeout = 10
* o tempo está em milesegundos, entao 10 é 1 segundo, se vc colocar 1 não irá funcionar...
* agora, tecle CTRL + X p/ fechar e Y para salvar as alterações
* digite agora lilo (se nao digitar não irá salvar as alterações)
lilo
* é isso, simples e prático... boa sorte
By Eder Závoli
sexta-feira, 16 de maio de 2008
NoCatAuth - Construindo um firewall/gateway autenticado
Por Patrick Brandão
http://www.patrick.eti.br
contato@patrick.eti.br
O programa NoCatAuth, criado pela nocat.net tem o propósito de evitar que pessoas não autorizadas tenham acesso a internet em rede wireless. Para isso, esse programa em Perl captura o tráfego na porta 80 e o desvia para um servidor HTTP, onde haverá uma página solicitando usuário e senha, e opcionalmente, uma página para cadastro.
O NoCat também pode ser usado para simplesmente obrigar o usuário a ler uma página de splash antes de navegar, onde se pode colocar um termo de uso, um aviso ou simplesmente a página do provedor de acesso.
O NoCat pode ser configurado para rodar em três modos:
O NoCatAuth funciona com duas instâncias nos modos PASSIVE e CAPTIVE, uma, NoCat Gateway, e outra NoCat Auth, o Gateway redirecionará o tráfego HTTP para a porta 80 do servidor Auth que após autenticar o usuário, se conectará na porta 5280 do Gateway para dar permissão de passagem ao host. A conexão do servidor Auth na porta 5280 do Gateway é criptografada com PGP para dar suporte a casos em que o servidor Auth tem uma conexão não confiável com o servidor Gateway.
Tomei a iniciativa de escrever este tutorial ao ver que não encontrava, nem no Google, nem na própria página no NoCat, um tutorial que me ensinasse com clareza como se usa este programa.
http://www.patrick.eti.br
contato@patrick.eti.br
O programa NoCatAuth, criado pela nocat.net tem o propósito de evitar que pessoas não autorizadas tenham acesso a internet em rede wireless. Para isso, esse programa em Perl captura o tráfego na porta 80 e o desvia para um servidor HTTP, onde haverá uma página solicitando usuário e senha, e opcionalmente, uma página para cadastro.
O NoCat também pode ser usado para simplesmente obrigar o usuário a ler uma página de splash antes de navegar, onde se pode colocar um termo de uso, um aviso ou simplesmente a página do provedor de acesso.
O NoCat pode ser configurado para rodar em três modos:
- OPEN - O tráfego na porta 80 é capturado e redirecionado para uma página de splash, após a página ter sido carregada, o acesso à internet é liberado para o host.
- PASSIVE - O tráfego dos usuários não autenticados para a porta 80 será capturado, após a autenticação, uma regra de firewall (iptables ou ipchains) permitirá o acesso à internet por meio de NAT.
- CAPTIVE - Semelhante ao PASSIVE, porém, ao se identificar com sucesso, o acesso à internet será liberado, mas sem NAT.
O NoCatAuth funciona com duas instâncias nos modos PASSIVE e CAPTIVE, uma, NoCat Gateway, e outra NoCat Auth, o Gateway redirecionará o tráfego HTTP para a porta 80 do servidor Auth que após autenticar o usuário, se conectará na porta 5280 do Gateway para dar permissão de passagem ao host. A conexão do servidor Auth na porta 5280 do Gateway é criptografada com PGP para dar suporte a casos em que o servidor Auth tem uma conexão não confiável com o servidor Gateway.
Tomei a iniciativa de escrever este tutorial ao ver que não encontrava, nem no Google, nem na própria página no NoCat, um tutorial que me ensinasse com clareza como se usa este programa.
Objetivo
 | ||||||||||||||||||
Tecnologias usadas e ambiente de laboratório
Instalação dos programas
Configuração
Iniciando o servidor
Créditos: Patrick Brandao http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=1338&pagina=1 |
Estrutura do Iptables
Introdução: o que esperar deste artigo
Ao contrário de outros artigos e tutoriais sobre iptables, este não se dispõe a ensinar sua sintaxe, como construir regras e como bloquear este ou aquele tipo de pacote. Artigos meus futuros poderão passear por este caminho, muito embora já se tenha muito material na Internet sobre isto.
Ele se destina a explicar a origem dos termos "tabelas" do iptables, o que é e para que servem as tabelas nat, filter e mangle. Onde, ou seja, em qual tabela se deve colocar as regras para este ou aquele objetivo.
Este artigo aproveita também para esclarecer algumas diferenças interessantes, como para que serve o REJECT e qual a diferença dele para o DROP?
Algumas definições serão relevantes e merecem serem citadas antes da leitura:
Quando falo de "nível" no artigo (ex: nível de Enlace) estou me referindo ao modelo de camadas TCP/IP, composto por apenas QUATRO camadas e não SETE como no modelo OSI. No modelo TCP as camadas são o ENLACE, onde se tem na sua imensa maioria o padrão de rede Ethernet como referência:
Em termos de nomenclatura geralmente se generaliza chamando tudo de pacote. Porém, quando se quer deixar mais específico em qual nível estamos lidando, pode-se se usar a nomenclatura "quadro" para o nível de Enlace, "datagrama" ip para o nível de rede e "pacote" para o de transporte (sendo que o TCP muitas vezes usam a palavra "segmento"). Na aplicação o que tem são dados.
Mas como o iptables atua em princípio nas camadas de rede, ip de origem ou de destino, e na de transporte (porta origem e destino), o pacote pode ser considerado, neste artigo, como um termo genérico (OBS: é certo que o iptables também permite atuar no enlace e até mesmo na aplicação, com os devidos módulos adicionados).
Créditos:
Elgio Schlemer
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=6834&pagina=1
Ele se destina a explicar a origem dos termos "tabelas" do iptables, o que é e para que servem as tabelas nat, filter e mangle. Onde, ou seja, em qual tabela se deve colocar as regras para este ou aquele objetivo.
Este artigo aproveita também para esclarecer algumas diferenças interessantes, como para que serve o REJECT e qual a diferença dele para o DROP?
Algumas definições serão relevantes e merecem serem citadas antes da leitura:
Quando falo de "nível" no artigo (ex: nível de Enlace) estou me referindo ao modelo de camadas TCP/IP, composto por apenas QUATRO camadas e não SETE como no modelo OSI. No modelo TCP as camadas são o ENLACE, onde se tem na sua imensa maioria o padrão de rede Ethernet como referência:
- O nível de REDE, responsável pelo roteamento, onde se tem o IP na sua versão 4 como mais significativo;
- O nível de TRANSPORTE, com seus pacotes UDP e TCP, dentre outros;
- O o nível de aplicação, com os protocolos FTP, HTTP, etc;
- O nível FÍSICO não faz parte do modelo de camadas TCP/IP, pois é restrito ao fabricante da placa.
Em termos de nomenclatura geralmente se generaliza chamando tudo de pacote. Porém, quando se quer deixar mais específico em qual nível estamos lidando, pode-se se usar a nomenclatura "quadro" para o nível de Enlace, "datagrama" ip para o nível de rede e "pacote" para o de transporte (sendo que o TCP muitas vezes usam a palavra "segmento"). Na aplicação o que tem são dados.
Mas como o iptables atua em princípio nas camadas de rede, ip de origem ou de destino, e na de transporte (porta origem e destino), o pacote pode ser considerado, neste artigo, como um termo genérico (OBS: é certo que o iptables também permite atuar no enlace e até mesmo na aplicação, com os devidos módulos adicionados).
Por onde passa um datagrama
O iptables, presente no Linux a partir do kernel 2.4, usa o conceito de "ganchos" do netfilter, permitindo avaliar um datagrama em alguns pontos dentro do kernel.
Conforme pode ser observado na Figura 1, um datagrama IP dentro do kernel do Linux passa por várias etapas. Basicamente um datagrama IP é de um dentre três tipos:
Conforme pode ser observado na Figura 1, um datagrama IP dentro do kernel do Linux passa por várias etapas. Basicamente um datagrama IP é de um dentre três tipos:
- O datagrama chegou por uma de suas interfaces, o nível de enlace viu o seu mac address no quadro ethernet. Contudo o datagrama não é destinado ao número IP desta máquina. Se a máquina não for configurada para atuar como roteador, o datagrama é descartado. Se a máquina estiver atuando como roteador, o datagrama deve ser roteado por ela.
- O datagrama chegou por uma de suas interfaces, o nível de enlace viu o seu mac address no quadro ethernet e ele é destinado ao IP desta máquina, logo deve ser entregue a um de seus processos locais (se for HTTP, por exemplo, deve ser entregue ao apache).
- O datagrama IP foi gerado por um de seus processos locais, por um cliente de email por exemplo, e deve ser repassado a outra máquina.
Cada datagrama passa por uma etapa de roteamento, onde o kernel decide para onde ele vai. Nesta etapa é que são consultadas, se for o caso, as tabelas de roteamento. Os do tipo 1 devem serem roteados para fora da máquina, que no caso deve estar atuando como roteador, sendo que na etapa de roteamento o kernel decide qual o próximo ponto de rota que deve ser usada. Se for para o IP desta máquina, é o roteamento que verifica isto (isto é, recebe o datagrama, vê que é local e entrega ao nível de transporte, que irá repassá-lo ao processo correspondente).
Da mesma forma, pacotes os gerados por processos locais também passam pelo roteamento para serem encaminhados. Logo, todos os datagramas passam, de uma forma ou de outra, pela etapa de roteamento.
Caso ele precise ser repassado a outra máquina (somente se ela estiver atuando como roteador IP), a etapa de "repasse de pacotes" realiza as alterações necessárias, como a reescrita total do cabeçalho de enlace (trocando o MAC origem para o seu), atualização do TTL, etc. Evidente que isto após a decisão de roteamento, pois a escrita do cabeçalho de enlace leva em conta o destino.
Ganchos do netfilter
O netfilter introduziu "ganchos", pontos ao longo do ciclo de vida de um datagrama onde o mesmo pode ser avaliado por regras de firewall. A Figura 2 destaca estes pontos.
Pode-se observar pela Figura 2, que:
Por existirem estes ganchos e a possibilidade de avaliar um datagrama e tomar decisões de firewall sobre ele nestes pontos, o iptables introduz filas de regras (listas) nestes pontos. Cada gancho pode possuir um ou mais conjuntos de regras.
Pode-se observar pela Figura 2, que:
- Um datagrama destinado ao processo local:
- Pode ser capturado para avaliação ao entrar na Interface, pelo gancho 1, chamado pelo kernel de PREROUTING.
- Pode ser capturado para avaliação pelo gancho 4, chamado pelo kernel de INPUT.
- Um datagrama gerado por um processo local:
- Pode ser capturado para avaliação pelo gancho 5, chamado pelo kernel de OUTPUT.
- Pode ser capturado para avaliação pelo gancho 3, chamado de POSTROUTING.
- Um datagrama que esteja apenas passando por esta máquina, não gerada e não destinada ao ip ela:
- Pode ser capturado para avaliação ao entrar na Interface, pelo gancho 1, chamado pelo kernel de PREROUTING.
- Pode ser capturado para avaliação pelo gancho 2, chamado pelo kernel de FORWARD.
- Pode ser capturado para avaliação pelo gancho 3, chamado de POSTROUTING.
Por existirem estes ganchos e a possibilidade de avaliar um datagrama e tomar decisões de firewall sobre ele nestes pontos, o iptables introduz filas de regras (listas) nestes pontos. Cada gancho pode possuir um ou mais conjuntos de regras.
Enfim, as tabelas
Ao todo são três as tabelas mais importantes do iptables:
A tabela filter deve conter apenas regras que determinam se um pacote deve ser aceito ou não. Nesta tabela não é possível colocar regras para alterar algum parâmetro, como ip ou porta.
A tabela nat serve para realizar operações de tradução sobre IP e/ou porta, tanto de origem como de destino, muito embora também permita recusá-lo (não será abordada neste artigo).
Por fim a tabela mangle serve para realizar alterações mais profundas e bizarras nos pacotes, como alterar o TTL, TOS, etc (não será abordada neste artigo).
As ações operadas sobre um pacote basicamente podem ser recusá-lo ou deixá-lo passar, mas o iptables possui várias maneiras de "recusar" e ainda permite realizar logs. Como dito, operações de alteração de pacotes, seja IP ou porta, não pode ser realizada na tabela filter, mas sim na nat ou mangle.
Em termos de filtragem, para impedir que pacotes que não queremos entrem na máquina, é a tabela filter que nos interessa.
- filter
- nat
- mangle
A tabela filter deve conter apenas regras que determinam se um pacote deve ser aceito ou não. Nesta tabela não é possível colocar regras para alterar algum parâmetro, como ip ou porta.
A tabela nat serve para realizar operações de tradução sobre IP e/ou porta, tanto de origem como de destino, muito embora também permita recusá-lo (não será abordada neste artigo).
Por fim a tabela mangle serve para realizar alterações mais profundas e bizarras nos pacotes, como alterar o TTL, TOS, etc (não será abordada neste artigo).
As ações operadas sobre um pacote basicamente podem ser recusá-lo ou deixá-lo passar, mas o iptables possui várias maneiras de "recusar" e ainda permite realizar logs. Como dito, operações de alteração de pacotes, seja IP ou porta, não pode ser realizada na tabela filter, mas sim na nat ou mangle.
Em termos de filtragem, para impedir que pacotes que não queremos entrem na máquina, é a tabela filter que nos interessa.
A tabela filter
Entram nesta tabela o conjunto de regras com finalidades gerais, como bloquear, negar, realizar logs. As regras existentes nesta tabela não tem poder de alterar as configurações dos pacotes. Basicamente todas as regras de filtragem estão nesta tabela, pois ela é de uso geral.
Para inserir uma regra em uma lista, pode-se usar -A para APPEND, inserindo-a no final, ou -I para INSERT, inserindo-a NO INÍCIO (a sintaxe profunda das regras não é o foco deste artigo).
A tabela filter possui três conjuntos de regras, ou seja, três listas sendo que cada uma delas está associada a um gancho:
A tabela filter é a tabela básica do iptables e são em suas listas que devem ser inseridas regras de filtragens gerais, que não são complexas, como proibir ou permitir ips, portas, etc. Na Figura 3 pode ser observado a atuação do conjunto de regras desta tabela sobre os ganchos.
Cada regra pode realizar uma determinada ação ao pacote (representado graficamente por -j), sendo que na filter as seguintes ações são possíveis:
Para inserir uma regra em uma lista, pode-se usar -A para APPEND, inserindo-a no final, ou -I para INSERT, inserindo-a NO INÍCIO (a sintaxe profunda das regras não é o foco deste artigo).
A tabela filter possui três conjuntos de regras, ou seja, três listas sendo que cada uma delas está associada a um gancho:
- INPUT: esta fila de regras recebe este nome justamente por ser aplicada aos pacotes na posição do gancho 4. Logo apenas os pacotes destinados ao ip da máquina atual serão avaliados por eventuais regras existentes nesta tabela. Sintaticamente para inserir regras nesta lista usa-se os parâmetros de iptables (o comando está incompleto):
iptables -t filter -A INPUT [regra] - OUTPUT: esta fila de regras recebe este nome justamente por atuar no gancho 5 (também chamado pelo kernel de OUTPUT). Logo serão avaliados pelas regras presentes nesta lista apenas os pacotes originados por processos locais da máquina. Sintaticamente para inserir uma regra nesta lista usa-se o comando:
iptables -t filter -A OUTPUT [regra] - FORWARD: esta fila de regras recebe este nome justamente por atuar no gancho 2 (também chamado pelo kernel de FORWARD). Logo serão avaliados por estas regras os pacotes que estão sendo repassados por esta máquina, não são para ela e nem originados por ela. Sintaticamente para inserir uma regra nesta lista usa-se o comando:
iptables -t filter -A FORWARD [regra]
A tabela filter é a tabela básica do iptables e são em suas listas que devem ser inseridas regras de filtragens gerais, que não são complexas, como proibir ou permitir ips, portas, etc. Na Figura 3 pode ser observado a atuação do conjunto de regras desta tabela sobre os ganchos.
Cada regra pode realizar uma determinada ação ao pacote (representado graficamente por -j), sendo que na filter as seguintes ações são possíveis:
- REJECT: o pacote, uma vez que casou com a regra, é rejeitado. Demais regras existentes são ignoradas e o pacote definitivamente já teve seu destino selado: será descartado. Se for usado REJECT o remetente do pacote será avisado com uma mensagem de erro, normalmente um ICMP de "porta inatingível" (mas o iptables permite ao usuário mudar o tipo de retorno se ele quiser). Em termos de segurança pode não ser interessante devolver uma resposta ao remetente, pois isto iria inevitavelmente dar a conhecer a ele o número IP do firewall.
- DROP: o DROP tem o mesmo efeito do REJECT e a mesma aplicação, com a diferença de que não é retornado nenhuma mensagem de erro ao remetente (ele não saberá o que aconteceu com o pacote). Em se tratando de FORWARD (repasse) pode ser conveniente usar DROP ao invés de REJECT para que um possível atacante não saiba o IP do firewall que rejeitou o seu pacote. Mas isto deve ser bem analisado, pois se o remetente não souber o que ocorreu, ele poderá ficar ainda tentando várias vezes até desistir por time out. Se o teu firewall é o roteador principal, não tem porque escondê-lo, pois ele é um ponto de rota mesmo. Mas se ele for transparente (atuando em modo bridge), aí pode ser uma boa estratégia não dar nada ao remetente.
- ACCEPT: Aceita um pacote, deixando que ele siga o seu percurso. O ACCEPT, como os anteriores, causa o término de teste nesta tabela, ou seja, o pacote já foi aceito e não será mais testado por nenhuma outra regra posterior nesta tabela (mas ainda poderá ser testado por outra tabela, como pela mangle ou nat, por exemplo. Acredito que o único exemplo onde isto possa acontecer é ele ser ACEITO no filter FORWARD, mas ser DROPADO no nat POSTROUTING, já que o nat tem também o poder de realizar DROP).
- LOG: realiza um log deste pacote no sistema (geralmente no /var/log/syslog ou messages). Ao contrário das demais ações (DROP, ACCEPT e REJECT), ao aplicar um log no pacote o mesmo ainda continua sendo testado pelas regras seguintes da fila atual. Uma ação do tipo LOG não causa o término do teste. Caso seja do interesse do usuário ele pode configurar uma mensagem de log que aparecerá nos logs facilitando a análise.
Conclusão
Este artigo teve como motivação apenas mostrar a estrutura interna do iptables e não ensinar a escrever regras sintaticamente corretas e poderosas.
Através do entendimento correto de como o iptables atua, pode-se determinar onde e de que forma pacotes devem ser filtrados:
Através do entendimento correto de como o iptables atua, pode-se determinar onde e de que forma pacotes devem ser filtrados:
- Se estou configurando um firewall pessoal, na minha máquina desktop ou no meu servidor, sendo que ela não é roteador: as regras para filtrar o conteúdo deverão ir na tabela filter, na lista INPUT para filtrar o que está entrando na minha máquina, destinada ao IP dela e na tabela filter, lista OUTPUT para os pacotes gerados pela minha máquina.
- Se estou configurando um firewall de rede, que filtra todo o conteúdo que entra e sai da minha rede para o mundo: as regras irão todas na tabela filter, lista FORWARD. Para representar o destino (está entrando ou está saindo) posso usar o parâmetro -i interface ou -o interface (o FORWARD é o único que permite -i e -o na mesma regra, querendo dizer, se estiver entrando por aqui e saindo por ali...).
- Se meu firewall é um firewall de rede, mas também possui alguns serviços nele, como proxy ou de email, devo inserir regras tando no filter INPUT/OUTPUT para definir a política dele enquanto servidor, como no filter FORWARD para proteger minha rede. Regras adicionadas no filter FORWARD não atuam sobre pacotes destinados ao número IP de uma máquina.
- Se desejo alterar características de ip ou porta, trocando-as, devo usar a tabela nat e para isto preciso aguardar o próximo artigo. :-D
Créditos:
Elgio Schlemer
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=6834&pagina=1
Assinar:
Postagens (Atom)