Author Archives: Luca

Come prevenire i bruteforce con Iptabes

Ci sono vari modi per bannare un ip che sta effettuando un attacco di bruteforce al server SSH sul nostro server. Vediamo come fare con Iptables.

Il modo è molto semplice, anche se non è utilizzato da molti, in quanto anche il software fail2ban offre questa feature insieme alle altre. Le regole da inserire sono tre ed utilizzeremo un modulo di Iptables chiamato RECENT, che offre la possibilità di marcare i pacchetti a seconda della frequenza con il quale vengono mandati.

Vediamo l’esempio, e consideriamo che l’interfaccia utilizzata sia eth0

Inizialmente dico ad Iptables di creare un database chiamato SSH degli IP che tentano di connettersi alla porta 22 (server SSH):

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

Dopodiché loggo tutti gli IP che effettuano 3 nuove connessioni in meno di 300 secondi:

iptables -A INPUT -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "

Infine blocco gli IP

iptables  -A INPUT -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP

Una volta che saranno passati i 300 secondi dovrò rimuovere il ban dagli IP:

iptables -A INPUT   -m recent --name SSH --remove

Quello che ho ottenuto è un ban automatico di 300 secondi di un IP che sbaglia 2 volte la password. Se si utilizzano le chiavi SSH è perfetto. Per vedere gli IP che vengono bloccati, essi saranno loggati in /var/log/syslog. Il database degli ip creato da Iptables si trova in /proc/net/ipt_recent/.

Ecco il mio in questo momento:

maradona:/home/luca# cat /proc/net/ipt_recent/SSH
src=66.96.207.19 ttl: 53 last_seen: 1574688771 oldest_pkt: 17 1574675627, 1574676051, 1574676051, 1574676070, 1574676070, 1574676070, 1574676899, 1574676899, 1574677663, 1574677663, 1574677663, 1574678595, 1574678595, 1574681987, 1574681987, 1574688771, 1574688771, 1574675452, 1574675452, 1574675627
src=121.184.33.56 ttl: 45 last_seen: 1523900419 oldest_pkt: 1 1523900419
src=59.30.218.148 ttl: 46 last_seen: 1550603547 oldest_pkt: 1 1550603547
src=122.70.150.106 ttl: 112 last_seen: 1561734410 oldest_pkt: 1 1561734410
src=218.108.0.91 ttl: 112 last_seen: 1580437381 oldest_pkt: 1 1580437381
src=61.236.182.11 ttl: 52 last_seen: 1584381984 oldest_pkt: 4 1584379536, 1584379536, 1584381984, 1584381984, 1584377172, 1584377172, 1584377242, 1584377242, 1584377394, 1584377394, 1584377700, 1584377700, 1584377922, 1584377922, 1584377922, 1584378312, 1584378312, 1584379421, 1584379421, 1584379421
src=195.228.135.138 ttl: 112 last_seen: 1525774504 oldest_pkt: 1 1525774504
src=64.120.26.34 ttl: 52 last_seen: 1548030041 oldest_pkt: 10 1548007267, 1548007267, 1548007583, 1548007583, 1548014434, 1548014434, 1548015069, 1548015069, 1548030041, 1548030041, 1548001891, 1548001968, 1548001968, 1548002398, 1548002398, 1548002398, 1548003683, 1548003683, 1548003840, 1548003840
src=38.108.125.101 ttl: 55 last_seen: 1551424865 oldest_pkt: 1 1551424865
src=85.114.140.73 ttl: 118 last_seen: 1594716674 oldest_pkt: 1 1594716674
src=59.1.90.140 ttl: 46 last_seen: 1550619212 oldest_pkt: 1 1550619212
src=174.36.85.36 ttl: 119 last_seen: 1551527977 oldest_pkt: 1 1551527977
src=211.202.2.107 ttl: 49 last_seen: 1552508574 oldest_pkt: 10 1552476845, 1552476845, 1552478775, 1552478775, 1552483035, 1552483035, 1552491546, 1552491546, 1552508574, 1552508574, 1552475052, 1552475052, 1552475346, 1552475346, 1552475346, 1552475586, 1552475586, 1552476649, 1552476649, 1552476845
src=64.120.26.58 ttl: 52 last_seen: 1589438178 oldest_pkt: 10 1589425634, 1589426141, 1589426141, 1589426141, 1589427426, 1589427426, 1589431010, 1589431010, 1589438178, 1589438178, 1589424066, 1589424066, 1589424290, 1589424290, 1589424641, 1589424641, 1589424641, 1589424738, 1589424738, 1589425634
src=93.93.129.125 ttl: 54 last_seen: 1601942176 oldest_pkt: 19 1601925043, 1601925313, 1601925313, 1601925572, 1601925572, 1601925572, 1601925857, 1601925857, 1601926945, 1601926945, 1601927078, 1601927078, 1601927078, 1601929122, 1601929122, 1601933473, 1601933473, 1601942176, 1601942176, 1601925043
src=112.161.94.145 ttl: 46 last_seen: 1577293804 oldest_pkt: 1 1577293804
src=62.128.149.44 ttl: 50 last_seen: 1562069800 oldest_pkt: 2 1562069208, 1562069800
src=125.138.59.232 ttl: 46 last_seen: 1586717876 oldest_pkt: 1 1586717876
src=14.37.84.210 ttl: 46 last_seen: 1549261247 oldest_pkt: 1 1549261247
src=178.162.239.192 ttl: 54 last_seen: 1593634277 oldest_pkt: 10 1593616610, 1593616610, 1593616805, 1593616805, 1593619302, 1593619302, 1593624293, 1593624293, 1593634277, 1593634277, 1593614621, 1593614621, 1593614934, 1593614934, 1593615110, 1593615110, 1593615110, 1593615557, 1593615557, 1593616610
src=60.190.216.90 ttl: 50 last_seen: 1549489599 oldest_pkt: 0 1549486840, 1549486840, 1549487023, 1549487023, 1549487392, 1549487392, 1549487510, 1549487510, 1549487510, 1549488127, 1549488127, 1549489010, 1549489010, 1549489010, 1549489599, 1549489599, 1549492543, 1549492543, 1549498431, 1549498431
src=112.220.100.226 ttl: 43 last_seen: 1563702466 oldest_pkt: 10 1563673299, 1563673299, 1563674914, 1563674914, 1563678850, 1563678850, 1563686722, 1563686722, 1563702466, 1563702466, 1563671471, 1563671471, 1563671799, 1563671799, 1563671799, 1563671963, 1563671963, 1563672946, 1563672946, 1563673299
src=109.168.123.134 ttl: 120 last_seen: 1571008152 oldest_pkt: 1 1571008152
src=31.210.72.73 ttl: 50 last_seen: 1590914007 oldest_pkt: 9 1590893785, 1590894295, 1590894295, 1590897111, 1590897111, 1590902743, 1590902743, 1590914007, 1590914007, 1590891831, 1590891831, 1590892183, 1590892183, 1590892285, 1590892285, 1590892285, 1590892887, 1590892887, 1590893785, 1590893785
src=109.230.232.145 ttl: 55 last_seen: 1592528351 oldest_pkt: 1 1592528351
src=58.68.174.76 ttl: 54 last_seen: 1520319496 oldest_pkt: 10 1520303368, 1520303369, 1520303369, 1520303369, 1520305672, 1520305672, 1520310280, 1520310280, 1520319496, 1520319496, 1520301352, 1520301352, 1520301640, 1520301640, 1520301869, 1520301869, 1520301869, 1520302216, 1520302216, 1520303368
src=218.108.85.240 ttl: 112 last_seen: 1578974064 oldest_pkt: 1 1578974064
src=95.250.59.247 ttl: 49 last_seen: 1515911697 oldest_pkt: 1 1515911697
src=81.56.117.225 ttl: 47 last_seen: 1562139443 oldest_pkt: 15 1562137225, 1562137303, 1562137303, 1562137303, 1562137911, 1562137911, 1562137955, 1562137955, 1562138784, 1562138784, 1562138784, 1562139351, 1562139351, 1562139443, 1562139443, 1562136857, 1562136857, 1562137199, 1562137199, 1562137225
src=41.139.66.52 ttl: 50 last_seen: 1573686109 oldest_pkt: 1 1573686109
src=109.70.149.42 ttl: 55 last_seen: 1558340790 oldest_pkt: 10 1558325333, 1558325425, 1558325425, 1558325425, 1558327542, 1558327542, 1558331958, 1558331958, 1558340790, 1558340790, 1558323402, 1558323402, 1558323678, 1558323678, 1558323926, 1558323926, 1558323926, 1558324230, 1558324230, 1558325333
src=61.232.11.146 ttl: 115 last_seen: 1590588858 oldest_pkt: 1 1590588858

Trunk SIP multipli con FeePBX e HANGUPCAUSE = 21

4 Replies

Piccolo suggerimento che spiega come attivare due trunk SIP su FreePBX senza ricevere l’errore HANGUPCAUSE = 21.

Nel mio scenario i trunk erano tre e tutti provenienti dallo stesso provider, ogni provider aveva il suo prefisso di teleselezione.
Ho notato che i primi due non funzionavano, mentre il terzo sì. Provandoli singolarmente con un telefono VoIP funzionavano tutti senza problemi.
L’errore che riscontravo era “Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 21”. Il SIP phone falliva la chiamata in uscita dando come errore “forbidden”.
Attivando il debug sulla shell di Asterisk.

sip set debug on

ho notato che ricevevo dal provider degli “access denied” o “login failed”. Ho controllato le credenziali ed ovviamente era tutto giusto.
Guardando su internet ho poi scoperto che con FreePBX (ma mi immagino anche con asterisk o altre soluzioni), in caso di trunk multipli, dobbiamo specificare anche l’utente da utilizzare. Andremo quindi nella sezione “Trunk”, selezioneremo il trunk desiderato e aggiungeremo l’opzione fromuser= nel form PEER details.
Questo è il mio box PEER details:

username=XXXXX
type=peer
secret=supersegreta
host=sip.myprovidervoip.com
insecure=very
dtmfmode=rfc2833
canreinvite=no
context=from-pstn
fromuser=XXXXX

Aggiungendo fromuser= ad ogni trunk, tutte e tre le linee telefoniche hanno iniziato a funzionare correttamente.

Tutorial: Limitare il traffico dei proxy con TC ed Iptables

Leave a reply

Qualche giorno fa ho dovuto far fronte ad un problema di sovraccarico di rete di alcuni server per un provider americano che eroga servizi di anonimato. Nello specifico, proxy e VPN. Ho dovuto quindi stendere un piccolo script per poter fare un po’ di traffic shaping. Ecco come l’ho creato.

Ambiente e servizi

Prima di tutto ho dato un’occhiata al traffico e al modo in cui la macchina eroga i servizi.

Il carico di rete alto proveniva essenzialmente dai proxy, che vengono usati per fare spidering dei siti internet. Si parla quindi di una grande mole di connessioni simultanee da parte dello stesso IP.

I proxy venivano anche usati per effettuare il download di files o lo streaming di flussi video. Ho provato poi a configurare un account nella mia macchina per controllare il numero medio di connessioni simultanee per un utilizzo standard del servizio ed ho visto che tocca punte di 40 connessioni (posta, browsing, ed altre piccole cose), mentre alcuni IP arrivavano anche a 500-600 connessioni.
Il proxy è in ascolto in porta 80.
Per una maggiore usabilità ho chiaramente dovuto escludere dei servizi dal sistema di shaping, come SSH, lasciandoli “liberi di correre”.

Ho deciso quindi di utilizzare un semplice traffic shaping avvalendomi di 2 tools molto potenti: TC e Iptables, che mi hanno consentito di creare una catena dinamica delle connessioni e dei rispettivi limiti di banda.

Ecco come funziona:

La banda viene limitata secondo le possibilità fisiche: se il provider ti offre un limite 10mbit di banda, pena un sovrapprezzo per megabyte, dovremo accuratamente settare la quantità di banda consentita
Le prime 50 connessioni simultanee vengono accodate a priorità 1 a massima velocità
Dalla connessione 51, le connessioni vengono accodate in una catena a banda limitata
I files vengono scaricati a piena velocità da 0 a 9.99Mbyte, da 10Mbyte a 49.99 Mbyte vengono accodati in una coda limitata, e da 50Mbyte in poi, in una coda ancor più limitata.
Possibilità di utilizzare solo una parte della banda totale, utilizzando i parametri “DESIRED” e “DEFAULT”

Vediamo un po’ come implementare questa soluzione:

Prima di tutto creo una sezione per la configurazione delle variabili che utilizzerà lo script:

# Configuration part:
# $IPT binary
IPT=/sbin/iptables
# Tc binary
TC=/sbin/tc
# Physical interface - no virtual interfaces allowed ($ETH:0, $ETH:1 etc)
ETH=eth0
# SSH server port - we accept all connections in order to bypass the shaper
SSH_PORT=131
# Total bw rate
TOTAL_BW=10mbit
# Bandwidth peak - Please set it a little lower than your real preference
PEAK_BW=10mbit
# Desired Bandwidth Rate - Useful if you want to use less bw of your real capacity
DESIRED_BW=9mbit
# Desired peak - Same as above
DESIRED_PEAK=10mbit
# Jail rate - Set it quite lower if you want real results
JAIL_BW=512mbit
# Jail peak - Same as above
JAIL_PEAK=1mbit
# Default Bandwidth
# Set: 1 for Total values
#      2 for Desired values
DEFAULT_BW=2
# Connection Limit - Note that we talk about symultaneous connections. A good value is 10
CONNLIMIT=30
# Set first size limit
FIRST_SIZE=10485760
# Set the total available bandwidth for the first size limit
FIRST_SIZE_BW=1mbit
# Set the total available peak for the first size limit
FIRST_SIZE_PEAK=1mbit
# Set second size limit
SECOND_SIZE=52428800
# Set the total available bandwidth for the second size limit
SECOND_SIZE_BW=512kbit
# Set the total available peak for the second size limit
FIRST_SIZE_BW_PEAK=512kbit
# End of configuration file

Dopodiché creo lo script vero e proprio:

Prima di tutto faccio un flush della tavola di mangle (che serve per il mark dei pacchetti) e della catena di OUTPUT – che è l’unica che utilizzerò -:

# Flush all queues
$TC qdisc del dev $ETH root
# Flush mangle chains
$IPT -t mangle -F
$IPT -t mangle -Z
$IPT -t mangle -X
$IPT -F OUTPUT

A questo punto posso creare la qdisc, con le relative classi:

# Creating New TC queue
$TC qdisc add dev $ETH root handle 1: htb default $DEFAULT_BW
$TC class add dev $ETH parent 1: classid 1:1 htb rate $TOTAL_BW ceil $PEAK_BW
$TC class add dev $ETH parent 1:1 classid 1:2 htb rate $DESIRED_BW ceil $DESIRED_PEAK
$TC class add dev $ETH parent 1:1 classid 1:3 htb rate $JAIL_BW ceil $JAIL_PEAK
$TC class add dev $ETH parent 1:1 classid 1:4 htb rate $FIRST_SIZE_BW ceil $FIRST_SIZE_PEAK
$TC class add dev $ETH parent 1:1 classid 1:5 htb rate $SECOND_SIZE_BW ceil $FIRST_SIZE_BW_PEAK

Poi aggancio le classi al device principale:

# Adding the queue lists to the main device
$TC qdisc add dev $ETH parent 1:2 sfq
$TC qdisc add dev $ETH parent 1:3 sfq
$TC qdisc add dev $ETH parent 1:4 sfq
$TC qdisc add dev $ETH parent 1:5 sfq

Dico a TC di effettuare il traffic shaping secondo il mark dei pacchetti di Iptables:

# Adding filter by packet mark
$TC filter add dev $ETH parent 1:0 protocol ip prio 1 handle 7 fw flowid 1:3
$TC filter add dev $ETH parent 1:0 protocol ip prio 1 handle 20 fw flowid 1:4
$TC filter add dev $ETH parent 1:0 protocol ip prio 1 handle 21 fw flowid 1:5

Ed infine creo le regole di MARK su Iptables e il canale preferenziale per SSH:

# Setting packet connmarks:
$IPT -A PREROUTING -t mangle -j CONNMARK --restore-mark
$IPT -A POSTROUTING -t mangle -m mark ! --mark 0 -j ACCEPT
$IPT -A POSTROUTING -t mangle -p tcp  -m connlimit --connlimit-above $CONNLIMIT -j MARK --set-mark 7
$IPT -A POSTROUTING -t mangle -j CONNMARK --save-mark
# Setting file size mark
$IPT -A OUTPUT -p tcp --sport $SSH_PORT -j ACCEPT
$IPT -A OUTPUT -p tcp -o $ETH -m connbytes --connbytes $SECOND_SIZE: --connbytes-dir both  --connbytes-mode bytes -j MARK --set-mark 21
$IPT -A OUTPUT -p tcp -o $ETH -m connbytes --connbytes $FIRST_SIZE:$SECOND_SIZE --connbytes-dir both  --connbytes-mode bytes -j MARK --set-mark 20
$IPT -A OUTPUT -p tcp  -m connlimit --connlimit-above $CONNLIMIT -j MARK --set-mark 7

Conclusione

Non sono sicuro al 100% che questo script sia stato steso in maniera perfetta, certo è che funziona abbastanza bene. I carichi sui suddetti server sono spariti e la navigazione con i proxy è fluida e veloce, nonostante ora venga utilizzato solamente circa un terzo della banda.

Come limitare il tempo o il volume dati con freeradius: Rlm_sqlcounter

Leave a reply

Eccovi semplice un how-to che vi consentirà di abilitare le limitazione di traffico e di tempo su freeradius in pochi passi utilizzando Rlm_sqlcounter.

In un vecchio post ho parlato di come installare e configurare Coovachilli su Ubuntu, e utilizzarlo con un’autenticazione Radius basata su Mysql. Oggi vi mostrerò come limitare gli account in base al volume di traffico e al tempo.

Lo strumento che andremo ad utilzzare è Rlm_sqlcounter.

Rlm_sqlcounter è un plugin per Freeradius che, tramite una query sql, restituisce il volume di tempo o di traffico rimanente nell’autenticazione mediante l’utilizzo di attributi radius specifici. In caso il tempo o il traffico siano terminati, l’autenticazione non andrà a buon fine.

Vi ricordo che l’autenticazione dovrà essere fatta tassativamente tramite mysql.

Gli attributi che verranno utilizzati sono:

Max-All-Session - Per quanto riguarda il volume di tempo (in secondi)
Max-All-MB - Per quanto riguarda il volume di traffico (in bytes)

L’implementazione è semplice. Le più moderne distribuzioni pacchettizzate (Debian, Ubuntu, Centos) già prevedono la possibilità di attivare il plugin. Pertanto quello che dovrete fare è:

Attivare il plugin nel file di configurazione principale di freeradius:

vim /etc/freeradius/radiusd.conf
oppure
vim /etc/raddb/radiusd.conf

e decommentare la seguente riga:

$INCLUDE ${confdir}/sqlcounter.conf

Dopodiché aprite – o create in caso non esistesse – il file sqlcounter.conf e aggiungete queste righe:

vim /etc/freeradius/sqlcounter.conf
oppure
vim /etc/raddb/sqlcounter.conf

e aggiungete queste righe:

sqlcounter noresetcounter {
counter-name = Max-All-Session-Time
check-name = Max-All-Session
sqlmod-inst = sql
key = User-Name
reset = never
query = "SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{%k}'"

}

sqlcounter octetslimit {
counter-name = Max-All-MB
check-name = Max-All-MB
reply-name = Chillispot-Max-Total-Octets
key = User-Name
reset = never
query = "SELECT SUM(acctinputoctets+acctoutputoctets) from radacct WHERE UserName='%{%k}'"
sqlmod-inst = sql
}

Infine andate ad attivare il count del traffico e del tempo:

vim /etc/freeradius/sites-available/default
oppure
vim /etc/raddb/sites-available/default

e in fondo alla sezione authorize aggiungete:

authorize {
...
...
...

noresetcounter
octetslimit
}

riavviate freeradius

/etc/init.d/freeradius restart
oppure
/etc/init.d/radiusd restart

A questo punto il vostro server dovrebbe essere apposto. Quello che resta da fare è provare a limitare un utente. Eccovi qualche esempio di utilizzo:

– L’utente test0001 ha un volume complessivo di tempo di 15 MegaBytes (l’utente può effettuare il login quante volte lo ritiene necessario, ma può essere online per una quantitaà totale di traffico di 15 MegaBytes, ovvero 165675008 bytes). La query da inserire sarà:

INSERT into radcheck VALUES ('','test0001','Max-All-MB','165675008',':=');

Fintanto che l’utente avrà a disposizione del tempo, l’autenticazione andrà a buon fine utilizzando la propria password:

[root@kingston raddb]#  radtest test0001 test 10.100.0.1 0 passwordradius
Sending Access-Request of id 228 to 10.100.0.1 port 1812
User-Name = "test0001"
User-Password = "test"
NAS-IP-Address = 173.255.219.122
NAS-Port = 0
rad_recv: Access-Accept packet from host 10.100.0.1 port 1812, id=132, length=20
ChilliSpot-Max-Total-Octets = 165675008
[root@kingston raddb]#

Una volta che il tempo si sarà esaurito, il radius non autenticherà l’utente:

[root@kingston raddb]#  radtest test0001 test 10.100.0.1 0 passwordradius
Sending Access-Request of id 228 to 10.100.0.1 port 1812
User-Name = "test0001"
User-Password = "test"
NAS-IP-Address = 173.255.219.122
NAS-Port = 0
rad_recv: Access-Reject packet from host 10.100.0.1 port 1812, id=228, length=68
Reply-Message = "Your maximum never usage time has been reached"
[root@kingston raddb]#

Lo stesso comportamento succede per quanto riguarda l’attributo Max-All-Session.

Se avete problemi con con il funzionamento vi ricordo che si può attivare il debug in foreground arrestando il demone:

/etc/init.d/freeradius stop

oppure

/etc/init.d/radiusd stop

ed avviando la modalità debug:

freeradius -XXX

oppure

radiusd -XXX

oppure potete consultare i log che si trovano in:

/var/log/freeradius

oppure

/var/log/radius/

Happy Hacking!

Creepy – una nuova applicazione per cacciare utenti!

Luca Rossi – Sistemista Linux Freelance

Appunti sui sistemi Linux

Author Archives: Luca

Come prevenire i bruteforce con Iptabes

Trunk SIP multipli con FeePBX e HANGUPCAUSE = 21

Tutorial: Limitare il traffico dei proxy con TC ed Iptables

Come limitare il tempo o il volume dati con freeradius: Rlm_sqlcounter

Creepy – una nuova applicazione per cacciare utenti!