eu acho mais vantajoso usar o iptables para bloquear que o tcpwrappers. o tcpwrappers precisa ser suportado pela aplicação (como comentado pelo kenjiro, e tb neste site http://www.dicas-l.com.br/cursos/seguranca/seguranca-150.html)
no red hat, da pra checar se a aplicação tem suporte ao tcpwrappers fazendo ldd aplicativo (se fizer mensao a libwrap) quer dizer que possui. http://docs.redhat.com/docs/pt-BR/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-tcpwrappers.html redhat root@canis ~]# ldd /usr/sbin/sshd libwrap.so.0 => /lib64/libwrap.so.0 (0x00002affa09f3000) libpam.so.0 => /lib64/libpam.so.0 (0x00002affa0bfc000) libdl.so.2 => /lib64/libdl.so.2 (0x00002affa0e07000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002affa100c000) libaudit.so.0 => /lib64/libaudit.so.0 (0x00002affa1224000) libfipscheck.so.1 => /usr/lib64/libfipscheck.so.1 (0x00002affa143c000) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002affa163f000) libutil.so.1 => /lib64/libutil.so.1 (0x00002affa1990000) libz.so.1 => /usr/lib64/libz.so.1 (0x00002affa1b93000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00002affa1da8000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002affa1fc0000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002affa21f8000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002affa240e000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002affa263c000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002affa28d1000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002affa2af7000) libnss3.so => /usr/lib64/libnss3.so (0x00002affa2cf9000) libc.so.6 => /lib64/libc.so.6 (0x00002affa3024000) /lib64/ld-linux-x86-64.so.2 (0x00002affa07d6000) libsepol.so.1 => /lib64/libsepol.so.1 (0x00002affa337c000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002affa35c2000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002affa37cb000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x00002affa39cd000) libplc4.so => /usr/lib64/libplc4.so (0x00002affa3bea000) libplds4.so => /usr/lib64/libplds4.so (0x00002affa3def000) libnspr4.so => /usr/lib64/libnspr4.so (0x00002affa3ff2000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002affa422c000) nao consegui identificar a mesma coisa no slack (pode estar intrinseco em outra lib) talvez alguem mais experiente possa dar a dica root@u134358:/home/alissonc# ldd /usr/sbin/sshd linux-vdso.so.1 => (0x00007fff266f3000) libcrypto.so.0 => /lib64/libcrypto.so.0 (0x00007f251de00000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f251dbfc000) libutil.so.1 => /lib64/libutil.so.1 (0x00007f251d9f9000) libz.so.1 => /usr/lib64/libz.so.1 (0x00007f251d7e3000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f251d5c9000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f251d390000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f251d175000) libc.so.6 => /lib64/libc.so.6 (0x00007f251cdcf000) /lib64/ld-linux-x86-64.so.2 (0x00007f251e189000) Mas tudo bem, eu fiz o teste aqui, adicionei no hosts.deny ALL:ALL e depois disso nada de SSH para a minha maquina, nem local, nem externo root@u134358:/home/alissonc# ssh localhost ssh_exchange_identification: Connection closed by remote host Em seguida, apenas adicionei ao /etc/hosts.allow SSHD:127.0.0.1 e acessei novamente o SSH, localmente.. nao precisei reiniciar nenhum serviço alissonc@u134358:~$ ssh localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. ECDSA key fingerprint is 71:bf:a2:59:75:e7:50:01:27:44:29:e9:b2:34:34:5a. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. alissonc@localhost's password: Apenas mais uma consideraçao tcpwrapper: vc recebe o pacote do emissor, avalia o serviço e depois o bloqueia - avisa o destinatário que o acesso foi bloqueado iptables : o kernel já verifica se existe alguma regra bloqueando o pacote (IP, porta) e pode droppa-lo no mesmo momento (nao entrando no 'sistema') eu considero uma técnica bem mais interessante - se vc usa o drop. ele nem avisa nada, simplesmente nao responde. ;) PS: as referencias ao redhat sao mais para comparar algumas diferenças mesmo, nao pra dizer q um é melhor q outro.. att Alisson Ceolin _ °v° /(S)\ SLACKWARE ^ ^ Linux _____________________ ________________________________ De: Paulino Kenji Sato <[email protected]> Para: [email protected] Enviadas: Sexta-feira, 27 de Maio de 2011 16:41 Assunto: Re: [slack-users] Criando acesso aos serviços somente os ip's autorizados ! 2011/5/27 Bruno Mendes <[email protected]>: > Queria confirmar e perguntar sobre como proceder para que somente os ip's > autorizados possam ter acesso a minha maquina ... Qual o protocolo que quer limitar o acesso? > > Penso eu que é pelos arquivos hosts.allow e hosts.deny ... Isso ira funcionar para os programas servidores (daemons) que usan o tcpwrapper. Como o inetd, ssh, alguns ftpd, etc. > agora o que devo colocar para que todos seja bloquaedos menos aqueles que > constam no hosts.allow ??? no hosts.deny para bloquear tudo ALL: ALL para bloquer somente o sshd sshd: ALL e no hosts.allow, depende do que colocou no .deny. liberando o sshd sshd: 192.168.0. 10.0.0.0/8 172.16.0.0/255.255.0.0 Se não me engano, o .deny tem preferência. -- Paulino Kenji Sato -- GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br Antes de perguntar: http://www.istf.com.br/perguntas/ Para sair da lista envie um e-mail para: [email protected] -- GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br Antes de perguntar: http://www.istf.com.br/perguntas/ Para sair da lista envie um e-mail para: [email protected]
