No need to thank me ;) Ron -- Ronald L. Johnson [email protected] 628.202.2396
On Tue, Jan 19, 2021 at 1:44 AM Dan Mahoney (Gushi) <[email protected]> wrote: > On Mon, 18 Jan 2021, Ronald L. Johnson wrote: > > > If that's the case and you have this huge worldwide presence and > > millions of customers, why then are you not using some of that hard > > earned cash to use proper commercial products? Just seems very odd to > > me... > > We have a couple dozen users on our SIP server. We're a small software > company with developers around the world using their own devices. That's > the userbase of this system. I never said millions of customers. > > SIP isn't our main business at all, but we do know what we're doing with > it. This kind of functionality is not something that asterisk builds in, > and compromising a SIP server is considered a high-value target. > > That said, I'm quickly coming to two conclusions: > > 1) Fail2Ban has trouble scaling to this type of load. > > 2) I suspect I've gotten all the help I'm likely to get here. > > I know my regexes work, as confirmed by the fail2ban tools. I've > replicated the problem more than once. I've been accused of being a > spammer and then had our business decisions questioned. > > I'm happy to keep working with a developer, offer real time traffic pcaps > or whatnot, but for obvious reasons, I don't want to post hostnames or ip > addresses to a public list. > > I thank you all for it and wish you all a safe 2021. > > -Dan > > > > > Ron > > -- > > Ronald L. Johnson > > [email protected] > > 628.202.2396 > > > > > > On Sun, Jan 17, 2021 at 11:23 PM Dan Mahoney (Gushi) <[email protected]> > wrote: > > On Sun, 17 Jan 2021, Ron Johnson wrote: > > > > > > > > Sounds like we’re trying to help someone fix a spamming sip > server. Should we be doing this? Forgive me if I’m wrong. > > > > *sigh* > > > > No, you're trying to help someone fix Fail2Ban on a SIP server > that must > > be open for registrations from the entire world because our > employees do > > not always use a corporate VPN. Additionally, for historic > reasons, > > people in our community are occasionally called via their direct > > sip://uri. (Less so than years ago, but we were part of something > called > > INOC-DBA which was sort of a community-based sip pool). > > > > What that means is you'll get two different classes of things: > > > > 1) Lots of fake registrations, which fail. > > > > [2021-01-17 18:54:56] NOTICE[828]: chan_sip.c:28499 > > handle_request_register: Registration from > > '"2001"<sip:[email protected]>' > > failed for '82.205.10.23:29868' - Wrong password > > > > [2021-01-17 18:55:40] NOTICE[828]: chan_sip.c:28499 > > handle_request_register: Registration from > '<sip:[email protected]>' > > failed for '212.129.42.78:58728' - Wrong password > > > > 2) Lots of unregistered calls, which hope that your dialplan is > woefully > > misconfigured and will allow those calls anyway, which will also > fail. > > (If it had ever "worked" we would know because our long distance > accounts > > would be depleted, which have their own (financial) rate-limits and > > alerting on them. > > > > [2021-01-17 19:05:04] NOTICE[828][C-000717b2]: chan_sip.c:26273 > > handle_request_invite: Call from '' (192.40.59.239:57878) to > extension > > '111111011972595725668' rejected because extension not found in > context > > 'untrustedsip'. > > > > [2021-01-17 19:01:45] NOTICE[828][C-000717b1]: chan_sip.c:26273 > > handle_request_invite: Call from '' (62.210.100.129:5071) to > extension > > '0041215080459' rejected because extension not found in context > > 'untrustedsip'. > > > > The thing is, when you're in the asterisk console trying to debug a > > non-working extension, all the above scrolls past so quickly that > it makes > > things impossible to use. > > > > Additionally, denying these requests and sending back a 401 > response is > > traffic we'd rather not generate because SIP is UDP, so it *could* > be > > spoofed and be a reflection attack. (It's probably not, since that > would > > make the calls not work). > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > Sent from Mail for Windows 10 > > > > > > > > > > > > From: Dan Mahoney (Gushi) > > > Sent: Sunday, January 17, 2021 11:24 AM > > > To: James Moe > > > Cc: [email protected] > > > Subject: Re: [Fail2ban-users] Fail2Ban finding but not blocking. > > > > > > > > > > > > On Sun, 17 Jan 2021, James Moe via Fail2ban-users wrote: > > > > > > > > > > > > > On 1/14/21 8:12 AM, Dan Mahoney (Gushi) wrote: > > > > > > > > > > > > > >> We have a regex that "matches" but I watch fail2ban.log with > "tail > > > > > > >> -F" and I watch match and match and match > > > > > > >> and not ban. > > > > > > >> > > > > > > > I see a similar pattern here for this reason: When f2b scans > a log file it > > > > > > > finds multiple log entries of an attack, and lists them all as > an INFO. Then at > > > > > > > the end of the scan, the IP is banned. > > > > > > > Your f2b log shows f2b was restarted before the scan was > finished. After the > > > > > > > restart, the scan continued and the IP was ultimately banned. > > > > > > > > > > > > So, what ends the scan? > > > > > > > > > > > > From what you're saying it sounds like fail2ban has to hit the > EOF marker, > > > > > > which would imply as long as one could fill the logs faster than > fail2ban > > > > > > can count, you can evade a block. > > > > > > > > > > > > These are often very fast scans, attempts to push dozens or > hundreds of > > > > > > registrations/calls through our asterisk server all at once. > (Yes, it has > > > > > > to be public for historic reasons -- we have a global userbase). > > > > > > > > > > > > Note: I watched the logs for at least ten seconds waiting for > something to > > > > > > happen, with screenfuls of the same ip not blocking. I gave it > a good > > > > > > shot to catch itself before restarting. > > > > > > > > > > > > -Dan > > > > > > > > > > > > -- > > > > > > > > > > > > --------Dan Mahoney-------- > > > > > > Techie, Sysadmin, WebGeek > > > > > > Gushi on efnet/undernet IRC > > > > > > FB: fb.com/DanielMahoneyIV > > > > > > LI: linkedin.com/in/gushi > > > > > > Site: http://www.gushi.org > > > > > > --------------------------- > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Fail2ban-users mailing list > > > > > > [email protected] > > > > > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > > > > > > > > > > > > > > > > -- > > > > <Belldandy> ha. you have not met me. > > <BaldDwarf> ha. but i have sene pictures > > <Belldandy> thanks but uh., > > <BaldDwarf> seen dammit! SEEN! > > <Gushi> I don't know who dammit! is. > > <Belldandy> so anyway > > > > -Undernet #reboot, October 2nd, 2000, 3AM > > > > --------Dan Mahoney-------- > > Techie, Sysadmin, WebGeek > > Gushi on efnet/undernet IRC > > FB: fb.com/DanielMahoneyIV > > LI: linkedin.com/in/gushi > > Site: http://www.gushi.org > > --------------------------- > > > > > > > > -- > > "If you need web space, give him a hard drive. If you need to do > something really heavy, build him a computer." > > -Ilzarion, late friday night > > --------Dan Mahoney-------- > Techie, Sysadmin, WebGeek > Gushi on efnet/undernet IRC > FB: fb.com/DanielMahoneyIV > LI: linkedin.com/in/gushi > Site: http://www.gushi.org > --------------------------- >
_______________________________________________ Fail2ban-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fail2ban-users
