Ao atualizar a versão do SAMBA do meu servidor me deparei com um problema na autenticação de usuário no proxy, no qual foi resolvido realizando as seguintes alterações

Problema:

debian:/etc/samba/netlogon# /usr/lib/squid/smb_auth -W domínio -U IP -d
marcelo senha
Domain name: sfs
Pass-through authentication: no
Query address options: -U 192.168.1.102 -R
Domain controller IP address: 192.168.1.102
Domain controller NETBIOS name: SAMBA
Contents of //SAMBA/NETLOGON/proxyauth:
ERR

Passos realizados

Servidor: Debian 5.0.4

ii samba 2:3.2.5-4lenny9 a LanManager-like file and printer server fo
ii samba-common 2:3.2.5-4lenny9 Samba common files used by both the server a
ii smbclient 2:3.2.5-4lenny9 a LanManager-like simple client for Unix

ii sarg 2.2.5-2 squid analysis report generator
ii squid 2.7.STABLE3-4.1lenny1 Internet object cache (WWW proxy cache)
ii squid-common 2.7.STABLE3-4.1lenny1 Internet object cache (WWW proxy cache) - co

Acessar o arquivos /usr/lib/squid/smb_auth.sh e adicionar as seguintes entradas:

Linha original:
authinfo=`$SAMBAPREFIX/bin/smbclient “//$dcname/$AUTHSHARE” -I $dcip -d 0
-E -W “$DOMAINNAME” -c “get $authfilebs -” 2>/dev/null`

Linha modificada:
authinfo=`$SAMBAPREFIX/bin/smbclient “//$dcname/$AUTHSHARE” -U $USER -I
$dcip -d 0 -E -W “$DOMAINNAME” -c “get $authfilebs -” 2>/dev/null`

Repare que adicionei o parâmetro -U $USER no comando smbclient, esta é
uma exigência da nova verão do Samba, agora o comando deverá ser
executado corretamente no seu servidor. Veja como funcionou no meu:

debian:/etc/samba/netlogon# /usr/lib/squid/smb_auth -W sfs -U 192.168.1.102 -d
marcelo senha
Domain name: sfs
Pass-through authentication: no
Query address options: -U 192.168.1.102 -R
Domain controller IP address: 192.168.1.102
Domain controller NETBIOS name: SAMBA
Contents of //SAMBA/NETLOGON/proxyauth: allow
OK

Red Hat / CentOS

Muito simples a instalação de um servidor telnet.

# yum install telnet-server

Verificar se o pacote foi instalado.

# rpm -qa |grep telnet

Saída
Exemplo:
[root@cls01 ~]# rpm -qa |grep telnet
telnet-server-0.17-39.el5
telnet-0.17-39.el5
[root@cls01 ~]#

Depois realizar a seguinte configuração

[root@cls01 xinetd.d]# pwd
/etc/xinetd.d
[root@spounix xinetd.d]# cat telnet
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = no
}

Acessar o arquivo e realizar a alteração na linha “disable=yes para disable=no”.

# vim /etc/xinet.d/telnet

Depois dar um restart no serviço.

# service xinetd restart

Sobre o logrotate, uma importante ferramenta de administração dos logs do sistema.

Fonte: logrotate man pages - Erik Troan <ewt@redhat.com> e Preston Brown <pbrown@redhat.com>

O logrotate é desenhado para facilitar a administração de sistemas que geram muitos arquivos de log. Todo usuário deve sempre vigiar os arquivos de log porque estes ocupam espaço no disco rígido. Os arquivos de log são importantes porque neles estão contidos os erros do sistema, erros esses que podem ser corrigidos. Entretanto se os arquivos de log não sofrerem rotação, ou seja, não forem apagados e recriados, irão crescer infinitamente.

Normalmente o logrotate é rodado pelo cron, com tarefas diárias, semanais ou mensais, porém é possível o uso direto através do comando logrotate.

Sintaxe do comando

logrotate -<opção>/<arquivo de configuração>

EX:

# logrotate -v /etc/logrotate.conf

*  -d - Debug. É apenas para listar na tela o resultado do comando e não altera os logs.
* -f - Force. Força o início da rotação mesmo se o sistema ache desnecessário.
* -m - Mail Diz qual comando usar para enviar um email com os logs.
* -s - State. Diz ao logrotate para usar um arquivo alternativo. The default arquivo de status é /var/lib/logrotate/status.
* -usage - Usabilidade. Imprime uma curta mensagem.

O /etc/logrotate.conf
Este é o arquivo importante para a manutenção, rotação, envio por email e exclusão dos arquivos de log. Alguns scripts especiais são incluídos na pasta /etc/logrotate.d e são lidos pelo logrotate através do logrotate.conf. Veja algumas dicas para a configuração deste arquivo:

Rotação dos logs [rotate log files weekly]

Neste ítem você deve decidir de quando em quando é feita a rotação. Pode ser diária(daily), semanal(weekly), mensal(monthly). Os arquivos de log que não tiveram indicação clara desta rotação seguirão o padrão indicado neste item.

Você também pode definir diretamente a rotação desejada deste modo:

# rotate /var/log/wtmp

/var/log/wtmp {
daily
create 0664 root utmp
rotate 1
}

Guardando os logs rotacionados para análise futura [keep 4 weeks wrth of backlogs]

Neste ítem você define quantos backups dos logs você manterá. Se um arquivo é rotacionado semanalmente, você pode definir que o sistema guarde as últimas semanas, no exemplo acima apenas a semana anterior será guardada em um arquivo chamado /var/log/wtmp.1. A sintaxe é:

rotate <número>

Criando logs vazios [create new (empty) log files after rotating old ones]

É importante deixar esta opção, porque assim o logrotate criará um novo arquivo, com as mesmas permissões do anterior, para substituir o antigo, como no exemplo: create.

Comprimindo os logs rotacionados

Você também pode salvar os logs rotacionados não eliminados em arquivos comprimidos, habilitando esta opção acima, a opção compress.

Abaixo as opções que você pode utilizar no logrotate.conf.

* -compress - comprimir os logs.
* -compresscmd - comprimir os logs com especificação do comando a utilizar. O padrão é gzip.
* -uncompresscmd - definir o comando para descomprimir os logs. O padrão é gunzip.
* -compressext - especifica a extensão usada para o arquivo de log comprimido.
* -compressoptions - para possibilitar incluir opções aos comandos de compressão. Por exemplo: gzip -5. O padrão é a compressão máxima (-9).
* -copy - copia o log sem modificar o original.
* -copytruncate - copia o log e move o original para outro lugar.
* -create [mode owner group] - Este é o comando usado para a criação de um novo arquivo de log vazio após a rotação. Você pode alterar as permissões, o dono do arquivo e o grupo.
* -daily - rotacionar diariamente.
* -delaycompres - Atrasa a compressão do log para a próxima rotação.
* -extension [ext] - Inclui uma extensão para o arquivo de log. Se a compressão usada for a padrão a extensão será .gz.
* -ifempty - Rotaciona os logs mesmo quando vazios.
* -include [file or directory] - Indica outros arquivos de configuração ou diretórios que tenham arquivos de configuração para o logrotate.
* -mail - envia um email com logs extintos.
* -mailfirst - envia um email com os logs rotacionados.
* -maillast - envia um email com os logs que serão rotacionados, os logs originais.
* -missingok - não enviar mensagem de erro no caso de um arquivo de log não existir.
* -monthly - rotaciona os logs mensalmente.
* -nocompress/nocopy/nocopytruncate/nocreate/nodelaycompress/nomail - negativas aos comandos correspondentes.
* -nomissingok/noolddir/nosharedscripts/notifempty - negativas aos comandos correspondentes.
* -olddir [directory] - guardar as versões rotacionadas em outro diretório.
* -postrotate/endscript - comandos a serem executados após a rotação do log.
* -prerotate/endscript - comandos a serem executados antes da rotação do log, caso o log seja rotacionado.
* -firstaction/endscript - comandos a serem executados imediatamente antes dos prerotates comandos.
* -lastaction/endscript - comandos a serem executados depois daqueles invocados através do -postrotate.
* -rotate - comando para rotacionar os logs.
* -size - rotacionar os logs quando ultrapassarem o tamanho indicado.
* -sharedscripts - postrotate e prerotate serão executados para cada log que tenha a mesma identificação. Este comando faz com que sejam executados apenas uma vez.
* -start - inclui um número para a base dos logs rotacionados, por exemplo: start 0 - log.0.
* -tabooext [+] list - mudar a lista de extensões taboo.
* -weekly - rotacionar semanalmente.

Exemplo de arquivo suplementar para o logrotate
Veja o exemplo do syslog:

/var/log/cron /var/log/debug /var/log/maillog /var/log/messages /var/log/secure /var/log/spooler /var/log/syslog {
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslog.pid 2>/dev/null` 2>/dev/null || true
endscript
}

Todos os logs indicados serão rotacionados, sem previsão de periodicidade que será fornecida pelo logrotate.conf e após a rotação será executado o comando kill nas condições indicadas pelo postrotate.

Conclusão
Utilizar o logrotate é fundamental porque os logs crescem infinitamente. Configurar o logrotate.conf para atender da melhor forma possível as suas necessidades também é fundamental.

Você pode incluir outros logs no sistema e é importante também incluir a rotação destes logs. Logs de firewall, por exemplo, tendem a crescer rapidamente.

Leia o manual do logrotate para maior ajuda e veja se o seu sistema está rotacionando os logs.

Para que seja possível este tipo de conexão em um servidor sshd é necessário o uso de criptografia. Será usada criptografia assimétrica, ou seja, chaves pública e privada.

A pública será colocada na máquina remota, é a chave que pode ser distribuída livremente, enquanto a privada deve ser guardada a sete trancas, pois é na chave privada que se baseia toda a segurança deste método.

Conexões deste tipo são bastante utilizadas na execução de scripts por acesso remoto, onde há a necessidade de preservar a integridade do sistema e a segurança da máquina.

PASSO 1 - Criação das chaves

Primeiramente deve-se estar logado com o usuário no qual deseja gerar a chave.

Digite no console:

$ ssh-keygen -b 1024 -t rsa

Onde:
ssh-keygen é o comando;
-b 1024 quantidade de bits que compõe a chave;
e -t rsa tipo de algoritmo usado para gerar a chave, a qual pode ser RSA (Rivest, Shamir and Adleman) ou DSA (Digital Signature Algorithm), que são evoluções do padrão de criptografia conhecido como DES (Data Encryption Standard).
Como referência a nível de segurança, os sítios bancários e e-commerce atualmente usam chaves de 128 bits. Para se ter um pouco mais de segurança a chave deverá ter no mínimo 128 bits, abaixo disto é insatisfatório. Uma chave 1024 bits é o suficiente para ter uma ótima segurança.

OBS: o sshd versão 1 trabalha somente com o algoritmo rsa, já na versão 2 trabalha tanto com algoritmos rsa como dsa.

Responda as solicitações no console, veja a tradução ao lado:

$ ssh-keygen -b 1024 -t rsa

Generating public/private rsa key pair. [Gerando o par de chaves pública/privada]
Enter file in which to save the key (/home/admin/.ssh/id_rsa): [Entre em qual arquivo a chave será salva]

Created directory ‘/home/admin/.ssh’. [criando o diretório]
Enter passphrase (empty for no passphrase): [entre com a frase senha, vazio para sem]
Enter same passphrase again: [confirme a frase senha]
Your identification has been saved in /home/admin/.ssh/id_rsa. [sua identificação foi salva em]
Your public key has been saved in /home/admin/.ssh/id_rsa.pub. [sua chave pública foi salva em]
The key fingerprint is: [a chave fingerprint is]
a6:af:64:cd:05:4e:3a:6e:64:fb:45:57:43:a1:a8:4d admin@apore.in.planalto.gov.br

Se for informado alguma frase senha, ela será solicitada no lugar da senha do usuário toda vez que a conexão for solicitada. Digite apenas enter para que fique vazia e nenhuma senha será solicitada.

O key fingerprint é a confirmação que as chaves foram salvas nos arquivos especificados.

PASSO 2 - Distribuir a chave pública

Ambas as chaves pública/privada serão criadas no diretório que foi especificado no passo anterior. Respectivamente /home/admin/.ssh/id_rsa.pub e /home/admin/.ssh/id_rsa. A chave privada ‘/home/admin/.ssh/id_rsa’ é a base da segurança, nunca a distribua!

A chave pública ‘/home/admin/.ssh/id_rsa.pub’ é a que deve ser distribuída para que tenha a validação autenticada do usuário.

$ scp ~/.ssh/id_rsa.pub Servidor_Remoto:/tmp
ou
$ scp ~/.ssh/id_rsa.pub Servidor_Remoto:/home/admin

Ou também pode ser utilizado um pendrive, disquete, ou qualquer outra mídia para transportar a chave pública.

PASSO 3 - Configurando o SSH para trabalhar com a chave pública

O sshd trabalha verificando as chaves autorizadas no arquivo ~/ssh/authorized_keys. Então após distribuídas as chaves nas máquinas remotas deve-se fazer a sua configuração para começar a utilizar autenticação assimétrica. Há duas maneiras para que façamos a configuração.

1. Configuração para apenas 01 validação RSA e/ou DSA:

RSA:

$ mv /tmp/id_rsa.pub ~/.ssh/
$ ln -s ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys

Ou também:

$ mv /tmp/id_rsa.pub ~/.ssh/authorized_keys

DSA:

$ mv /tmp/id_dsa.pub ~/.ssh/
$ ln -s ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys2

Ou também:

$ mv /tmp/id_dsa.pub ~/.ssh/authorized_keys2

2. Configuração para vários usuários com validação RSA e/ou DSA:

RSA:

$ cat /tmp/id_rsa.pub >> ~/.ssh/authorized_key

DSA:

$ cat /tmp/id_dsa.pub >> ~/.ssh/authorized_key2

OBS: Execute o comando específico para chave que está em uso para cada usuário remoto.

O NFS é um sistema de arquivos criado com o objetivo de compartilhar arquivos e diretórios entre computadores de rede. Usando NFS, os usuários e programas podem acessar arquivos em sistemas remotos quase como se fossem arquivos locais.

Como funciona
O NFS funciona da seguinte forma: um servidor e um cliente (ou mais clientes). O servidor exporta um determinado diretório ou arquivo para que seus clientes acessem remotamente como de fosse um arquivo local.

Para o perfeito funcionamento são necessários alguns daemons configurados e rodando. Veremos esses daemons mais a frente.

Obs: Essa configuração é baseada no RedHat, podendo conter algumas diferenças para outras ditros.

Pacotes relacionados

nfs-server;

nfs-server-clients;

nfs-utils.

/home/arquivos         cliente (rw)
/home/mp3	       cliente (rw)

Configuração de Serviços DHCP

Todo computador conectado a redes IP precisa, para se comunicar, de uma identificação numérica. Esta identificação é conhecida como endereço IP.
O endereço IP pode ser atribuído de forma estática ou dinâmica.

Endereços IP atribuídos estaticamente possuem algumas desvantagens. Sempre que um equipamento for movido de uma rede para outra o endereço IP tem que ser alterado manualmente, o que pode envolver uma consulta ao administrador de redes. Adicionalmente, cada rede IP possui um gateway distinto, que também precisa ser indicado na configuração do equipamento.

Endereços atribuídos dinamicamente oferecem uma flexibilidade maior. Libertam o usuário de conhecer detalhes sobre a configuração de sua máquina, permitindo-lhes uma maior mobilidade dentro da rede. Tudo o que é necessário é desconectar o equipamento de um ponto e ligá-lo em outro e tudo continuará funcionando normalmente. Usuários de computadores portáteis se beneficiam ainda mais, pois ficam livres de constantemente terem que identificar endereços IP livres nas redes em que irão trabalhar.

A atribuição dinâmica de endereços IP é feita através do protocolo DHCP ou Dynamic Host Configuration Protocol. Seu uso e configuração, tanto do lado do cliente como do servidor, é extremamente simples.

Faremos a seguir uma exposição dos passos necessários para configurar um servidor e um cliente DHCP. Tomaremos como base, para a configuração do servidor, sistemas GNU/Linux. Como clientes abordaremos a configuração de sistemas GNU/Linux.

Nesta exposição tomaremos como base sistemas GNU/Linux baseados na distribuição Red Hat. São dois os pacotes que implementam o serviço DHCP: dhcp e dhcpcd. O primeiro deles, dhcp, é o código do servidor e o segundo, dhcpcd (DHCP Client Daemon) implementa o código cliente.

O primeiro passo é realizar a instalação do pacote dhcp:

# rpm -ivvH dhcp-2.0-5.i386.rpm (Red Hat)
# apt-get install dhcp-server (Debian)

O comando rpm implementa tarefas relacionadas com gerenciamento de software: instalação, verificação, remoção e consultas. No exemplo acima o pacote dhcp foi instalado. O próximo passo é a criação do arquivo de configuração, /etc/dhcpd.conf. Este arquivo conterá diretivas que irão regular o funcionamento do servidor dhcp.

Passemos então à análise de um arquivo de configuraçao típico.

default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 255.255.255.255;
option routers 192.168.1.1;
option domain-name-servers 143.106.80.11, 143.106.1.5;
option domain-name “ccuec.unicamp.br”;
authoritative;

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
range 192.168.1.150 192.168.1.200;
}

Analisemos cada uma das opções:

default-lease-time 600;
Servidores DHCP cedem endereços sob pedido por um tempo pré-determinado.O padrão neste exemplo é ceder o endereço IP por 600 segundos, ou 10 minutos.

max-lease-time 7200;
Caso o cliente solicite um tempo maior, o tempo máximo permitido será de 7200 segundos (2 horas)

option subnet-mask 255.255.255.0;
Esta opção define a máscara de subrede a ser fornecida aos clientes

option broadcast-address 255.255.255.255;
Esta opção define o endereço de envio para requisições de broadcast

option routers 192.168.1.1;
O cliente, além do número IP, recebe também a informação do número do equipamento que é o gateway de sua rede.

option domain-name-servers 143.106.80.11, 143.106.1.5;
Esta opção lista os servidores de nomes (DNS) a serem utilizados para resolução de nomes.

option domain-name “ccuec.unicamp.br”;
Esta máquina pertence ao domínio ccuec.unicamp.br

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
range 192.168.1.150 192.168.1.200;
}
Esta opção lista a subrede à qual o equipamento pertence e a máscara de rede utilizada. A seguir encontra-se a faixa de endereços IP que pode ser fornecida pelo servidor DHCP aos seus clientes. A primeira linha indica que podem ser fornecidos endereços na faixa de 192.168.1.10 a 192.168.1.100 e a segunda linha especifica os endereços entre 192.168.1.150 e 192.168.1.200

Uma vez criado o arquivo /etc/dhcpd.conf, conforme as características da rede em questão, resta configurar a ativação automática do daemon dhcpd. Isto pode ser feito através do utilitário ntsysv, ou através da edição direta dos links em /etc/rc.d.

Para teste do ambiente, ativar o daemon dhcpd:

# cd /etc/rc.d/init.d
# ./dhcpd start

As mensagens de registro de atividades do servidor DHCP são registradas no arquivo /var/log/messages:

Exemplos: IP Fixo

# Máquina (melhor, placa de rede) com IP fixo
host host1 {
hardware ethernet 00:80:C8:35:5D:12;
fixed-address 192.168.0.1;
}
# Outro IP fixo
host host2 {
hardware ethernet 00:10:60:88:3D:BE;
fixed-address 192.168.0.4;
}
}