Marcelo Cavalcante - kalib : Dica Rápida - Linux - Como Limpar o Conteúdo de um Arquivo Texto Sem Abrir o Mesmo

Arquivos de log, por vezes, podem ser muito extensos. Tão extensos que torna-se praticamente impossível a leitura de seu conteúdo com um editor de textos como o vim ou vi. Além disso, muitos deles podem chegar a ocupar Gigas e mais Gigas de seu espaço em disco, o que pode acabar sendo um desperdício de espaço em seu sistema de arquivos.

Hoje passei por um problema deste tipo. Ao atualizar meu Arch Linux, percebi que comecei a receber erros devido ao meu espaço em disco o qual era apontado como “insuficiente”. O fato é que é muito comum em distribuições Linux utilizarmos um particionamento de forma a isolarmos um pouco cada partição para fins específicos. No meu caso, verifiquei que a minha partição raíz estava mesmo completamente cheia.

1
2
3

 [kalib@tuxcaverna ~]$ df -h /
 Sist. Arq.      Tam. Usado Disp. Uso% Montado em
 /dev/sda3        30G   30G   0M  100% /

Para resolver meu problema comecei limpando os pacotes que ficam em cache desnecessariamente através do pacman:

1

 [kalib@tuxcaverna ~]$ pacman -Sc

Em seguida resolvi verificar quanto de espaço eu estava consumindo com logs de sistema:

1
2

 [root@tuxcaverna ~]# cd /var/log
 [root@tuxcaverna ~]# du -h .

O comando acima me mostrou que meu diretório de logs estava consumindo mais de 13G. Insano, certo? Na verdade, não. É comum que ao longo dos meses, ou mesmo anos, o sistema acumule logs e mais logs. Uma quantia absurda e, muitas vezes, desnecessária de informações. Como trata-se de meu notebook pessoal e não estou tendo qualquer erro em meu sistema, resolvi limpar estes logs, portanto o primeiro passo é identificar os maiores arquivos. No meu caso foram os arquivos:

1

 everything.log    kernel.log    daemon.log

Uma vez que cada um destes arquivos possuía mais de 3G, resolvi limpá-los completamente. A saída mais rápida e KISS? /dev/null neles.

1

 [root@tuxcaverna ~]# cat /dev/null >everything.log

Isto limpará completamente o conteúdo do arquivo de texto informado. Vejamos o simples exemplo a seguir:

Vamos criar um arquivo de texto vazio chamado teste.txt.

1

 [root@tuxcaverna ~]# touch teste.txt

Em seguida, vamos inserir algum conteúdo no mesmo:

1

 [root@tuxcaverna ~]# echo "Testando" >teste.txt

Verifiquemos se meu texto realmente foi inserido no arquivo:

1
2

 [root@tuxcaverna ~]# cat teste.txt
 Testando

Tudo certo. Agora vamos limpar o mesmo:

1

 [root@tuxcaverna ~]# cat /dev/null >teste.txt

Agora, vamos confirmar se o mesmo foi mesmo zerado:

1
2

 [root@tuxcaverna ~]# cat teste.txt
 [root@tuxcaverna ~]#

Missão cumprida. Apenas para constar a diferença:

1
2
3

 [kalib@tuxcaverna ~]$ df -h /
 Sist. Arq.      Tam. Usado Disp. Uso% Montado em
 /dev/sda3        30G   16G   13G  56% /

Magnun Leno : Web2py: Abstraindo a DAL Corretamente

Por mais que o Web2Py já possua uma camada de abstração para o acesso ao banco de dados, conhecida como DAL, e que ela seja excelente, eu não acho que ele incetiva da forma correta a segmentação e reutilização de códigos. Como eu já mostrei anteriormente aqui é possível implementar um modelo simples que “corrige” esses problemas, entretanto, a forma que apresentei não é a mais elegante de todas, pois ela utiliza a sintaxe de dicionários para controlar o acesso às colunas do banco de dados.

A forma mais Pythonica de controlar este tipo acesso é através de Properties. Mas convenhamos, é extremante exaustivo escrever códigos para getters e setters para cada coluna de cada tabela do banco de dados.

Continue reading...

Marcelo Cavalcante - kalib : Correção do Bug entre Kernel Linux e Placas Broadcom

Bug capturado e tratado!

Diversas pessoas se depararam com intermináveis erros de kernel panic após atualizar seu kernel para a versão 3.10.6 (e posteriores) quando utilizavam placas wireless da Broadcom. O erro reportado foi tratado e, apesar de ainda não estar resolvido no último kernel lançado, 3.10.10, já se encontra na árvore de Linus Torvalds, conforme código e correção podem ser vistos através do seguinte link:

mac80211: add a flag to indicate CCK support for HT clients

O problema se dava com o módulo brcm80211 que não conseguia lidar adequadamente com o envio de frames com taxas CCK como parte de uma sessão A-MPDU. Apesar de outros drivers/módulos da broadcom conseguirem conectar-se sem o kernel panic logo na inicialização do sistema, estes ainda podem enfrentar problemas em outros momentos sem esta correção. O patch corrige o erro reportado com módulos brcmsmac bem como outros.

Atualmente estou utilizando o último kernel disponibilizado, o 3.10.10. Apesar de a correção ainda não ter saído nesta versão, estou utilizando uma versão do kernel com o patch já aplicado.

Esperemos pelo kernel 3.11 que deverá ser lançado nos próximos dias e que, por sua vez, deverá resolver este problema definitivamente.

Marcelo Cavalcante - kalib : Tornando Seu SSH Mais Seguro

O SSH (Secure Shell) é um dos protocolos mais utilizados atualmente para transferência de arquivos ou mesmo conexão remota, principalmente em ambientes Linux/Unix e, por si só, já tem se provado ser confiável e seguro. O mesmo passou a ser o principal substituto ao TELNET por possuir a vantagem da criptografia na conexão entre o cliente e o servidor, além da possibilidade de criação de túneis, o que chamamos de tunneling, oferecendo assim a capacidade de redirecionar pacotes de dados. Mas não é por isso que devemos nos descuidar…

Sempre existe espaço para melhorias.

As configurações do servidor SSH, geralmente, ficam localizadas em /etc/ssh/sshd_config. Vale lembrar que a cada alteração feita neste arquivo será necessário reiniciar o serviço SSH para que suas alterações possam ser efetivadas.

Indo ao que interessa:

1- Altere a porta de escuta do SSH

Por padrão o SSH aceita conexões na porta 22, portanto é importante alterar esta porta para dificultar as tentativas de ataques aleatórios de brute-force que buscam máquinas que disponibilizam o SSH através da porta padrão. Preferivelmente, é interessante optar por uma porta posterior a 1024, visto que a maioria dos softwares de escaneamento de portas e serviços não fazem uma varredura por portas muito altas. Esta é geralmente uma das primeiras configurações no arquivo /etc/ssh/sshd_config, conforme pode ser visto abaixo:

1

 Port 22

2- Permita apenas o protocolo SSH 2

Dependendo de sua distribuição Linux, o padrão poderá ser a utilização de ambos os protocolos, 1 e 2. A versão 1 do protocolo SSH possui vulnerabilidades bastante conhecidas, portanto é preferível que utilize apenas o protocolo de versão 2, diminuindo assim suas chances de um ataque de inserção, por exemplo, conforme possível com a versão 1 do protocolo. Procure pela seguinte linha de configuração e altere-a mantendo apenas a opção 2:

1

 Protocol 2,1

3- Decida quais usuários poderão logar-se via SSH

Permitir que qualquer usuário possa logar-se via SSH não é aconselhável, da mesma forma que permitir que o usuário root efetue login via SSH também é extremamante desencorajado devido às vulnerabilidades envolvidas. Por possuírem determinados (ou todos, no caso do root) privilégios no sistema, alguns usuários simplesmente não devem ter permissão de login via SSH, evitando assim que alguém utilize ferramentas de brute-force e consiga, por quebra de senha, logar-se em seu servidor com um usuário privilegiado. Para proibir o login do usuário root via SSH, altere a seguinte linha para no:

1

 PermitRootLogin yes

Para definir quais usuários poderão ter acesso via SSH, insira o nome dos mesmos na seguinte linha, conforme exemplo abaixo:

1

 AllowUsers usuario1 usuario2 usuario3

4- Utilize uma chave pública DSA como mecanismo de autenticação

Ao invés de utilizar nomes de usuários e senhas para autenticar-se via SSH, você pode utilizar chaves públicas DSA. Outra opção é utilizar ambos os mecanismos, usuário e senha + chave. Uma das maiores vantagens de se utilizar chaves como mecanismo de autenticação é que você impossibilitará o acesso indevido através de ataques de força bruta ou brute force, pois você não precisará de um login e senha para logar-se ao servidor ou estação. Ao invés disso, você utilizará um par de chaves – uma pública e uma privada. No cenário de chaves DSA, a chave privada fica em sua máquina e uma cópia da chave pública fica no servidor que você deseja acessar via SSH.

Ao tentar logar-se em um servidor configurado para autenticação via chave DSA, o mesmo verifica as chaves de ambos os lados e, se elas combinarem, autoriza seu login, caso contrário nega sua conexão.

No arquivo de configuração do servidor SSH você irá procurar os seguintes parâmetros e deixá-los da seguinte forma:

1
2
3

 RSAAuthentication yes
 PubkeyAuthentication yes
 AuthorizedKeysFile %h/.ssh/authorized_keys

Caso você deseje utilizar apenas a autenticação por chaves DSA, você precisará desabilitar a autenticação por senha, deixando como no o seguinte parâmetro:

1

 PasswordAuthentication no

Agora que as regras de configuração para a autenticação via chaves foram criadas, vamos criar as chaves em si.

Em sua máquina, vamos digitar o seguinte comando para a criação de suas chaves pública e privada:

1

 $ ssh-keygen -t dsa -C "$(whoami)@$(hostname)-$(date -I)"

O sistema lhe perguntará se você deseja escolher um diretório no qual salvar suas chaves. Caso você não especifique nenhum, ele salvará no diretório .ssh que se encontra no home de seu usuário (~/.ssh/id_dsa). Em seguida lhe perguntará se você deseja criar uma senha para sua chave (não é obrigatório).

Ao finalizar este procedimento você receberá a confirmação de que o procedimento foi realizado. Algo similar a isto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

 Your identification has been saved in /home/username/.ssh/id_dsa.
 Your public key has been saved in /home/username/.ssh/id_dsa.pub.
 The key fingerprint is:
 dd:15:ee:24:20:14:11:01:b8:72:a2:0f:99:4c:79:7f username@localhost-2013-08-28
 The key's randomart image is:
 +--[DSA  1024]---+
 |     ..oB=.   .  |
 |    .    . . . . |
 |  .  .      . +  |
 | oo.o    . . =   |
 |o+.+.   S . . .  |
 |=.   . E         |
 | o    .          |
 |  .              |
 |                 |
 +-----------------+

O próximo passo é copiar a sua chave pública para o servidor que você deseja acessar via SSH. Você pode copiar de algumas formas diferentes:

4.1 – Copiando manualmente

Copie o conteúdo retornado através do seguinte comando:

1

 $ cat ~/.ssh/id_dsa.pub

O retorno será algo similar a isto:

1
2
3
4
5
6
7

 ssh-dss AAAAB3NzaC1kc3MAAACBAKWJtlUANTuqKy1NN4bb5qBJLZVMnR+nr84hk7EWnHmpJgipRZ8Y/tUDJTpCab
 GwoMNYmPZaz62Nm5/F5Nl9yzgMmxfGja8OYt3bwir6A379NOWFM2NBq7Q107uH4L+MFszXKoCVn6rM9SddkAJL1V66
 eGX+Y+r1o/8wG773h9P5AAAAFQDh09qovWFzKJk0E58c0oRz9S4UAQAAAIBuVxw+LZDrWVVCLr4WMubRPJuFzXqqHN
 re9RUZ2kMrUENnAenYyJgjcBg7uJJA/wMfn7Oe32e4hvpU7SsXEUf7xT1sKb/UFyX9qTr5G0kkU6t8IYPjIQaqRIOQ
 mnRiqm7JCDd1GTAFU9n/ocK4sNPZDL8KeEEquZmk+ihKcu9FLwAAAIBlz+K7fcZSlA5hKewHOF7fA9IdwdMsbc2Ri7
 bSw4Fv70rQeMnYYUDeHQQJHeJJyScmuHswordGXYKe2tsf7fYn11CW46P9WxCRcargojxJNrRHlF5WiK15fhNMLtfx
 7/+CSmoXnEUCw8uCCBVduGLyevZ3WC+FEx7/aqJjuUCNJg== username@localhost-2013-08-28

É exatamente este conteúdo que precisa ser copiado.

Em seguida você precisará colar este conteúdo no servidor desejado, porém incrementando dentro do seguinte arquivo (no servidor): ~/.ssh/authorized_keys

Para facilitar, você poderá já ter copiado o arquivo da chave completo para o servidor. Veja nos próximos métodos algumas formas de o fazer.

4.2 – Método Simples – Deve ser usado antes de configurar o servidor para permitir autenticação por chaves

Se o seu arquivo de chave é ~/.ssh/id_dsa, você poderá simplesmente digitar o seguinte comando para enviar a chave para o servidor:

1

 $ ssh-copy-id servidor-remoto.com.br

Caso o nome de usuário em sua máquina seja diferente do nome de usuário no servidor, lembre-se de adicionar o nome do usuário do servidor antes do endereço do mesmo:

1

 $ ssh-copy-id nome-de-usuario@servidor-remoto.com.br

Caso o servidor esteja recebendo as conexões SSH em uma porta diferente da padrão (22), utilize (supondo que estamos utilizando a 221):

1

 $ ssh-copy-id -p 221 nome-de-usuario@servidor-remoto.com.br

4.3 – Método Tradicional – Deve ser usado antes de configurar o servidor para permitir autenticação por chaves

Por padrão a chave pública precisa ser concatenada no arquivo ~/.ssh/authorized_keys. Comece copiando a chave pública para o servidor remoto:

1

 $ scp ~/.ssh/id_dsa.pub nome-do-usuario@servidor-remoto.com.br:

O comando acima copiará a chave pública para o diretório home do usuário citado para o servidor via scp. Não esqueça de inluir o : ao final do endereço do servidor.

Caso o diretório ~/.ssh ainda não exista no servidor, você precisará criá-lo. O mesmo com o arquivo authorized_keys:

1
2
3
4
5
6

 $ ssh nome-do-usuario@servidor-remoto.com.br
 nome-do-usuario@servidor-remoto's password:
 $ mkdir ~/.ssh
 $ cat ~/id_dsa.pub >> ~/.ssh/authorized_keys
 $ rm ~/id_dsa.pub
 $ chmod 600 ~/.ssh/authorized_keys

Os últimos dois comandos removem a chave pública do diretório do servidor e definem as permissões para o arquivo authorized_keys de forma que ele apenas possa ser lido ou escrito por você, o dono.

Pronto, sua chave já está no servidor após seguir uma das dicas acima.

Lembre-se sempre de reiniciar o serviço ssh após efetuar qualquer alteração de configuração.

Dicas simples de serem implementadas mas que irão melhorar bastante a segurança de seu servidor SSH. ;]