Re: fail2ban

2023-07-25 Per discussione Giuliano Curti
Il mar 25 lug 2023, 15:48 Paride Desimone  ha scritto:

Ciao Paride,

Qualcuno che usa file2ban? Mi occorrerebbe una mano sulla configurazione
> del ban (ipv6 ed ipv4) dopo tre tentativi sbagliati di login su http ed
> https, porte 80 e 443.
> Quesato è quello che dobrei bannare dopo tre tentativi errati:
>
> 2023-07-25 14:21:47 ERROR logapache [16387]: [:::10.10.253.22]
> Failed authentication for user u'pippo'
>

L'avevo usato tempo fa per un'applicazione casalinga (non sono un
amministratore di rete).

Quello che dici tu dovrebbe farlo automaticamente; mi sembra di ricordare
che tu possa settare la soglia (quanti tentativi in quanto tempo) e la
durata dell'espulsione, ma sto andando un po' a tentoni.

Se precisi meglio il tuo dubbio diventa più facile risolvere :-)

/paride
>

Ciao,
Giuliano


Re: fail2ban

2023-07-25 Per discussione Leandro Noferini


Paride Desimone  writes:

> Qualcuno che usa file2ban? Mi occorrerebbe una mano sulla configurazione del 
> ban
> (ipv6 ed ipv4) dopo tre tentativi sbagliati di login su http ed https, porte 
> 80
> e 443.
> Quesato è quello che dobrei bannare dopo tre tentativi errati:
>
> 2023-07-25 14:21:47 ERROR logapache [16387]: [:::10.10.253.22] Failed
> authentication for user u'pippo'

Io per nginx ho in /etc/fail2ban/jail.conf quest righe

[nginx-http-auth]

port= http,https
logpath = %(nginx_error_log)s

[nginx-limit-req]
port= http,https
logpath = %(nginx_error_log)s

[nginx-botsearch]

port = http,https
logpath  = %(nginx_error_log)s
maxretry = 2

E la cosa pare funzionare.

--
Ciao
leandro



fail2ban

2023-07-25 Per discussione Paride Desimone
Qualcuno che usa file2ban? Mi occorrerebbe una mano sulla configurazione 
del ban (ipv6 ed ipv4) dopo tre tentativi sbagliati di login su http ed 
https, porte 80 e 443.

Quesato è quello che dobrei bannare dopo tre tentativi errati:

2023-07-25 14:21:47 ERROR logapache [16387]: [:::10.10.253.22] 
Failed authentication for user u'pippo'


/paride
--
https://keyserver.gnupg.org/pks/lookup?op=get&search=0xf14cd648d16d33c82a7d2ac778c59a24690431d3

Chi e' pronto a rinunciare alle proprie liberta' fondamentali per 
comprarsi briciole di temporanea sicurezza non merita ne' la liberta' 
ne' la sicurezza.(Benjamin Franklin - dalla Risposta al Governatore, 
Assemblea della Pennsylvania, 11 novembre 1755)




Re: Debian 12 - Messaggi dmesg

2023-07-25 Per discussione pinguino

Il 24/07/23 11:47, Alessandro Rubini ha scritto:

[0.208536] ** This system shows unhashed kernel memory addresses   **


Vuol dire che i messaggi del kernel mostrano gli indirizzi interni
invece di una "hash" degli stessi (ma solo se il driver usa "%p" per
stampare il puntatore, invece che le normali stringhe testuali.
Per esempio in caso di oops o panic.


[0.208536] ** via the console, logs, and other interfaces. This**


Appunto, i messaggi.

Questo quadratozzo di NOTICE sta in lib/vsprintf.c nei sorgenti del kernel,
da cui vedo che dipende dal parametro "no_hash_pointers".

Buongiorno Lista,
Qua ho trovato questo:
https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html?highlight=boot%20parameter
 no_hash_pointers
Force pointers printed to the console or 
buffers to be
unhashed.  By default, when a pointer is 
printed via %p
format string, that pointer is "hashed", i.e. 
obscured
by hashing the pointer value.  This is a 
security feature
that hides actual kernel addresses from 
unprivileged

users, but it also makes debugging the kernel more
difficult since unequal pointers can no longer be
compared.  However, if this command-line option is
specified, then all normal pointers will have 
their true
value printed. This option should only be 
specified when
debugging the kernel.  Please do not use on 
production

kernels.

Spiega cosa fa. Poi alla fine dice di non usarlo nei kernels di produzione.



Guardando /proc/cmdline si dovrebbe vedere la presenza di questa
opzione, che si puo` togliere nella configurazione del boot loader.

In /boot/grub/grub.cfg non ho trovato quel parametro.
Non so se lo devo aggiungere ?

Io ho trovato questo nel mio /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 
root=UUID=880d6880-906e-49a6-8e72-bef089ab837e ro kaslr pti=on 
slab_nomerge page_poison=1 slub_debug=FPZ nosmt


Non c'è il parametro no_hash_pointers

Grazie
Saluti
Claudio



Io, che sono vecchio e rinco, non vedo 'sto gran problema di
sicurezza, e da sviluppatore preferisco di gran lunga i numeri
veri. Ma oggi non si possono minimizzare potenziali minacce senza
sembrare rinco (appunto!) quindi forse andrebbe tolta l'opzione.

Il dubbio che rimane e` perche` qualcuno ha messo quel parametro,
che serve solo a chi fa debug sul kernel. Da me non c'e` :)

Comunque tra ricerche in rete e/o "git blame" sui sorgenti, e` spiegato
tutto.

saluti
/alessandro



--
https://www.linkedin.com/in/claudio-sandrone