Hoje em dia, muitos administradores de sistemas já possuem o hábito de utilizar sudo, porém, seu arquivo de configuração
‘/etc/sudoers’ possue a seguinte entrada:
sysadmin ALL=(ALL) ALL
Isso permite que o sysadmin execute qualquer comando como root. Mas, e quando queremos que sysadmin execute determinadas tarefas, e queremos que logadmin execute outras, ambos com poder de root?
sysadmin ALL=(ALL) ALL
logadmin ALL=(ALL) ALL
Isso resolveria o problema, mas não seria correto, já que teriamos duas pessoas com poderes administrativos.
E, se por acaso, logadmin executar um comando do tipo ’sudo su’, e remover ou alterar arquivos de configuração?
Isso ficaria gravado nos logs do usuário root. Como evitar este tipo de situação?
Aplicando configurações corretas ao arquivo ‘/etc/sudoers’.
Para começar, vamos instalar o pacote sudo, caso você ainda não o tenha:
#aptitude install sudo
Depois, vamos editar o arquivo de configuração do sudo com o comando ‘visudo’.
#visudo
Provavelmente, teremos uma linha igual a esta:
root ALL=(ALL) ALL
Isso quer dizer que o usuário root pode executar comandos em qualquer host, como qualquer usuário, e qualquer comando?
Como assim???
Segue a explicação:
User Host = (Run As) Authentication Command
O primeiro campo é o usuário que pode executar o sudo.
O segundo, é com qual usuário a aplicação será executada.
O terceiro, se será ou não exigida autenticação do usuário.
O ultimo, é o comando em si.
Então, vamos imaginar a seguinte situação.
O grupo SYSADMINS, composto por john, jane e irene, podem executar as seguintes tarefas:
Verificar e instalar pacotes com aptitude e dpkg, examinar quaisquer arquivos do /var/log, e editar qualquer arquivo do /etc e executar qualquer comando dos diretórios bin e sbin, enquanto que o grupo LOGADMINS pode apenas verificar os logs e reiniciar o sysklogd, enquanto que o estagiário pode executar apenas ps como root (ele está aprendendo) =)
O nosso arquivo ficaria assim:
# /etc/sudoers
#
# This file MUST be edited with the ‘visudo’ command as root.
#
# See the man page for details on how to write a sudoers file.
#
#!/bin/bash
#Script para sincronização de dados, funciona para midias externas e para o nosso NFS.
#Este script checa de maneira primária se o disco está montado ou se o NFS está ativo.
#Bom para utilizar no cron =)
Origem=Coloque o diretório de origem aqui
DestinoNFS=Coloque o diretório de destino NFS aqui
DestinoUSB=Coloque o diretório de destino USB aqui
#função que sincroniza o NFS
SyncNFS ( ) {
rsync -Cavz --delete $Origem $DestinoNFS 2> /dev/null | \
zenity --title="Sincronizando NFS" --progress --auto-close
}
#Função que sincroniza com Disco USB
SyncUSB ( ) {
rsync -Cavz --delete $Origem $DestinoUSB 2> /dev/null | \
Recentemente, precisei de um storage para testar alguns FileSystems distribuidos, OCFS2 e GFS, especificamente. Também queria um storage para brincar de Xen Live Migration mas…
Droga. Storages são caros. :/
Conversando com um colega de trabalho, ele mencionou um daemon chamado iscsitarget. Funcionou que é uma beleza.
Para quem não conhece, iSCSI é uma tecnologia que permite enviar comandos scsi encapsulados em pacotes TCP/IP.
No meu ambiente de testes, eu utilizei uma partição de 6G em um disco IDE para ser o “Storage”, e utilizei dois computadores para trabalhar como clientes. :)
Bom, para começar, vamos instalar o daemon.
#aptitude install iscsitarget
Não vou entrar em detalhes sobre os arquivos de configuração e autenticação agora. Por enquanto, basta saber que precisamos apenas alterar os parametros referentes a identificação do volume.
#vi /etc/iscsi/iscsid.conf
Dentro do arquivo, procure pela seção “Target”.
Edite ao seu gosto. No meu caso, ficou assim:
iqn.2008-02.br.com.dominio:storage.disk1
Depois de configurado, vamos instalar os clientes.
Depois desses comandos, sua unidade está conectada e pronta para ser formatada.
Agora, é só aplicar o filesystem (no meu caso, OCFS2) e se divertir com os testes e brincadeiras. Conheço alguns DBA’s que vão adorar brincar com isso ;)
Olá. Faz tempo que tenho observado várias tentativas de brute force em alguns serviços, como o SSH por exemplo.
Procurando na web, acabei deparando-me com uma ferramenta interessante, o denyhosts .
O Denyhosts faz uma verificação nos arquivos de log buscando por ocorrencias frustradas de login via ssh (ou algum outro serviço, desde que especificado), e, de acordo com o seu arquivo de configuração, coloca o ip automaticamente no arquivo /etc/hosts.deny.
Simples, prático e com um arquivo de configuração 100% comentado, o que torna mais prática a configuração e adição de outros serviços.
Além disso, é possível fazer upload e download da base de dados dos ips, o que possibilita automatizar o processo e compartilhar de uma base contendo ip’s que disparam ataques pela web.
Claro que esta ferramenta não se compara a um IDS/IPS completo, porém, há casos em que um sistema sofisticado não é necessário. ;)
Outra ferramenta similar à esta é o fail2ban , porém, que tem o mesmo principio de funcionamento, porém, ao invés de colocar o ip no hosts.deny, o fail2ban cria uma regra de firewall impedindo o acesso daquele ip ao seu servidor.
Ok. Você pegou uma cerveja, uma bacia, água quente, sentou relaxadamente na frente do PC, pronto para uma seção de navegação sem propósito. Sim, você está pronto para cruzar websites aleatórios, porém, para onde ir?
Quando você vai ao google, só consegue procurar por coisas relacionadas à trabalho. E agora?
Loading ...