If your IRCd allows an unauthenticated connection to start spamming like that, changing the port so a browser can't do it is just wallpapering over the real problem. Anybody that cared to could just use any other software to spam your IRCd.
The issue remains that your ircd is still wide open, waiting for somebody more creative to find another way of opening connections inside your LAN on arbitrary ports. Counting on browsers to keep your network secure is foolish.
> The issue remains that your ircd is still wide open
Wide open, from within the LAN... not many consider internal apps wide open.
Besides browsers, you need actual hacking to reach internal services, a SSRF for example. Or real remote code execution and at that point, you have other problems.
> Counting on browsers to keep your network secure is foolish.
I think what you're saying is: treating the internal network as secure is foolish. That I would agree with.
I never said you should rely on the browsers port banning. It's the other way around, people usually don't even know you can talk to IRC over HTTP and therefore don't even consider it a risk and are protected without even knowing.
My point is not "use port banning as security measure". My point is just: if you move apps to a non-standard port you might expose it to browsers, so better use the standard!
