Eish…. Q fdp de blog

August 28, 2011

E o google continua…..

Filed under: Ah coisital não quero fotografias sff,Pensamentos — admin @ 7:32 pm

Olá a todos,

Lembram-se deste artigo?

E eis que a coisa melhora… agora até lançam aplicações para identity managment… e até se dão ao trabalho de esconder a coisa por debaixo de um veu de rede social:

Ribombem os tambores… eis o google+ em todo o seu esplendor….

Artigo on google+

E claro… estão sempre a vontade de deixar de utilizar a coisa… como é óbvio irão ter penalizações….

 

Fica apenas agora o ultimo pensamento sobre esta questão directamente da boca do cavalo:

[Google CEO Eric Schmidt] replied by saying that G+ was build primarily as an identity service, so fundamentally, it depends on people using their real names if they’re going to build future products that leverage that information.

Reparem…. You are the product, not the consumer.

Abraço,

Xupetas

 

 

 

August 8, 2011

Disaster Recovery – Home Edition

Filed under: How-To's — admin @ 1:19 pm

Bom dia a Todos,

Ainda a algum tempo atrás li numa publicidade de loja uma frase que publicitava um NAS: Os seus dados são importantes. São os seus documentos, as suas fotografias, a sua vida.

Nesse momento, pensei para comigo… como conseguiria explicar a minha mulher, que as fotos do meu filho de 3 anos se tinham perdido? Como explicava que as fotos da lua de mel se tinham derretido no canto de uma drive avariada?

Sim… porque mesmo gravando em DVD, o tempo de replica é limitado (+- 700 dias por media), alem que os DVDS riscam-se, apanham calor e empenam de vez… etc….

A somar a isso, e com os assaltos a residências como garantir que as minhas fotos e os meus dados se escapam?

Após muito pensar, um cafe, e uma ida ao WC fez-se luz…. Disaster Recovery for the Poor!

Em primeiro lugar, escolhi um repositório de download link’s, neste caso o filesonic com uma capacidade de armazenamento de 5GB por file, sem limite de transferência por payed user, e muito importante, sem limite de repositório de upload.

No meu caso, como já tenho uma infra-estrutura de bacula utilizei o mesmo para a gestão do disaster recovery. Quem não tiver bacula, ou afins utilize um rar com forte encriptação.

Para quem tiver bacula, recomendo a leitura do seguinte link de forma a garantirem segurança dos vossos dados de uma forma encriptada.

Criem pool’s e jobs para os vossos dados encriptados, com retenção de pelo menos 700 dias (+- 2anos) e no fim de cada Job com dados que irão enviar para o vosso site remoto exportem o vosso catalogo.

Recomendo igualmente, e dependendo da vossa banda de upload que criem vTapes no bacula com apenas 200 MB no máximo. A mesma coisa se aplica a ficheiros rar.

Mais tarde e caso o pior aconteça vão agradecer terem feito este pequeno esforço. O bscan não funciona tao bem como isso quando teem muitos ficheiros por volume como é por exemplo o caso de diretórios com fotografia.

Em seguida, e como uso linux, preferi utilizar um upload manager que suportasse o filesonic, fosse opensourced, corresse de consola em screen e achei o Plowshare. No fim deste post deixarei um script de upload que valida se o upload correu bem ou não.

Assim, após fazerem os vossos backups enviem as vossas vTapes para a Cloud, juntamente com um rar que contenha a vossa chave de encriptação, backup ao SQL do catalogo e ficheiros de config de um bacula. É muito importante que não se esqueçam deste passo.

Finalmente, efetuem um teste de restore. Apaguem as vossas vTapes, descarreguem do site, reponham o catalogo e exprimentem.

Caso tenham alguma duvida, ou quiserem ajuda com isto, enviem-me e-mail para nuno em filhodaputa.net

Abraço,

Xupetas

Recursos:

Script para fazer upload’s:

http://geek.filhodaputa.net/conteudos/offsite_backup_via_ploware.sh.txt

http://geek.filhodaputa.net/conteudos/jailed_offsite_backup_via_ploware_v2.sh.txt

Script para fazer validações com o Nagios:

http://geek.filhodaputa.net/conteudos/crontab_check.sh.txt

http://geek.filhodaputa.net/conteudos/nagios_upload_check.sh.txt

 

Agradecimentos:

Não podia deixar de agradecer ao Itchy Trigger Finger Nigger que me emprestou a conta dele no filesonic para testes. Obrigado!

PS1: Fiz hoje testes de restore dos ficheiros deixados no filesonic e encontrei dois que embora tivessem o tamanho correcto o MD5sum estava com problemas.

Tentei um restore e correu MESMO MAL. Da vTape com problemas para a frente, o bacula deixou de conseguir recuperar dados.

Apaguei as vTapes com problemas do filesonic, re-efectuei o upload da mesmas e já tudo funcionou bem, por isso não se esqueçam de testar as tapes que enviaram, testem com md5sum, testem com um restore para outro diretório mas para o vosso próprio bem TESTEM!

 

Abr,

Xupetas

 

 

June 22, 2011

Backups de Routers Thomson / MEO / Vodafone TV

Filed under: Hardware How-To — admin @ 1:51 pm

Viva Amigos,

Tenho estado muito ausente por motivos profissionais.

No entanto na semana passada, passou-se algo que me fez agora vir aqui escrever umas linhas para ajudar a malta.

Quantos de vocês já teve de mudar um router da vodafone/meo e teve de andar a repor configurações de NAT com aquela interface web bomboca?

Pois bem… aqui vai um mini howto de como gerar regras de instalação:

a) No router e por interface de consola (telnet/ssh)  ANTES de ser substituído ( e se ainda conseguirem entrar nele) façam os seguintes comandos:

ip rtlist

nat maplist

Guardem os outputs.

O primeiro comando dá-vos a tabela de routeamento do router. Podem ser malucos e terem várias redes publicadas na vossa home Lan.

O segundo comando dá-vos a tabela de NAT / PAT que tem implementada no vosso equipamento.

Em ambos os comandos, só vos interessa as vossas configurações. Não as do operador.

Exemplo:

{Administrator}=>ip rtlist
Label             Destination          Gateway  Interface     Mtc Admin  Oper
10.49.16.12/32       127.0.0.1  loop          0   UP     [UP]
10.49.127.255/32       127.0.0.1  loop          0   UP     [UP]
77.54.116.22/32       127.0.0.1  loop          0   UP     [UP]
77.54.127.255/32       127.0.0.1  loop          0   UP     [UP]
127.0.0.1/32       127.0.0.1  loop          0   UP     [UP]
192.168.1.254/32       127.0.0.1  loop          0   UP     [UP]
192.168.1.255/32       127.0.0.1  loop          0   UP     [UP]
255.255.255.255/32       127.0.0.1  loop          0   UP     [UP]
87.103.113.139/32      77.54.96.1* ipInternet    0   UP     UP
87.103.113.203/32      77.54.96.1* ipInternet    0   UP     UP
87.103.119.196/32                  ipVideo       1   UP     UP
213.30.36.212/32                  ipVideo       1   UP     UP
213.30.43.16/32       10.49.0.1  ipVideo       1   UP     UP
95.136.4.112/29       10.49.0.1  ipVideo       1   UP     UP
213.30.36.208/29       10.49.0.1  ipVideo       1   UP     UP
212.18.177.96/27       10.49.0.1  ipVideo       1   UP     UP
93.108.253.128/25       10.49.0.1  ipVideo       1   UP     UP
10.10.0.0/24     192.168.1.1  LocalNetwork  0   UP     [UP]
10.10.1.0/24     192.168.1.1  LocalNetwork  0   UP     [UP]
10.10.2.0/24     192.168.1.1  LocalNetwork  0   UP     [UP]
10.10.3.0/24     192.168.1.1  LocalNetwork  0   UP     [UP]
10.10.50.0/24     192.168.1.1  LocalNetwork  0   UP     [UP]
192.168.1.0/24   192.168.1.254  LocalNetwork  0   UP     [UP]
10.20.100.0/24       10.49.0.1  ipVideo       1   UP     UP
10.20.110.0/24       10.49.0.1  ipVideo       1   UP     UP
10.20.120.0/24       10.49.0.1  ipVideo       1   UP     UP
10.20.150.0/24       10.49.0.1  ipVideo       1   UP     UP
95.136.4.0/23       10.49.0.1  ipVideo       1   UP     UP
87.103.116.0/22       10.49.0.1  ipVideo       1   UP     UP
77.54.96.0/19   77.54.116.122  ipInternet    0   UP     UP
10.49.0.0/17     10.49.16.12  ipVideo       0   UP     UP
0.0.0.0/0       77.54.96.1  ipInternet    1   UP     UP
{Administrator}=>nat maplist
Idx Type Interface       Outside Address                Inside Address                 Use
1 NAT  ipInternet      77.54.116.22:8                127.0.0.1:8                    0
2 NAT  ipInternet      77.54.116.22                  127.0.0.1                      0
3 NAPT ipInternet      77.54.116.22:22               10.10.0.153:22                1
4 NAPT ipInternet      77.54.116.22:25               10.10.0.147:25                2
5 NAPT ipInternet      77.54.116.22:53               10.10.0.149:53                0
6 NAPT ipInternet      77.54.116.22:80               10.10.0.148:80                7
7 NAPT ipInternet      77.54.116.22:119              192.168.1.100:22               0
8 NAPT ipInternet      77.54.116.22:120              192.168.1.101:22               0
9 NAPT ipInternet      77.54.116.22:443              10.10.0.148:443               1
10 NAPT ipInternet      77.54.116.22:514              10.10.0.52:514                2
11 NAPT ipInternet      77.54.116.22:993              10.10.0.147:993               1
12 NAPT ipInternet      77.54.116.22:5060             77.54.116.22:5060             0
13 NAPT ipInternet      77.54.116.22:[7000-7003]      10.10.3.5:[7000-7003]         18
14 NAPT ipInternet      77.54.116.22:9103             10.10.0.4:9103                1
15 NAPT ipInternet      77.54.116.22:[10003-10010]    10.10.3.5:[10003-10010]       1
16 NAPT ipInternet      77.54.116.22:12005            10.10.2.5:12005               1
17 NAPT ipInternet      77.54.116.22:23595            10.10.3.251:23595             1
18 NAPT ipInternet      77.54.116.22:51005            127.0.0.1:51005                0
19 NAPT ipInternet      77.54.116.22:53               10.10.0.149:53                0
20 NAPT ipInternet      77.54.116.22:68               77.54.116.22:68               0
21 NAPT ipInternet      77.54.116.22:5060             77.54.116.22:5060             0
22 NAPT ipInternet      77.54.116.22:[7000-7003]      10.10.3.5:[7000-7003]         136
23 NAPT ipInternet      77.54.116.22:[10003-10010]    10.10.3.5:[10003-10010]       469
24 NAPT ipInternet      77.54.116.22                  unmapped                       73
1 NAT  ipVideo         10.49.16.12:8                  127.0.0.1:8                    0
2 NAT  ipVideo         10.49.16.12                    127.0.0.1                      0
3 NAPT ipVideo         10.49.16.12:22                 10.10.0.153:22                0
4 NAPT ipVideo         10.49.16.12:25                 10.10.0.147:25                0
5 NAPT ipVideo         10.49.16.12:53                 10.10.0.149:53                0
6 NAPT ipVideo         10.49.16.12:80                 10.10.0.148:80                0
7 NAPT ipVideo         10.49.16.12:119                192.168.1.100:22               0
8 NAPT ipVideo         10.49.16.12:120                192.168.1.101:22               0
9 NAPT ipVideo         10.49.16.12:443                10.10.0.148:443               0
10 NAPT ipVideo         10.49.16.12:514                10.10.0.52:514                0
11 NAPT ipVideo         10.49.16.12:993                10.10.0.147:993               0
12 NAPT ipVideo         10.49.16.12:5060               10.49.16.12:5060               0
13 NAPT ipVideo         10.49.16.12:[7000-7003]        10.10.3.5:[7000-7003]         0
14 NAPT ipVideo         10.49.16.12:9103               10.10.0.4:9103                0
15 NAPT ipVideo         10.49.16.12:[10003-10010]      10.10.3.5:[10003-10010]       0
16 NAPT ipVideo         10.49.16.12:12005              10.10.2.5:12005               0
17 NAPT ipVideo         10.49.16.12:23595              10.10.3.251:23595             0
18 NAPT ipVideo         10.49.16.12:51005              127.0.0.1:51005                0
19 NAPT ipVideo         10.49.16.12:53                 10.10.0.149:53                0
20 NAPT ipVideo         10.49.16.12:68                 10.49.16.12:68                 0
21 NAPT ipVideo         10.49.16.12:5060               10.49.16.12:5060               0
22 NAPT ipVideo         10.49.16.12:[7000-7003]        10.10.3.5:[7000-7003]         0
23 NAPT ipVideo         10.49.16.12:[10003-10010]      10.10.3.5:[10003-10010]       0
24 NAPT ipVideo         10.49.16.12                    unmapped                       3

Só nos interessa no primeiro campo o que está atribuído a LocalNetwork, e no segundo comando o que está com o endereçamento publico/porto que nos interessa replicar.

Ou seja:

10.10.0.0/24     192.168.1.1  LocalNetwork  0   UP     [UP]
10.10.1.0/24     192.168.1.1  LocalNetwork  0   UP     [UP]
10.10.2.0/24     192.168.1.1  LocalNetwork  0   UP     [UP]
10.10.3.0/24     192.168.1.1  LocalNetwork  0   UP     [UP]
10.10.50.0/24     192.168.1.1  LocalNetwork  0   UP     [UP]
192.168.1.0/24   192.168.1.254  LocalNetwork  0   UP     [UP]

e

1 NAT  ipInternet      77.54.116.22:8                127.0.0.1:8                    0
2 NAT  ipInternet      77.54.116.22                  127.0.0.1                      0
3 NAPT ipInternet      77.54.116.22:22               10.10.0.153:22                1
4 NAPT ipInternet      77.54.116.22:25               10.10.0.147:25                2
5 NAPT ipInternet      77.54.116.22:53               10.10.0.149:53                0
6 NAPT ipInternet      77.54.116.22:80               10.10.0.148:80                0
7 NAPT ipInternet      77.54.116.22:443              10.10.0.148:443               1
8 NAPT ipInternet      77.54.116.22:5060             77.54.116.22:5060             0

No primeiro output temos as rotas publicadas que este router dá internet, e no segundo as portas que estão mapeadas:

SSH, DNS, SMTP, HTTP, HTTPS, SIP

Assim sendo, temos que configurar da seguinte forma:
B) Mal o novo router esteja instalado, coloquem os seguintes comandos (entre parentisis estão os comentários e explicação dos comandos):

:ip rtadd dst=10.10.0.0/24 gateway=192.168.1.1
:ip rtadd dst=10.10.1.0/24 gateway=192.168.1.1
:ip rtadd dst=10.10.2.0/24 gateway=192.168.1.1
:ip rtadd dst=10.10.3.0/24 gateway=192.168.1.1
:ip rtadd dst=10.10.50.0/24 gateway=192.168.1.1

(adição de rotas no formato – rede/mascara gateway=ip_da_firewall_que_da_servico_a_rede)

:connection timerconfig timer=udpidle value=20
:connection timerconfig timer=udpkill value=15
:hostmgr config state=disabled

(desativar o autodiscovery de rede para poupar CPU do router, diminuir o timeout de udp para múltiplas ligações – ver outros posts do blog)

:hostmgr saveall
:hostmgr clear
:saveall

(gravar configurações)

:service host add name=SSH mode=custom
:service host add name=smtpcluster mode=custom
:service host add name=wwwcluster mode=custom
:service host add name=wwwscluster mode=custom
:service host add name=dnscluster mode=custom

(criar novos servicos com os nomes que se deseja)

:service host rule add name=SSH protocol=tcp baseport=22 portrange=22
:service host rule add name=smtpcluster protocol=tcp baseport=25 portrange=25
:service host rule add name=wwwcluster protocol=tcp baseport=80 portrange=80
:service host rule add name=wwwscluster protocol=tcp baseport=443 portrange=443
:service host rule add name=dnscluster portrange=53

(atribuir portas tcp/udp/IP aos serviços)

:service host assign name=SSH host=10.10.0.153
:service host assign name=smtpcluster host=10.10.0.147
:service host assign name=wwwcluster host=10.10.0.148
:service host assign name=wwwscluster host=10.10.0.148
:service host assign name=dnscluster host=10.10.0.149

(atribuir os serviços aos hosts)

:saveall

(gravar configurações)

 
Após isto, se forem ao vosso router por web, vao la ver as vossas configurações de nat todas como estavam no antigo router.

Pode não parecer muito, mas imaginem que tem 30 ou 40 regras simultaneas, e vão ver o tempo que este truque vos irá poupar.

Se tiverem duvidas ou ideias enviem-me e-mail para xupetas <at> filhodaputa.net. Como sempre não sou responsável se meterem os pés pelas mãos, ou se o operador se lembrar de inventar alguma coisa para impedir este tipo de consolas.

Normalmente em caso de borrada apenas tem que fazer hardreset ao router a coisa volta a estaca 0.

 
Abraço,

Xupetas!!

 

 

June 30, 2010

HSHR – Firewall Transparente – Cluster Edition

Filed under: Hardware How-To,How-To's — admin @ 10:10 am

Olá amigos,

A muito tempo que não tenho tido oportunidade de fazer um post por aqui, nem de desenvolver coisas novas, mas hoje isso vai mudar.

Como já sabem sou fervoroso adepto da virtualização, tendo toda a minha infraestrutura de laboratório em dois servidores.

Um destes elementos em ambos os sistemas é um cluster activo-activo de firewalling, que é a continuação do projecto de firewall transparente.

O esquema é algo como isto:

Ambos os sistemas estão permanente activos, distribuindo a carga entre eles, e assegurando que em caso de falha de um dos nós físicos (ou virtuais) o nó sobrevivente terá a capacidade de garantir conectividades futuras e existentes, sem ser necessário um reconnect (por exemplo para sessão de ssh).

Para tal o material que foi necessário, alem dos virtualizadores claro,  foram duas instâncias de servidores virtuais linux (cada um com 4 interfaces ethernet).

Como sempre utilizei OpenSUSE 11.1, compilado através do OpenSUSE factory (JeOS).

Os componentes em avulso foram:

  • Fwbuilder 4.0 para gerar regras de Firewall (http://www.fwbuilder.org/)
  • Conntrackd para garantir que as ligações de firewall estabelecidas são replicadas em ambos os nós da firewall (http://conntrack-tools.netfilter.org/)
  • VRRP – Implementação de Virtual Router Redundant Protocol  (http://off.net/~jme/vrrpd/)

Na pratica, a FWbuilder apenas constrói as regras de forma a suportar os acesos, e em seguida replica para ambos os nós.

Será sempre necessário que seja atribuído endereçamento para cada das interfaces de ambos os nós (a excepção de interfaces ethernet que sejam elementos de bridge’s). P.exp:

br0       Link encap:Ethernet  HWaddr 00:0C:29:3C:E0:78
inet addr:172.16.0.240  Bcast:172.16.0.255  Mask:255.255.255.0

eth2      Link encap:Ethernet  HWaddr 00:00:5E:00:01:01
inet addr:172.16.1.245  Bcast:172.16.1.255  Mask:255.255.255.0

e

br0       Link encap:Ethernet  HWaddr 00:0C:29:3C:E0:79
inet addr:172.16.0.241  Bcast:172.16.0.255  Mask:255.255.255.0

eth2      Link encap:Ethernet  HWaddr 00:00:5E:00:01:02
inet addr:172.16.1.246  Bcast:172.16.1.255  Mask:255.255.255.0

E  ainda terão de reservar um terceiro IP que será o vosso endereço VIP (Virtual IP que receberá o pedido, e que sendo independente dos sistemas é gerido pelo VRRP ao nível de userspace do sistema).

Assim sendo, e após construírem as regras que as vossas necessidades exigem, será necessário activarem os elementos necessários para as gateways virtuais.
Estes endereços são activados pelos VRRP’s:

Por exemplo:

/apps/webapp/vrrpd/vrrpd/vrrpd -i br0 -v 1 172.16.0.254 -n
/apps/webapp/vrrpd/vrrpd/vrrpd -i eth2 -v 1 172.16.1.254

Pf notem que no caso das interfaces em bridge (br’s),  como o sistema de bridge já efectua a gestão de mac address, tem que se indicar ao vrrpd que não é ele a efectuar o controlo dos mac’s através da flag -n. Sem esta flag a interface bridged irá entrar em loop e falhar.

No caso de interfaces normais, a gestão pode ser efectuada pelo vrrpd (no caso deste exemplo a eth3).

Finalmente, é necessário que ambos os sistemas saibam que ligações estão a ser asseguradas naquele momento. Isto é efectuado através do conntrackd de uma forma totalmente transparente.

Lembrem-se que será necessário configurarem tanto o conntrackd como o vrrpd para comunicarem entre si, e que esta configuração terá de ser replicada ao nível das vossas regras de firewall (não queremos um deny ip any any se ainda não temos comunicação entre o vrrpd e/ou conntrackd).

Links úteis:

Cluster de Firewall com Heartbeat: http://www.fwbuilder.org/4.0/docs/users_guide/heartbeat_cluster.html
Cluster de Firewall para BSD’s e outros: http://www.fwbuilder.org/4.0/docs/users_guide/clusters.html
Cookbook para Firewalls com VRRP e outros: http://www.fwbuilder.org/4.0/docs/users_guide/cluster-cookbook.html
Cookbook para Firewalls com VRRP: http://www.fwbuilder.org/4.0/docs/users_guide/vrrpd_cluster.html
Howtoforge Cookbook para FWbuilder 4.0: http://howtoforge.net/new-features-in-firewall-builder-4.0

Já sabem. Se tiverem duvidas enviem-me mail para xupetas at filhodaputa.net

Abr.
Xupetas

February 27, 2010

Que curta que a memória é….

Filed under: Pensamentos — xupetas @ 9:34 am

Olá a todos.

Hoje vou-me desviar um pouco do estilo romântico-dom-quixotesco que costumo exibir e vou falar de politica.

Não que este seja um blog dedicado a outra coisa que não a tecnologia, mas quando li num pasquim diário, que Ramos Horta achava que a China tinha direitos soberanos sobre o Nepal não pude deixar de ficar… boquiaberto…

Não será este o Ramos Horta que andou com choradinhos por Portugal, pela UE e por todo o sitio que lhe desse tempo de antena para reclamar com o que a Indonésia estava a fazer no o seu pais?

Não será este o Ramos Horta que andou a chorar por todo o lado quando houve o massacre de Sta.Cruz?

Qual a diferença entre o seu Pais e o Nepal? Deve ser a cultura milenar espiritual riquíssima do seu pais… ah espera… estamos a falar de Timor não é?

E assim se vê quem são as pessoas, e ao que elas se rendem. O Sr. Ramos Horta não era pró-Timor como tanto apregoava… a Indonésia ainda não lhe tinha era pago o suficiente….

Ps: façam barulho.. vão a pagina do GAT e exprimam o vosso vómito sobre as declarações do dito Sr.

Abraços

Xupetas

February 22, 2010

E os chineses estão de volta…

Filed under: Pensamentos — xupetas @ 1:30 pm

Amigos,

Mais uma volta mais uma moedinha. Os chineses estão de volta, desta vez com a botnet Zeus.

Esta noticia foi apresentada em primeira mão pela edição Online do WSJ e onde se observa que é mais do mesmo. Em todo o caso e para não dizerem que levanto a lebre, e que a deixo fugir em seguida aqui vão os ip’s por eles utilizados:
113.105.152.71
122.115.63.17
122.225.117.147
125.46.60.222
218.93.205.19
218.93.205.246
58.218.199.186
58.218.199.239
59.53.91.102
60.12.117.147
61.235.117.71
61.235.117.86
61.4.82.216
193.104.110.88
95.169.186.103
222.122.60.186
217.23.10.19
85.17.144.78
200.106.149.171
200.63.44.192
200.63.46.134
91.206.231.189
124.109.3.135
61.61.20.134
91.206.201.14
91.206.201.222
91.206.201.8
216.104.40.218
69.197.128.203

A empresa que desta vez descobriu isto foi a NetWitness, e demonstram o ataque através do seu site e whitepaper.

Boa sorte e mandem cacetada neles!!!

Xupetas

January 7, 2010

Primeiro Post do Ano! Como integrar I2P com TOR e com Squid

Filed under: How-To's — xupetas @ 9:31 am

Olá amigos,

Bom Ano Novo a todos!!!

Fiz mais um howto, desta vez para ensinar como integrar o Squid para destingir entre domínios de destino, e forçar a saída através de um anonimizador especifico.

HOWTO

A ideia será que um domínio especifico saia pela rede .I2p, outro pela rede TOR e os restante saiam directamente através da cache do squid.

Boa sorte para todos.

Xupetas!!

December 23, 2009

Portal Anonimo…

Filed under: Ah coisital não quero fotografias sff — xupetas @ 3:22 pm

Amigos,

Não podia deixar de vir cá desejar um Feliz e Santo Natal a vocês e as vossas Famílias.

Trago um presente para todos: um howto para que possam montar um portal, de acesso remoto a sistemas e a sites mesmo em redes com acesso restrito (https é necessário).

Desenvolvi o conceito nos últimos tempos por gosto, e pelo que se vislumbra, será uma coisa interessante para todos que estão em redes corporativas ou em redes desmasiado restritas (fccn e amigos).

Sem demoras aqui tem o Portal de Acesso Anonimo.

Lembrem-se que isto é para utilizarem com alguma calma. Se não tem acesso a uma coisa, forcar o mesmo quase de certeza vos vai trazer problemas caso sejam apanhados. Numa firewall com SPI, ou num websense, isto registará como um site https, no entanto se abusarem da coisa irão atrair atenções indesejadas.

Tenham isto em mente antes de se porem a inventar no vosso local de trabalho.

Um abraço de Feliz Natal.

Xupetas

December 9, 2009

E eis que cai a mascara ao Google….

Filed under: Pensamentos — xupetas @ 10:57 am

Viva amigos,

Estes tem sido dias muito elucidativos… basta ver a conferencia da google sobre privacidade na internet:

“In a surprising statement to CNBC, Google CEO Eric Schmidt told reporter Maria Bartiromo, ‘If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.’ This will only fuel concerns about Google’s behavior as it becomes an ever more powerful gatekeeper of information; though Google says it is aware of these concerns and has taken steps to be transparent to users about the information that is stored.”
Depois desta noticia só a dizer… c’a raio?  Não eram vocês que diziam “dont  be evil?”  Não posso ter direito a minha privacidade porque?

Assim de cabeça lembro-me de varias coisas que posso não querer que se tornem domínio publico, ou mesmo do domínio de alguém que eu não tenha sido alvo da minha confiança  por exemplo discussão de uma ideia nova com um amigo via e-mail, criar uma nova técnica de negócio, dizer que não gosto de algum governo.

O problema com esta atitude, é que para alguem existe sempre outrem que faz algo de incorrecto, ou de censurável, seja por opção de vida, seja por opção de religião, seja por opção sexual.

E a somar a isto lembrem-se amigos, que neste momento, o engine de datamining do google está dentro do vosso gmail a indexar, e a verificar. Para os que dizem que isto não está a acontecer, leiam isto que ilustra perfeitamente a realidade.

Assim sendo, cada vez mais faz sentido mecanismos de protecção como o I2P ou o TOR.

Pensem assim: agora alguém está a ler o vosso e-mail, e a aprender a vossa personalidade, a catalogar o que vocês vêem na internet. Qualquer dia, essa informação será utilizada para vos vender algo, vos seduzir a algo, vos obrigar a algo….

Big Breda is watching….

Xupetas

December 1, 2009

Uma face indistinguível no meio da multidão…

Filed under: Ah coisital não quero fotografias sff — xupetas @ 12:37 am

Olá a todos,

Este é o primeiro dos meus posts sobre o anonimato na net. Embora algumas pessoas (e muitos governos) gostariam de vos fazer acreditar, numa era onde quem não tem facebook, hi5, twitter e afins, não é ninguem, existem ainda pessoas que gostam de ter alguma privacidade e anonimato.

Por privacidade não quero afirmar que quem procura privacidade é obrigatoriamente um elemento da sociedade a tentar fazer algo nefasto para a mesma. O proverbial homem de gabardine que atrai as donas de casa para escadas escuras a procura de algo….

Pode simplesmente ser zeloso, paranóico ou agorafóbico.

Em todo o caso, e depois das ultimas noticias que vieram da UE, temos que começar a pensar no futuro. É correcto que não devemos (nem em boa consciência o fazemos) efectuar o roubo do trabalho de outros, seja em formato musical seja em formato .avi.

Da mesma forma que eu, que sou um cidadão perto do exemplar, que pago os meus impostos, que faço as minhas obrigações cívicas, que participo positivamente na minha comunidade não deveria ser olhado com suspeição por empresas que não elegi para nenhum lugar politico e que agem como se fossem a policia politica, como um potencial criminoso, que só por ter internet. Não é por ter banda larga que estou a beira de cometer um crime (!) de efectuar um download pirata.

Para minha sorte, os meus gostos vão para musicas e videos indie, que são efectuados pela comunidade e para a comunidade sem interesse monetário.

Em todo o caso, saber que teria a minha ligação sobre investigação, sem a supervisão de nenhum magistrado, apenas ao doce sabor da ultima quebra nas vendas,  levou-me ao nosso amigo google procurar uma forma de me defender contra tal violação dos meus direitos de cidadão nacional, europeu e mundial.

Assim sendo descobri o projecto I2P feito pelos nossos amigos comedores de Bratwurst e bebedores de cevada liquida.

É um projecto interessante com suporte directo a SMTP, POP3, IRC, MTM, etc, com a possibilidade acrescida de ser um protocolo aberto, com código aberto. Assim sendo podem escrever (se compreenderem aquele java todo) os vossos próprios plugins para as vossas aplicações.

Os pontos fortes desta coisa são (e sim vai mesmo em inglês):

I2P is an anonymizing network, offering a simple layer that identity-sensitive applications can use to securely communicate. All data is wrapped with several layers of encryption, and the network is both distributed and dynamic, with no trusted parties.

Many applications are available that interface with I2P, including mail, peer-peer, IRC chat, and others.

The I2P project was formed in 2003 to support the efforts of those trying to build a more free society by offering them an uncensorable, anonymous, and secure communication system. I2P is a development effort producing a low latency, fully distributed, autonomous, scalable, anonymous, resilient, and secure network. The goal is to operate successfully in hostile environments. even when an organization with substantial financial or political resources attacks it. All aspects of the network are open source and available without cost, as this should both assure the people using it that the software does what it claims, as well as enable others to contribute and improve upon it to defeat aggressive attempts to stifle free speech.

Anonymity is not a boolean – we are not trying to make something “perfectly anonymous”, but instead are working at making attacks more and more expensive to mount. I2P is a low latency mix network, and there are limits to the anonymity offered by such a system, but the applications on top of I2P, such as Syndie, I2P mail, and I2PSnark extend it to offer both additional functionality and protection.

I2P is still a work in progress. It should not be relied upon for “guaranteed” anonymity at this time, due to the relatively small size of the network and the lack of extensive academic review. It is not immune to to attacks from those with unlimited resources, and may never be, due to the inherent limitations of low-latency mix networks.

I2P works by routing traffic through other peers, as shown in the following picture. All traffic is encrypted end-to-end. For more information about how I2P works, see the Introduction.

O diagrama de como isto funciona é baseado no conceito do TOR mas levaram a coisa um passo mais a frente:

Legenda:

In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on their local router. They each have a pair of 2-hop inbound tunnels per destination (labeled 1,2,3,4,5 and 6), and a small subset of each of those router’s outbound tunnel pool is shown with 2-hop outbound tunnels. For simplicity, Charlie’s inbound tunnels and Dave’s outbound tunnels are not shown, nor are the rest of each router’s outbound tunnel pool (typically stocked with 5-10 tunnels at a time). When Alice and Bob talk to each other, Alice sends a message out one of her (pink) outbound tunnels targetting one of Bob’s (green) inbound tunnels (tunnel 3 or 4). She knows to send to those tunnels on the correct router by querying the network database, which is constantly updated as new leases are authorized and old ones expire.

If Bob wants to reply to Alice, he simply goes through the same process – send a message out one of his outbound tunnels targetting one of Alice’s inbound tunnels (tunnel 1 or 2). To make things easier, most messages sent between Alice and Bob are garlic wrapped, bundling the sender’s own current lease information so that the recipient can reply immediately without having to look in the network database for the current data.

To deal with a wide range of attacks, I2P is fully distributed with no centralized resources – and hence there are no directory servers keeping statistics regarding the performance and reliability of routers within the network. As such, each router must keep and maintain profiles of various routers and is responsible for selecting appropriate peers to meet the anonymity, performance, and reliability needs of the users, as described in the peer selection page.

The network itself makes use of a significant number of cryptographic techniques and altorithms – a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode with PKCS#5 padding, 1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman negotiated connections with station to station authentication, and ElGamal / AES+SessionTag.

Content sent over I2P is encrypted through three or four layers – end to end encryption (absolutely no routers get the plaintext, ever), garlic encryption (used to verify the delivery of the message to the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel gateway to the tunnel endpoint), and interrouter transport layer encryption (e.g. the TCP transport uses AES256 with ephemeral keys):

End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release 0.6; end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice’s router “a” to Bob’s router “h” remains. Notice the different use of terms! All data from a to h is end-to-end encrypted, but the I2CP connection between the I2P router and the applications is not end-to-end encrypted! A and h are the routers of alice and bob, while alice and bob in following chart are the applications running atop of I2P.

Inconvinientes desta tecnologia:

Como é um sistema de direct peering, irá ser necessário manterem uma maquina sempre em execução com isto. Se for abaixo, toda a rede, ou pares próximos terão de ser re-descobertos. E uma redescoberta que garanta utilidade no sistema demora umas horitas a dar frutos.

Assim sendo, recomendo que exprimentem isto. Pode não ser o futuro, mas será nesta direcção que as coisas irão progredir.

Lembrem-se Big Brother is Watching….
Xupetas!

Older Posts »

Powered by WordPress