Restricting DCCs depending on IP/host

Mike · Post by **Mike** » Sat Sep 17, 2005 12:38 am

There I go again with another problem

I'd like to restrict the usage of DCC depending on the IP/hostmask of the users involved (sending and receiving). Background info: I am running an ircd on a private network, but the server is also visible from outside, so I'd like to allow DCC for internal users on the private network and prohibit it for outside users (you should be able to come up with reasons for that

)

There seems to be no chance for achieving that with standard Unreal configuration. The closest match for a module I could find is the 'noctcp' module, providing a usermode +M to prevent the user from receiving DCC. This is in and for itself a good idea, but doesn't help me out, since I see no way to tell the ircd to assign different umodes to different users when connecting (according to classes, or whatever).

Does someone know how we can achieve that? How about adding simple clauses like 'from-host' and 'to-host' in the 'deny dcc' and 'allow dcc' blocks (implied feature request

)?

Thanks for any hints,

Mike

aquanight · Post by **aquanight** » Mon Sep 19, 2005 3:14 pm

Unfortunately restricting DCC is really not very useful. Why? They can go to a different server and do their DCC there. Plus, a DCC session is completely seperate from the IRC server. And if you're trying to keep things like warez bots off your network, well there are better ways to do that ;) .

Post by **Syzop** » Mon Sep 19, 2005 3:20 pm

These are features that I think of like "Sounds like a good idea, but it will probably end up on the heap of feature requests that won't be done for another year" :/. (patches are welcome though)

aqua: I'm assuming he means that on the private network users can only connect to this particular chat server (eg: on 192.168.0.1), so then it makes sense.

Mike · Post by **Mike** » Mon Sep 19, 2005 10:47 pm

aquanight wrote:Unfortunately restricting DCC is really not very useful. Why? They can go to a different server and do their DCC there.

So what? I don't want to (nor can I, as an IRC admin) stop people from doing DCC at all. I just don't want (all of) them doing it on my server. Preventing people from doing DCC is the job of the netadmin, who sits at the external router.

aquanight wrote:Plus, a DCC session is completely seperate from the IRC server.

I know, so that's why I don't want to turn off DCC completely. The traffic is not a problem, as long as it stays whithin the private network. (And by the way, it's a quite large one, like 10.148.0.0/14, so there are potentially a lot of people affected by that.) External traffic is counted and people get banned if they download/upload too much (don't blame me, I'm not the network admin

), so that's why I want to restrict internal-to-external DCCs.

Sure they can still do DCC on other IRC servers and get the same problem, but I can't crowl to everybody's box and tell them what to do. I just want to do my best to prevent that on the server that's under my control.

aquanight wrote:And if you're trying to keep things like warez bots off your network, well there are better ways to do that .

That's the point: as long as they don't go outside, I got no problem with that...

Syzop wrote:These are features that I think of like "Sounds like a good idea, but it will probably end up on the heap of feature requests that won't be done for another year" :/. (patches are welcome though)

These are replies that I think of like "Sounds like I'm gonna have to take a closer look at the module API, or just make 'deny dcc { filename *; soft no; };' if I don't have the time..."

SCNR

Mike

Matridom · Post by **Matridom** » Mon Sep 19, 2005 11:31 pm

why not setup two linked servers.

set one (blocking all DCC) that the external people connect to.
set one (allowing all DCC) that the internal people connect to

link the two servers.

that *should* do the trick

Mike · Post by **Mike** » Tue Sep 20, 2005 12:11 am

Matridom wrote:why not setup two linked servers.

set one (blocking all DCC) that the external people connect to.
set one (allowing all DCC) that the internal people connect to

Hm, that could work

(Luckily, the box has separate IPs for internal and external connections, so we can put both ircd's on the same ports. Otherwise they would have to use different ports, and go tell half of the users they must connect to port 6668 when all clients default to 6667...)

Acutally I haven't thought about that, but if 'deny dcc's are not the same on all servers on a network, then it could become a big mess, I think. Every server with 'deny dcc { filename *; };' will be blocking all DCCs that pass through it. For 2 servers the result is obvious, but if you have like 10 servers, then you get a different result depending on how your servers are linked (network topology). And if that changes (which is rare but can happen) your network becomes pretty non-deterministic

Anyways, thanks for the tip, I'll check it out.

Mike

aquanight · Post by **aquanight** » Tue Sep 20, 2005 7:00 am

I *think* deny dcc is only checked locally (iow only the originator's server checks).

Post by **Syzop** » Tue Sep 20, 2005 4:21 pm

Though (seeing nobody gave such a warning yet ;p), if people in your private thing wanted to evade it, they could simply make something else up, such as hexeditting 'DCC' to 'EDD' or something and use that, or implement something on their own.

Or they could just as easily upload something on the web and paste urls for downloading.

[insert 233523 variants here]