[Risolto] Bloccare l'accesso internet in base al mac address

Fedora Linux Internet, Reti e Sicurezza
#1

Salve,

come in oggetto, vorrei bloccare l’accesso internet ai computer della rete interna tramite mac addres.
Googlando un po, ho trovato questo
iptables -A INPUT -p tcp --dport PORT -m mac ! --mac-source MIO NUMERO MAC ADDRESS -j DROP

sostituendola con

iptables -A INPUT -m mac ! --mac-source MIO NUMERO MAC ADDRESS -j DROP

Ho tolto “-p tcp --dport PORT” perché con nessun protocollo devono collegarsi, ma non funziona.

Il problema è che ho dei computer interni probabilmente infetti che fanno sniff su computer esterni, e mi vengono dei reclami dall’indirizzo esterno.

Vorrei aprirne uno alla volta per vedere quale di questi è, ma se avete un suggerimento diverso (tipo un programma che controlla questi sniff o quant’altro) ve ne sarei grato.

Sergio

#2

Ciao Sergio,

Una Fedora “sana” non fa sniffing (anche se probabilmente la parola esatta non è sniffing, dal momento che non è possibile sniffare traffico esterno alla rete in cui giaci). Penso che tu debba prendere seriamente in considerazione l’update. Tutte le versioni di Fedora EOL (quindi <= 21) hanno diversi gravi problemi di sicurezza che non sono patchati (dal momento che sono EOL).

PS: Corretto ‘>’ con ‘<’, grazie mille marcomotta :slight_smile:

#3

Tutte le versioni di Fedora EOL (quindi <= 21)

#4

La catena INPUT processa solo le richieste dei client dirette alla macchina firewall.
Quella regola dovresti utilizzarla nella catena FORWARD o in una creata ad hoc da te, dove vengono processate le richieste dei client verso Internet e quindi oltre il firewall.
Dipende un po’ da come hai configurato Netfilter tramite iptables.
Eventualmente puoi postarne la configurazione?

#5

Grazie a tutti delle risposte :slight_smile:

fale:
non credo sia il server con fedora 21 che fa sniffing, ma probabilmente un computer all’interno della rete che, con il masquerade, esce con l’ip del server.

cupo:
non ho iptables funzionante, ma solo firewall-config. L’unico parametro è quello che c’è in alto.

#6

[quote=sergio59]Grazie a tutti delle risposte :slight_smile:
fale:
non credo sia il server con fedora 21 che fa sniffing, ma probabilmente un computer all’interno della rete che, con il masquerade, esce con l’ip del server.
[/quote]
Possibile.
Se ci sono macchine F21 (indipendentemente dove siano nella tua rete) imho vanno aggiornate

#7

Ci fai vedere qualche output della macchina firewall Fedora, giusto per farci un’idea di come è configurata?

[code]$ ip a
$ route -n
$ cat /proc/sys/net/ipv4/ip_forward

iptables -t nat -L -n

iptables -t filter -L -n[/code]

#8 
ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: p3p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:0e:e8:e0:15:cc brd ff:ff:ff:ff:ff:ff
    inet 141.250.121.168/24 brd 141.250.121.255 scope global p3p1
       valid_lft forever preferred_lft forever
    inet6 fe80::20e:e8ff:fee0:15cc/64 scope link 
       valid_lft forever preferred_lft forever
3: p3p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:0e:e8:e0:2e:99 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global p3p2
       valid_lft forever preferred_lft forever
    inet6 fe80::20e:e8ff:fee0:2e99/64 scope link 
       valid_lft forever preferred_lft forever
4: p2p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether bc:ee:7b:88:e0:b4 brd ff:ff:ff:ff:ff:ff
route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         141.250.121.3   0.0.0.0         UG    1024   0        0 p3p1
141.250.121.0   0.0.0.0         255.255.255.0   U     0      0        0 p3p1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 p3p2
cat /proc/sys/net/ipv4/ip_forward

1
iptables -t nat -L -n

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
iptables -t filter -L -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
LOG        tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22 flags:0x17/0x02 LOG flags 0 level 4 prefix " OUTPUT PORT 22 "
#9

Su quale delle due subnet sono attestati i client che vuoi monitorare?

#10

la numero 3. p3p2. 192.168.1.1

#11

Salve…
con la regola che c’è sulla catena di output su log, ho dato una controllata su journalctl --since=today e mi sono capitateun numero di log tipo

OUTPUT PORT 22 IN= OUT=p3p1 SRC=141.250.121.168 DST=31.190.11.4 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=57205 DF PROTO=TCP SPT=51776 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0

e per il momento finisce con

OUTPUT PORT 22 IN= OUT=p3p1 SRC=141.250.121.168 DST=31.190.64.172 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=28129 DF PROTO=TCP SPT=59341 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0

ed è ricominciata con un altro ip finendo, per il momento, con

OUTPUT PORT 22 IN= OUT=p3p1 SRC=141.250.121.168 DST=78.5.51.24 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1667 DF PROTO=TCP SPT=50977 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0

Ora io vorrei conoscere chi da questi comandi per cercare collegamenti ssh su macchine remote!

#12

L’indicazione SRC=141.250.121.168 del log indica chiaramente che la connessione verso indirizzi Ip esterni diretti alla porta tcp 22 proviene dalla tua macchina Fedora…
E non potrebbe essere diversamente dal momento che all’interno della catena OUTPUT della tabella Filter vengono processate le connessioni originate dalla macchina stessa verso altri host.
Quello che a me personalmente non risulta molto chiaro sulla base degli output che hai fornito nei post precedenti è la funzione di questa macchina.

Mi spiego meglio. Se questa macchina deve fare da firewall per i client attestati sulla subnet 192.168.1.0/24 significa che il default gateway configurato sugli host dovrebbe essere 192.168.1.1
In questo modo, tutte le richieste originate dai singoli client della rete e destinate verso subnet differenti e/o Internet vengono dirette in prima battuta alla tua macchina che “deciderà” poi se consentirle o meno (elaborazione svolta nella catena FORWARD della tabella filter).
In caso affermativo dette richieste verranno poi sottoposte a Nat e inoltrate, tipicamente ad un router connesso ad una seconda intefaccia (scheda di rete) della macchina firewall.

Tuttavia l’output della tabella Nat che hai mostrato non evidenzia alcuna configurazione con questa specifica, ad esempio un tipico masquerade o un source nat.
Sei sicuro che i client non siano configurati con un indirizzo ip come default gateway che punta direttamente al router bypassando la tua macchina?

Se cosí fosse non hai purtroppo modo di svolgere il monitoraggio che intendevi realizzare a meno di rivedere la configurazione della tua lan.

Mi scuso se non sono riuscito ad esprimermi chiaramente o se non ho compreso correttamente la configurazione della tua rete.

Nel dubbio, hai la possibilità di mostrare la configurazione di rete (indirizzo ip, subnet mask e default gateway) di un client qualsiasi configurato sulla subnet 192.168.1.0/24 ?

#13

Mi spiego meglio:
La rete interna è composta da due GW. Uno è 192.168.1.1 e l’altro è 192.168.1.51.
La prima è una rete più veloce della seconda ed essendo la seconda più lenta ma più affidabile, imposto la maggior parte dei computer interni ad usare il GW 192.168.1.1
Le macchine interne sono impostate chiaramente con indirizzo IP 192.168.1.X, e nel caso escano dal primo GW lo hanno impostato 192.168.1.1 con subnet mask /24 DNS 8.8.8.8
Correggimi se sbaglio. La catena di output fa vedere cosa avviene in output, ma non in input dalla rete interna, quindi per controllare quale macchina genera traffico, dovrei inserire il comando per funzionare sull’input della scheda p3p2!

#14

Se sei d’accordo ti proporrei un approccio un po’ più “basico” al problema perché mi resta ancora qualche perplessità in merito alla configurazione della tua lan.

Proviamo ad effettuare un dump di tutto il traffico che transita per l’interfaccia p3p2 e verifichiamo chi lo origina e verso quali host esterni rispetto alla rete locale è destinato.

Ci affidiamo a tcpdump

Verifica se il relativo pacchetto è già disponibile sulla macchina Fedora

 $ rpm -q tcpdump

Se il pacchetto non è presente installalo

 # dnf install tcpdump

Quando hai il maggior numero di client in attività verifica il traffico che transita per la tua macchina Fedora con *tcpdump *

 # tcpdump -i p3p2 -nn -q tcp and dst net not 192.168.1.0 mask 255.255.255.0

Se riscontri qualche output che ritieni anomalo postalo pure

#15

Ciao Cupo,
non so quando avviene il collegamento, quindi do il comando per tutta la giornata. Nel frattempo, se vedo qualche cosa, la posto.

#16

Primo risultato…

tramite il comando

tcpdump -i p3p2 -nn -q tcp and dst net not 192.168.1.0 mask 255.255.255.0

ho visto che c’è una macchina un po’ strana che ha prodotto questi risultati.

09:21:53.072626 IP 192.168.1.19.4346 > 141.250.198.211.13000: tcp 0

con altre righe simili a questa dove però cambia la porta di richiesta (ho pensato fosse quella dopo l’ip, nel caso la 4346) ed il computer di destinazione lasciando invariata la porta di arrivo (sempre se ho pensato bene la 13000)
Sono andato un po’ in giro ed ho visto che la http://2600-skimonhertz.forumcommunity.net/?t=44497179 è usata da http://www.paretologic.com/resources/definitions.aspx?remove=Senna%20Spy%20FTP%20Trojan ed allora ho impedito al computer 192.168.1.19 di accedere ad internet bloccandolo tramite il mac-address con la regola

iptables -A INPUT -m mac --mac-source 00:e0:7d:7d:93:57 -j DROP

Un’altra cosa che ho fatto è stata quella di abilitare il LOG su iptables sulla catena di INPUT e FORWARD con i comandi

iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j LOG --log-prefix ' INPUT PORT 22 '

e

iptables -A FORWARD -p tcp -m tcp --dport 22 --syn -j LOG --log-prefix ' FORWARD PORT 22 '

La catena di INPUT ha prodotto anche quella moti risultati, tra i quali quella di un computer che mi da questo risultato.

localhost.localdomain kernel:  INPUT PORT 22 IN=p3p1 OUT= MAC=00:0e:e8:e0:15:cc:bc:ea:fa:03:cb:c8:08:00 SRC=183.3.202.106 DST=141.250.121.168 LEN=60 TOS=0x08 PREC=0x00 TTL=35 ID=25236 DF PROTO=TCP SPT=50401 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0

Cosa ne pensi?

#17

Forse ho trovato l’arcano…
sempre googlando, ho trovato quest’altro comando che mi da i processi che sono in esecuzione con protocollo tcp.

netstat -tapn

Mi ha dato una lista di output con il mio computer che sniffa sulla porta 22 di intere reti, ed il programma che fa cio, è hald-runner situato un /usr/bin.

Ho provato a killarlo, ma riparte.

Per sicurezza, ho controllato sull’altro computer che può fare da gateway, ma non c’è questo processo.
Penso sia questo il problema…

Cos’è e a cosa serve hald-runner?

#18

E’ questo senz’altro…

Ho rinominato il file /usr/bin/hals-runner in /usr/bin/hald-runner2.
Ho killato il processo, ma è ripartito.
Ho cercato hard-runner tramite la funzione locate (dopo aver fatto un updatedb) ma mi ha dato hard-runner2 sotto /usr/bin

Cosa posso fare?

#19

Ti restituisce qualcosa

 $ rpm -q -f /usr/bin/hald-runner

? (scrivi però il nome corretto di quell’eseguibile… nel post l’hai chiamato in modi diversi… hals, hard, hald… ) :slight_smile:

#20

Il dubbio è che quella macchina sia stata in qualche modo compromessa.
Limitandosi a fare solo forwarding senza filtering del traffico l’ipotesi non è da escludere.
Trattandosi poi di una edizione End Of Life, come altri utenti del forum hanno giustamente evidenziato, le probabilità aumentano.
Puoi postare anche

$ rpm -q gcc make 
$ ss -l -n -t 
# tac /var/log/secure
# cat /etc/passwd
$ sestatus