On 6/28/2019 9:30 PM, Bill Shirley wrote:
conntrack tracks UDP. Try running:
conntrack -L | grep udp
That would depend on the sender using real source addresses. A naive
attacker might do that. Or an attacker behind an ISP that does proper
egress filtering.
conntrack tracks UDP. Try running:
conntrack -L | grep udp
Bill
On 6/28/2019 9:04 AM, BASSAGET Cédric wrote:
Hello Bill,
would that apply to UDP traffic ? I think it does not as UDP is stateless
Regards
Le ven. 28 juin 2019 à 14:43, Bill Shirley mailto:bshir...@openmri-scottsboro.com>> a
On 6/28/2019 6:04 AM, BASSAGET Cédric wrote:
would that apply to UDP traffic ? I think it does not as UDP is stateless
It's almost trivial to forge source addresses in UDP, so each packet
might have a unique source address. The address might be that of an
important victim that the attacker
Hello Bill,
would that apply to UDP traffic ? I think it does not as UDP is stateless
Regards
Le ven. 28 juin 2019 à 14:43, Bill Shirley
a écrit :
> Some attacks open up tens, if not hundreds, of connections at one time. I
> think fail2ban
> works by blocking *new* connections and since these
Some attacks open up tens, if not hundreds, of connections at one time. I
think fail2ban
works by blocking *new* connections and since these connections are already
initiated
they don't get banned.
You could limit the number of simultaneous connections with iptables.
Something like:
ACCEPT
I'm using sipvicious to test that. If sipvicious send a fast flow of SIP
requests (dozens per second), fail2ban does not ban the IP address until it
has reached the end of the logfile. Because fai2ban parses the logfile
slower than the SIP requests are received, fail2ban does not reach the end
of
Hello
I'm trying to underestand why fail2ban takes too uch time (> 1 sec) to
detect tthat an IP address has to be banned and ban it
Here's my fail2ban.log (truncated) :
2019-06-28 14:10:30,253 fail2ban.filter [24709]: INFO[asterisk]
Found 91.121.2.x
about 3000 same entries
