jump to navigation

Assessment Tool by Symantec Calcola il prezzo che potrebbero avere i tuoi dati nel mercato nero Settembre 13, 2009

Posted by installatore in Varie, networking, security.
Tags: , , , , ,
add a comment

In questi giorni la Symantec ha rilasciato un tool on-line per calcolare il valore della tua identità sul mercato nero di internet.E’ molto curioso,la mia vale solo sui 10$ ,effettivamente ci sono rimasto un pò male.Provatelo anche voi….

http://www.everyclickmatters.com/victim/assessment-tool.html

Linux Firewall How to abort (cut) specific connections Settembre 13, 2009

Posted by installatore in linux, networking, script, security.
Tags: , , , , , ,
add a comment

Alcune volte capita gestendo Firewall basati su distribuzioni Linux di dover killare eventuali connessioni superfluee,o non autorizzate o più semplicemente terminare vpn lasciate aperte dagli impiegati piuttosto che terminare connessioni con alti consumi di banda nonchè peer-to-peer.Per fare ciò non possiamo affidarci al solito comando netstat dovremmo imparare a utilizzare altri due comandi disponibili in linux.

Il primo comando disponibile è il comando tcpkill.

La sintassi del comando è:

tcpkill -i eth0 { expression }

Per esempio per poter killare tutte le connessioni in uscita sulla porta 21 (ftp) potremmo usare il comando nella seguente maniera.

tcpkill -i eth0 port 21

Oppure bloccare completamente tutte le connessioni da e per un determinato host.

tcpkill host 192.168.0.123

Altrimenti bloccare tutti i pacchetti tra un determinato host e tutti gli altri pc in rete ad esclusione del nostro.

tcpkill ip host 192.168.0.123 and not 192.168.0.15

Il secondo è cutter.

Per esempio se volessimo terminare tutte le connessioni da un’host al resto del mondo.

cutter 192.168.0.123

Se invece ci interessa terminare solo le connessioni ssh.

cutter 192.168.0.123 22

Se vogliamo essere più specifici e bloccare tutte le connessioni ssh dal 192.168.0.123 al server remoto 123.123.123.123 la sintassi sarà la seguente.

cutter 123.123.123.123 192.168.0.123 22

Direi che questi 2 utilissimi comandi se usati in aggiunta ad iptraf o ad altri programmi di monitoring come ntop permettono anche l’automazione di eventuali operazioni ripetitive come la disconnessione do tutte le vpn alla fine del turno di lavoro.

Passive fingerprinting of a system through firewall log Settembre 8, 2009

Posted by installatore in networking, security.
Tags: , , ,
add a comment

In determinate situazioni,vi potrebbe essere chiesto di raccogliere informazioni su eventuali sistemi ormai non più raggiungibili per svariati motivi (spenti…?oppure più semplicemente poichè non autorizzati dalla direzione piuttosto che da motivi legali…),in questo determinato caso per ottenere informazioni su questo/i sistemi dovremmo avventurarci nel mondo del network forensics.,il quale consiste nel raccogliere informazioni attraverso l’osservazione di  eventuali “tracce”,lasciate dai sistemi sugli apparati di rete aziendali.

Di seguito spiegherò come poter risalire alla marca produttrice della macchina e a riconoscere il sistema operativo installato sulla stessa.

Normalmente le macchine basate su sistema operativo Windows creano di default i pacchetti con un TTL standard di 128,mentre per le macchine con sistema operativo Linux di ultima generazione presentano un TTL standard di 64.

Ne consegue che un pacchetto che arriva con un TTL di 126 è molto più probabilmente attribuile a una macchina Windows a 2 hop (router) di distanza dal nostro firewall piuttosto che un pacchetto generato da una macchina Linux a 126 hop di distanza.Stessa cosa è valida per le macchine Linux,un pacchetto con TTL 60,sarà in linea di massima attribuibile a una macchina Linux a 4 hop di distanza.

Provate a indovinare la marca produttrice e il sistema operativo da questi log estratti da un firewall basato su iptables.

Mar 24 12:13:13 192.168.1.10 kernel: [ 915.256256] FIREWALL:BLOCKEDIN=eth3 OUT= MAC=ff:ff:ff:ff:ff:ff:00:21:70:4d:4f:ae:08:00 SRC=192.168.1.170 DST=192.168.1.255 LEN=96 TOS=0×00 PREC=0×00 TTL=128 ID=61495 PROTO=UDP SPT=137 DPT=137 LEN=76
Mar 24 12:13:14 192.168.1.10 kernel: [ 916.006952] FIREWALL:BLOCKEDIN=eth3 OUT= MAC=ff:ff:ff:ff:ff:ff:00:21:70:4d:4f:ae:08:00 SRC=192.168.1.170 DST=192.168.1.255 LEN=96 TOS=0×00 PREC=0×00 TTL=128 ID=61496 PROTO=UDP SPT=137 DPT=137 LEN=76
Mar 24 12:13:14 192.168.1.10 kernel: [ 916.764653] FIREWALL:BLOCKEDIN=eth3 OUT= MAC=ff:ff:ff:ff:ff:ff:00:21:70:4d:4f:ae:08:00 SRC=192.168.1.170 DST=192.168.1.255 LEN=96 TOS=0×00 PREC=0×00 TTL=128 ID=61497 PROTO=UDP SPT=137 DPT=137 LEN=76

Dal valore del TTL possiamo evincere che sia una macchina Windows nella stessa sotto rete del firewall (0 hop di distanza),mentre dal mac address “00:21:70:4d:4f:ae:08:00″,fondamentalmente dalle prime due coppie di caratteri scopriamo che la marca è Dell.

Backdoor demonstration by Symantec Settembre 7, 2009

Posted by installatore in networking.
Tags: , , ,
add a comment

La cosa mi spaventa al quanto…

Linux Monitor / Healthcheck script Settembre 3, 2009

Posted by installatore in Varie, linux, networking, script, solaris.
Tags: , , , , , ,
add a comment

In questo articolo,descrivo come tramite l’uso dei comandi della shell di linux possiamo crearci uno script da schedulare successivamente con cron,per monitorare lo stato di salute dei nostri server.La funzionalità dello script è molto semplice ,sicuramente può essere migliorato.

Come prima cosa partirei controllando che il/i filesystem del nostro server non siano pieni .

[root@rac2 ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/mapper/VolGroup00-LogVol00

14G   13G  775M  95% /

/dev/sda1              99M   19M   76M  20% /boot

tmpfs                 502M  300M  202M  60% /dev/shm

Controlliamo inoltre gli ultimi login effettuati sulla macchina,come si dice….la prudenza non è mai troppa…
[root@rac2 ~]# last | head -20
root     pts/3        192.168.0.8      Tue Aug 18 09:20   still logged in
oracle   pts/3        :0.0             Tue Aug 18 09:17 – 09:20  (00:02)
oracle   pts/3        :0.0             Tue Aug 18 08:19 – 09:16  (00:56)
oracle   pts/2        :0.0             Tue Aug 18 07:08   still logged in
oracle   :0                            Tue Aug 18 07:08   still logged in
oracle   :0                            Tue Aug 18 07:08 – 07:08  (00:00)
root     pts/1        openfiler1       Tue Aug 18 07:04   still logged in
reboot   system boot  2.6.18-128.4.1.e Tue Aug 18 06:57          (02:25)
root     pts/1        :0.0             Tue Aug 18 06:44 – down   (00:11)
root     pts/2        openfiler1       Tue Aug 18 06:22 – down   (00:32)
root     pts/1        :0.0             Tue Aug 18 06:15 – 06:43  (00:28)
root     :0                            Tue Aug 18 06:14 – down   (00:40)
root     :0                            Tue Aug 18 06:14 – 06:14  (00:00)
reboot   system boot  2.6.18-128.4.1.e Tue Aug 18 06:10          (00:45)
root     pts/1        :0.0             Tue Aug 18 05:49 – down   (00:19)
root     pts/1        :0.0             Tue Aug 18 05:47 – 05:48  (00:00)
root     pts/1        :0.0             Sun Aug 16 16:36 – 05:46 (1+13:10)
root     pts/2        :0.0             Sun Aug 16 16:26 – down  (1+13:41)
root     pts/1        :0.0             Sun Aug 16 16:24 – 16:36  (00:12)
root     :0                            Sun Aug 16 16:23 – down  (1+13:45)
Un’altra cosa da controllare soprattutto sui sistemi esposti su internet,è la grandezza della cartella temporanea e relativi file,molto spesso al suo interno si annidano rootkit o altri malware.Nel mio caso la cartella temporanea era /tmp
[root@rac2 ~]# du -h /tmp
8.0K    /tmp/gconfd-root
4.0K    /tmp/keyring-JuVYH2
4.0K    /tmp/.oracle
16K    /tmp
Controlliamo anche lo stato dell’hardware della scheda madre andando a fare un grep su tutte le voci che contegono state o status.
[root@rac2 ~]# dmidecode |grep -B 2 Stat
Serial Number: …..
Asset Tag:
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
–
Max Speed: 5200 MHz
Current Speed: 2400 MHz
Status: Populated, Enabled
–
On Board Device Information
Type: Ethernet
Status: Enabled
–
On Board Device Information
Type: Sound
Status: Enabled
–
On Board Device Information
Type: Other
Status: Enabled
–
Access Method: Memory-mapped physical 32-bit address
Access Address: 0xFFF81000
Status: Valid, Not Full
–
Handle 0×1800, DMI type 24, 5 bytes.
Hardware Security
Power-On Password Status: Enabled
Keyboard Password Status: Not Implemented
Administrator Password Status: Enabled
Front Panel Reset Status: Not Implemented
–
Cooling Device
Type: Fan
Status: OK
–
Cooling Device
Type: Fan
Status: OK
–
Cooling Device
Type: Fan
Status: OK
–
Handle 0×2000, DMI type 32, 11 bytes.
System Boot Information
Status: No errors detected
A questo punto diamo un’occhiata allo stato dei pacchetti droppati e agli errori di trasmissione e ricezione sulle interfacce di rete.In linea di massima questi valori non dovrebbero crescere in maniera esorbitante nell’arco della giornata.
[root@rac2 ~]# ifconfig
eth4      Link encap:Ethernet  HWaddr 00:0C:29:2D:6F:3E
inet addr:192.168.0.102  Bcast:192.168.0.255  Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe2d:6f3e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:2814028 errors:0 dropped:0 overruns:0 frame:0
TX packets:383162 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2263618394 (2.1 GiB)  TX bytes: 372588412946 (347 GiB)
Base address:0×2000 Memory:d8940000-d8960000
Oltre al comando ifconfig per controllare la parte “fisica” del collegamento in rete possiamo usare ethtool.
[root@rac2 ~]# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Current message level: 0×00000007 (7)
Link detected: yes
Tramite lm_sensors possiamo ottenere i valori di elettricità e di temperatura di alcuni componenti della scheda madre della nostra macchina,quindi se non lo avete già fatto bisogna installare lm_sensors e lanciare il comando sensors-detect e seguire la procedura guidata per la prima configurazione.
[root@rac2]# sensors
lm85b-i2c-0-2e
Adapter: SMBus I801 adapter at c400
V1.5: +1.47 V (min = +1.42 V, max = +1.58 V)
VCore: +1.49 V (min = +1.45 V, max = +1.60 V)
V3.3: +3.33 V (min = +3.13 V, max = +3.47 V)
V5: +5.03 V (min = +4.74 V, max = +5.26 V)
V12: +12.25 V (min = +11.38 V, max = +12.62 V)
CPU_Fan: 2386 RPM (min = 4000 RPM) ALARM
fan2: 0 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 300 RPM (min = 0 RPM)
CPU: +29°C (low = +10°C, high = +50°C)
Board: +29°C (low = +10°C, high = +35°C)
Remote: +28°C (low = +10°C, high = +35°C)
CPU_PWM: 255
Fan2_PWM: 255
Fan3_PWM: 77
vid: +1.525 V (VRM Version 9.0)
Bisogna inoltre controllare eventuali errori hardware ai dischi tramite dmesg,in dmesg trovate anche altri errori relativi alle periferiche,qui di seguito lo utilizzo con un grep per i dischi,ovviamente potete personalizzare il grep a vostra discrezione.
[root@rac2 ~]# dmesg | grep sda
SCSI device sda: 33554432 512-byte hdwr sectors (17180 MB)
sda: Write Protect is off
sda: Mode Sense: 5d 00 00 00
sda: cache data unavailable
sda: assuming drive cache: write through
SCSI device sda: 33554432 512-byte hdwr sectors (17180 MB)
sda: Write Protect is off
sda: Mode Sense: 5d 00 00 00
sda: cache data unavailable
sda: assuming drive cache: write through
sda: sda1 sda2
sd 0:0:0:0: Attached scsi disk sda
EXT3 FS on sda1, internal journal
Quindi controlliamo il numero di processi “zombie” e quale tra i processi sta consumando più ram e cpu giusto per vedere che non ci siano problemi (il numero dei processi zombie non deve mai essere troppo alto).
[root@rac2]# top -bn 2 >> /tmp/top.txt
top – 09:52:46 up  130 days,  5 users,  load average: 0.13, 0.21, 0.27
Tasks: 159 total,   3 running, 156 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  1.0%sy,  0.0%ni, 95.0%id,  3.6%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   1027004k total,   936852k used,    90152k free,    20292k buffers
Swap:  2064376k total,    71652k used,  1992724k free,   681484k cached
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1314 root      15   0 12740 1108  804 R  1.0  0.1   0:00.16 top
1274 root      15   0 88948 3328 2588 R  0.3  0.3   0:00.27 sshd
1 root      15   0 10344  508  476 S  0.0  0.0   0:01.22 init
2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0
3 root      34  19     0    0    0 S  0.0  0.0   0:00.05 ksoftirqd/0
4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
5 root      10  -5     0    0    0 S  0.0  0.0   0:05.58 events/0
6 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 khelper
15 root      10  -5     0    0    0 S  0.0  0.0   0:00.01 kthread
19 root      10  -5     0    0    0 S  0.0  0.0   0:08.29 kblockd/0
20 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
205 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 cqueue/0
208 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 khubd
A questo punto spiegati tutti i singoli comandi possiamo crearci uno script da lanciare tutti i giorni tramite cron,in modo tale che ci invii anche una mail con il resoconto di tutti i comandi.
#!/bin/sh
# monitor script linux v1
uname -a > /tmp/mhc.txt
echo “—————————-”>>/tmp/mhc.txt
df -h >> /tmp/mhc.txt
last |head -10 >> /tmp/mhc.txt
echo “—————————-”>>/tmp/mhc.txt
du -h /tmp >> /tmp/mhc.txt
echo “—————————-”>>/tmp/mhc.txt
ethtool eth0 >> /tmp/mhc.txt
echo “—————————-”>>/tmp/mhc.txt
ifconfig eth0 >> /tmp/mhc.txt
echo “—————————-”>>/tmp/mhc.txt
dmidecode |grep -B 2 Stat >> /tmp/mhc.txt
echo “—————————-”>>/tmp/mhc.txt
sensors >> /tmp/mhc.txt
echo “—————————-”>>/tmp/mhc.txt
top -bn 2 >> /tmp/mhc.txt
echo “—————————-”>>/tmp/mhc.txt
smartctl -d ata -iH /dev/sda >> /tmp/mhc.txt
smartctl -d ata -iH /dev/sdb >> /tmp/mhc.txt
echo “—————————-”>>/tmp/mhc.txt
dmesg |grep sda >> /tmp/mhc.txt
dmesg |grep sdb >> /tmp/mhc.txt
echo “—————————-”>>/tmp/mhc.txt
cat /tmp/mhc.txt |mail -s server-health-check your@email.com
[root@rac2 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
14G   13G  775M  95% /
/dev/sda1              99M   19M   76M  20% /boot
tmpfs                 502M  300M  202M  60% /de

Active/Active cluster with Heartbeat + Mon for a Server Application Aprile 26, 2009

Posted by installatore in linux, networking, script.
Tags: , , ,
add a comment

In questo articolo spiegherò brevemente come poter creare un cluster a 2 nodi Active/Active per un applicazione server attraverso anche l’uso di un record DNS Round Robyn,che andrà a smistare il traffico.

Per questa configurazione ho scelto di avere 2 indirizzi Ip virtuali (a cui punterà il round robyn) che potranno effettuare il failover su entrambi i nodi del nostro cluster.Per creare i 2 ip virtuali e lanciare mon, utilizzeremo heartbeat http://www.linux-ha.org/ .

Per gestire le risorse clusterizzate utilizzeremo mon http://mon.wiki.kernel.org/ .Mon avrà il compito di monitorare i nostri 2 nodi e tramite lo script tcp.monitor monitorare la porta che la nostra applicazione terrà aperta in ascolto.

Prima di tutto andiamo a configurare il file /etc/hosts inserendo i nomi host dei nostri server su entrambi i nodi.

10.0.0.2 nodoclu1                                                                                                                                                                                           

10.0.0.3 nodoclu2

Quindi procediamo con l’installazione di heartbeat e di mon,tramite i sorgenti o i packages scaricati dai relativi siti.Ipotizzerò che le cartelle di installazione per i 2 programmi siano /etc/ha.d (per heartbeat) e /etc/mon (per mon).

Cominciamo con il configurare su entrambi i nodi il file /etc/ha.d/ha.cf nel seguente modo:

# Logging 

debug 0

debugfile /var/log/ha-debug

use_logd  false

logfacility  daemon

logfile /var/log/ha-log

 

# Misc Options

traditional_compression off

compression bz2

coredumps true

 

# Communications (scelgo su quali interfacce e su che porta configurare le comunicazioni interne tra i due nodi)

udpport 691

bcast eth0

bcast eth1

 # Thresholds (in seconds)

keepalive 1

warntime 6

initdead 5   #(un nodo viene indicato come failed dopo 5 secondi)

 

deadtime 9 #(un nodo viene indicato come morto dopo 9 secondi)

ping 10.0.0.1      #(per verificare che la rete pubblica sia sù pingo il mio gateway)

node  nodoclu1,nodoclu2    #(i nodi che appartengono al cluster)

auto_failback off               #(gestisco il fail back delle risorse con mon,quindi questo lo lascio a off)

respawn hacluster /usr/lib64/heartbeat/ipfail     #(indica il programma che controlla le interfacce di rete)

In questo file abbiamo quindi specificato i parametri di partenza per heartbeat,non ci resta che andare ad editare anche il file /etc/ha.d/haresources per poter configurare le risorse che vogliamo clusterizzare.

nodoclu1 10.0.0.10 mon_script

nodoclu2 10.0.0.20

Abbiamo quindi specificato che sul nodoclu1 sarà presente l’ip virtuale 10.0.0.10 e la risorsa mon_script ,che sarebbe lo script di avvio di mon,che dovrà essere inserito in /etc/ha.d/resource.d .Mentre per il nodoclu2 girerà solamente un altro ip virtuale.Ovviamente entrambi i nodi possono ospitare tutte le risorse qui descritte (2 ip virtuali + mon).Qui di seguito lo script mon_script….

 

#!/bin/sh

#

# start/stop the mon server

#

# processname: mon

# config: /etc/mon/mon.cf

# pidfile: /var/run/mon.pid

#

PATH=/bin:/usr/bin:/sbin:/usr/sbin

export PATH

# Source function library.

. /etc/rc.d/init.d/functions

# See how we were called.

case “$1″ in

start)

echo -n “Starting mon daemon: “

# daemon /etc/mon/mon -c /etc/mon/mon.cf

/etc/mon/mon -f -c /etc/mon/mon.cf

echo

touch /var/lock/subsys/mon

;;

stop)

echo -n “Stopping mon daemon: “

killproc mon

echo

rm -f /var/lock/subsys/mon

;;

status)

base=”mon”

pid=`pidof -o $$ -o $PPID -o %PPID -x ${base}`

if [ -n "$pid" ]; then

echo “running”

else

echo “stopped”

fi

;;

monitor)

base=”mon”

pid=`pidof -o $$ -o $PPID -o %PPID -x ${base}`

if [ -n "$pid" ]; then

echo “running”

else

echo “stopped”

exit 7

fi

;; restart)

killall -HUP mon

;;

*)

echo “Usage: mon {start|stop|status|restart|monitor}”

exit 1

esac

exit 0

A questo punto possiamo lanciare heartbeat su entrambi i nodi per controllare che vengano caricate tutte le nostre risorse (/etc/init.d/heartbeat start).Quindi possiamo partire configurando il file /etc/mon/mon.cf

 

alertdir = /etc/mon/alert.d

mondir = /etc/mon/mon.d

logdir = /etc/mon

maxprocs = 20

histlength = 100

randstart = 60s

 

hostgroup nodo1 10.0.0.2    

hostgroup nodo2 10.0.0.3

 

watch nodo1

service tcp

interval 5s

monitor tcp.monitor -p 3000 10.0.0.2  #-p portatcp indirizzonodo1

period wd {Mon-Sun}

alert ha_sall.alert  #appena non mi risponde per 2 volte il server lancio /usr/lib64/heartbeat/hb_standby all

upalert ha_tloc.alert #appena torna su il server lancio /usr/lib64/heartbeat/hb_takeover local

alertafter 2

no_comp_alerts

watch nodo2

service tcp

interval 5s

 

monitor tcp.monitor -p 3000 10.0.0.3 #-p portatcp indirizzonodo2

period wd {Mon-Sun}

alert ha_tall.alert # appena non mi risponde per 2 volte il server lancio /usr/lib64/heartbeat/hb_takeover all

upalert ha_sfor.alert #appena torna su lancio /usr/lib64/heartbeat/hb_standby foreign

alertafter 2

no_comp_alerts

I file come ha_sfor.alert sono contenuti sotto /etc/mon/alert.d e non sono altro che file script con il comando scritto affianco.Ovviamente questa è la configurazione del nodo 1 quindi sul nodo 2 dovrò scambiare tutto ciò che riguarda col nodo1 con il nodo2 e viceversa.In pratica monitorizza se la porta 3000 sugli indirizzi ip indicati è aperta se non lo è esegue il file di alert dopo 2 volte che non risponde (alertafter 2),se la porta torna disponibile allora scatta l’upalert.Con questa configurazione la mia applicazione aveva tra l’alert e il failover delle risorse solo 5 secondi :D direi un risultato molto soddisfacente.

BGP…un altro buco nella sicurezza di Internet Settembre 16, 2008

Posted by installatore in networking.
Tags: , , , , , , , ,
add a comment

Al DefCon,due esperti di networking (Alex Pilosovand Anton “Tony” Kapela) hanno dimostrato come sia possibile sfruttare la troppa credibilità ,che il protocollo bgp dà alle informazioni interscambiate tra i router dei vari ISP,  esponendo il fianco a possibili attacchi man-in-the-middle (MiM).

Funzionamento del BGP

Questo protocollo di routing non fà altro che tramite una serie di algoritmi calcolare la “best” path verso una determinata sottorete.Una volta calcolata,questa viene “spreadata” a tutti i router vicini definiti “neighbour”.BGP inoltre riterrà una route come la più favorità quanto più sia vicina alla rete di destinazione.Ecco un esempio….

Network          Next Hop           Metric LocPrf Weight Path  *>  151.1.0.0/16      5.198.4.2             0    100      0  100 ?

 

  *>  151.1.3.0/24     5.198.4.3             0    100      0  100 ?
Qui sopra vediamo riportato l’output di una entry BGP,ritornando al discorso cominciato sopra se per esempio noi dobbiamo raggiungere l’indirizzo 151.1.3.34 la best path sarà la seconda perchè è più “vicina” rispetto alla prima in quanto lnella seconda entry viene annunciata una sottorete più completa rispetto alla prima e quindi più simile all’indirizzo ip che dobbiamo raggiungere.

Dove stà l’inghippo….

Visto che BGP prenderà come vere ogni aggiornamento sulle route e eleggerà come best path quella più vicina all’ip di destinazione….un male intenzionato potrebbe “spreadare” un falso update BGP per dirottare il traffico verso un determinato indirizzo ip verso un altro e verrebbe sempre considerato vero dai router e verrà annunciato a tutti i “neighbour”.

Un evento del genere era già capitato per sbaglio a You Tube quando la Telecom Pakistana ha cominciato a “spreadare” update BGP errati sulla route verso you tube questo ha causato l’irraggiungibilità del sito per diverse ore.Potete leggerne di più qui http://news.bbc.co.uk/1/hi/technology/7262071.stm

Purtroppo la facilità con cui si può creare un router BGP e quindi poter spargere falsi update è molto semplice come è dimostrato dall’articolo qui sotto dove viene creato utilizzando un semplice Mac Mini. http://www.fubra.com/blog/2007/10/mac-mini-bgp-routers-part-2.html

Riporto qui di seguito il file di presentazione power point utilizzato dai due esperti per il DefCon.

http://installatore.files.wordpress.com/2008/09/edited-iphd-2.ppt

Ovviamente per ovviare a questa mancanza nel protocollo ,che è il più usato per il collegamento tra i vari ISP,si è studiato una soluzione chiamata S-BGP (Secure BGP) che consiste in tutta una serie di collegamenti cifrati tramite IPsec e certificati per rendere sicuro l’interscambio di informazioni tra i vari Enterprise router.Questo sicuramente eliminerebbe il problema ,ma comporterebbe un notevole esborso in termini di denaro per sostituire tutti i router ormai obsoleti che a causa della limitata potenza di calcolo oltrechè alla memoria ristretta nonchè all’altissimo numero di collegamenti che reggono,che non reggerebbero di certo il nuovo protocollo.

Come conclusione citando Douglas Maughan( cybersecurity research program manager for the DHS’s Science and Technology Directorate)

The only thing that can force them (to fix BGP) is if their customers … start to demand security solutions

The Enhaced Bob Maneuver – Subnetting rapido rapido Settembre 15, 2008

Posted by installatore in networking.
Tags: , , , ,
add a comment

In questo post andremo ad analizzare questa tecnica di subnetting immediata nella comprensione e veloce nell’attuazione grazie all’utilizzo di un semplice schema.

 

Lo schema come potete vedere è composto da 4 righe l’utilizzo dello stesso prevede di cominciare dal basso verso l’altto.Al di sotto della riga nera in grassetto,si conta da destra verso sinistra,mentre al di sopra della stessa si conta da sinistra verso destra.Queste sono le semplici regole per utilizzare questa tecnica.

Come prima cosa dobbiamo decidere quante subnets vogliamo nella nostra rete e quindi cercare il numero che gli si avvicina di più nell’ultima riga in basso “Number of valid subnets”.

Una volta individuato il numero di subnets che fà a caso nostro ci spostiamo in linea verticale verso l’alto sulla riga “Bit place” che ci indica il numero di bit dedicati alla subnet (i rimanenti saranno dedicati agli hosts).

Quindi partendo da sinistra (128) sulla riga “Target number” ci spostiamo di tante posizioni quanto è il numero che avevamo trovato sulla riga “Bit place”.Il numero individuato è il numero di hosts presenti nelle nostre subnets.

A questo punto basterà spostarci in linea verticale verso l’alto per trovare la subnetmask che fà al caso nostro.

Adesso facciamo un esempio pratico per schiarirci un pò le idee. vogliamo 9 subnets sull’indirizzo di classe C 192.168.1.0

1)Il numero più vicino a 9 sulla riga “Number of valid subnets” è 14 2)Spostandoci in alto sulla riga “Bit Place” troviamo il numero 4 3)Contando 4 volte da 128 verso destra sulla riga “Target number” troviamo il numero 16 (che sono gli hosts presenti sulle nostre subnets) 4)Muovendoci verso l’alto dal numero 16 sulla riga “Target number” troviamo la “Subnet mask” 240

Quindi la nostra subnet mask è 255.255.255.240 192.168.1.0-15 (255.255.255.240) 192.168.1.16-31 (255.255.255.240) 192.168.1.32-47 (255.255.255.240)