I am proud to finally see this long long long time feature request not getting batted down after the first couple of emails (hostmasking). This very much has a need, I was shut down by a packet kiddie angry at another user and started targeting people in the channel, ecause my ISP forces me to a static ip based on my modem MAC address I was shut down until I could get another modem. This could have been avoided with this.
I also like the DNSBL idea but I see the latency issues as possibly becoming a deterrent if using one single/multiple lists in itself much less if its down. Maybe DALnet could run its own as possibly support others?
Chris White/phreakshow
Sent from my iPhone
On May 24, 2013, at 3:42 PM, Charalampos Pournaris charpour@gmail.com wrote:
I've already implemented such feature for a small network (IPv4 enabled queries only) and works great. It has actually reduced droneruns and proxy disturbance quite significantly.
The way it works is like this: when a new connection is received (and before registering it to the ircd) a new DNSBL query is dispatched to all blacklists defined in the ircd.conf. Depending on the replies and whether they match the replies defined in ircd.conf the user is whether killed with a kill message specified for the particular blacklist or the user registration continues normally.
However, with this approach if X is a timeout specified for a DNSBL, then it might take up to X seconds before the user connection can proceed with registration if the DNSBL is down/there are network issues.
Regards, Harry
On 24/5/2013 10:19 μμ, brandon wrote:
Wow, as the guy who has to deal with most of our bopm bots, I second this idea emphatically!!
brandon@dalnet [irc.dal.net] Routing & Peering Team Lead
On 5/24/13 2:34 PM, Charalampos Pournaris wrote:
Embedded DNSBL query capabilities to the IRCD would be a nice feature.
Regards, Harry
On 24/5/2013 3:27 μμ, Aaron Wiebe wrote:
Hi all,
The bug in 2.0.6 should have been identified in the code review and testing phase - and I feel like we got some egg on our face as a result. I wanted to take a moment to comment on it, and apologize.
The fact that this bug, being fairly big and obvious, got through the process reflects that I've been a bit lax in reviews and testing. I'm personally going to change my review and approval process to try to resolve these issues, through a more formal off-trunk review.
Bahamut as a project is effectively in a maintenance phase, as we don't have anyone working on it as actively as we previously have. We release new versions sporadically, and don't have a roadmap or any "next big thing". This is actually part of the problem - without goals, we have a lot fewer eyes on individual changes, and we're not all driving towards anything.
So with that said, I'd like to put it to the community to discuss what we could put on our roadmap. Little things and big things. Let's brainstorm - what would you like to see in Bahamut? And out of this discussion, maybe we can line up a roadmap for 2.1, 2.2 and maybe even a 3.0.
What would you like to see in Bahamut?
-Aaron
DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
On 5/24/13, Chris White phreaks@gmail.com wrote: [snip]
I also like the DNSBL idea but I see the latency issues as possibly becoming a deterrent if using one single/multiple lists in itself much less if its down. Maybe DALnet could run its own as possibly support others?
How about generalize it to an "external policy deny mechanism"; basically a mechanism for IRCD to connect to a specified IP:PORT, report a connection attempt, and receive an answer in the form of either "OK" / "NOT OK", or a "spam score", combined with a refusal reason, if the client is deemed not OK by the policy service.
When a client connects, the IP address is sent at registration, before reverse DNS lookup begins, to give the policy daemon time to begin preparing its response, possibly a USER line may be sent, during registration, to enable blacklisting based on resolve host, username, or real name fields.
The Yes/No decision occurs at the USER line. This way you probably avoid additional latency, because there is already a delay involved in the reverse DNS lookup that IRCD already performs.
A policy daemon being external to IRCD could implement any desired blacklisting mechanism.
This could be a local database instead of a DNS query, in large environments.
Or a server admin could run a number of policy servers for their IRC network, on separate dedicated hardware.
A policy service like that could also be used as an alternative to the K:Line mechanism and other ways of banning users.
If an IRC network runs their own policy servers, they could have custom code to check a centralized database specific to known abusers of their IRC network and ban reasons, before going out to poll the list of selected RBLs or RBL feeds.
In this manner, providing an "external decision mechanism" adds a lot more flexibility than just including code in IRCD itself for one specific blacklist.
So I see "external decision mechanism", plus maybe some bundled example program to check against a few common blacklists, as providing administrators with the greatest level of flexibility :)
Chris White/phreakshow
-- -JH
On Fri, May 24, 2013 at 7:10 PM, Jimmy Hess mysidia@gmail.com wrote:
How about generalize it to an "external policy deny mechanism"; basically a mechanism for IRCD to connect to a specified IP:PORT, report a connection attempt, and receive an answer in the form of either "OK" / "NOT OK", or a "spam score", combined with a refusal reason, if the client is deemed not OK by the policy service.
[snip]
It's been a few years since I've paid to attention to the lists, or even been on the network, but I think this is generally a good idea.
One could look at the iauth protocol, as used by other ircds (e.g., ircu, ircd (IRCnet), some hybrid implementations, etc.) to see how they've done this, or perhaps even add support for it with any bahamut-specific extensions that may be needed.
-J
This is actually a hot concern from last few years for host Masking (hostserv) which is needed to be work with DALnet and as the years we have passed in past that would be a great change and give the great relief and protection for the normal users as they think/want no one can see their IPS with these changes our user strength would be increase.
Regards, Asif - Jazzzzz Aop - #Help @ DALnet !
On 25-May-2013, at 7:45 AM, "Jason Hill" secrtagnt@gmail.com wrote:
On Fri, May 24, 2013 at 7:10 PM, Jimmy Hess mysidia@gmail.com wrote:
How about generalize it to an "external policy deny mechanism"; basically a mechanism for IRCD to connect to a specified IP:PORT, report a connection attempt, and receive an answer in the form of either "OK" / "NOT OK", or a "spam score", combined with a refusal reason, if the client is deemed not OK by the policy service.
[snip] It's been a few years since I've paid to attention to the lists, or even been on the network, but I think this is generally a good idea. One could look at the iauth protocol, as used by other ircds (e.g., ircu, ircd (IRCnet), some hybrid implementations, etc.) to see how they've done this, or perhaps even add support for it with any bahamut-specific extensions that may be needed. -J _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
_______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
-
Asif Ali Baig -
Chris White -
Jason Hill -
Jimmy Hess