View Issue Details

IDProjectCategoryView StatusLast Update
0003726unrealircdpublic2013-05-20 04:06
ReporterkdevcfAssigned Tonenolod 
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
PlatformOSLinux, WindowsFreeBsd, OS VersionALL
Product Version 
Target VersionFixed in Version3.4-alpha1 
Summary0003726: Custom cloak module
DescriptionI've been using the unreal software where for quite sometime, and i've been thinking, Seeing as Unreal is still in development and alot of people are using this that they should have an option to customize there host masking
which presently looks something like
rox-510E1CEB.ip.secureserver.net, of course rox being changeable.

perhaps a more customizeable host mask would appea=l, purely an option to users tho for example CustomeMasking "Customizeable variables"

For example
"1" - Default, Old method of hidden host masks "rox-702039293.ip.ip.ip"
"2" - New Style Perhaps a secure md5 table
"rox-742929dcb631403d7c1c1efad2ca2700.secure <or something customizeable aswell"

Of course have a var aviaible for the secure version (md5) table of there ip so u can do instead of "1"-"2" you can do
"w/e-u-want-here.%secureip.-w/e-message here"

I think alot of users are wanting modules for this, you should have it built in as an option.
TagsNo tags attached.
3rd party modules

Relationships

child of 0004188 closed Unreal 3.4 alpha1 blockers 

Activities

nate

2008-08-28 05:45

reporter   ~0015389

A change to the cloaking engine/algorithm was planned for 3.3 actually anyways, though I do like the idea of perhaps making it a bit more controllable for the users side, at least on maybe how much will be cloaked, etc.

Say we take hostmask pool-71-200-80-210.pitbpa.east.verizon.net

Generally we would cloak the portion before the pitbpa.east.verizon.net, for hostmasks this could be controllable to maybe even go as much as down to the ISP level itself (eg; $cloak.verizon.net)

Same would potentially go for IP's, as I was trying to implement something similar for that as well (right now we basically cloak the whole IP, where as now it could be $cloaked.80.210), where the 'depth' of it can be controlled.

kdevcf

2008-08-28 10:01

reporter   ~0015390

The whole idea is that the users personal experience is met, i mean do you agree that if everyone followed the exact same pattern it would be quite useless to even have multiple networks. Personally i'd even like to host testing servers for Unreal's development. I own my own dedicated server.

nate

2008-08-28 12:52

reporter   ~0015391

As do I, but 3.3 is far from even alpha testing yet. When it comes to that point people will be made aware :P

And no, the 'exact same pattern' doesn't make it useless to have multiple networks, not over something as silly as a cloak mask, considering even for other IRCd softwares that implement a cloaking system, its generally the same regardless as well.

kdevcf

2008-08-28 13:06

reporter   ~0015392

Last edited: 2008-08-28 13:10

True enough, i didnt mean it the way i said it, what i mean is because of the IRC world changing contantly, i find it more and more useful for little extra abilitys.

katsklaw

2013-01-13 20:31

reporter   ~0017352

IMVHO, cloaking should also be made optional. Some admins feel hiding a users IP makes the users server an attack target and if the users IP is exposed, it makes them a more cautious user as they know they are not hidden. This should be an option other than forcing -x and then restricting it. That's just sloppy and doesn't affect opers. Several more modern IRCds (think codebase) already have this ability.

As far as popularity goes, many of the big 10 nets do not and have never hidden users IP's and while this has run off some users, it has not been a deciding factor for many users migration and still more than 15-20% of IRC users are on nets that expose their IP.

That said, I too like the idea of having some options and some of those options should also include a more realistic looking hashed host.

nenolod

2013-01-14 08:44

reporter   ~0017356

+1 katsklaw, I am already working on cleaning things up where the cloaking stuff can run without efunctions.

repton77

2013-02-11 18:27

reporter   ~0017412

Last edited: 2013-02-11 18:29

View 2 revisions

Well I thought I'd give my 2 cents, so here goes:

Personally I think it would be good to have another set { } option for cloaking for example:

cloakmethod "ipv3/default" = the default, eg. 194103A0.C35941FD.4DCA40A2.IP
cloakmethod "ipv4" = eg. 194103A0.C35941FD.4DCA40A2.6282022
cloakmethod "host1" = eg. cloak-E9BC4314.whatever.cable.ispname.net
cloakmethod "host2" = eg. cloak-E9BC4314.cable.ispname.net
cloakmethod "network" = eg. users.networkname.net

I think this would be a good way to do it, then on ipv4 it would check the "cloak keys" to check if there is 4 different keys, or maybe just revert to key1 if key4 didnt exist?

thanks.

nenolod

2013-05-20 04:06

reporter   ~0017614

http://hg.unrealircd.org/hg/unreal/rev/e5f805cda93a

Issue History

Date Modified Username Field Change
2008-08-28 04:30 kdevcf New Issue
2008-08-28 05:45 nate Note Added: 0015389
2008-08-28 05:45 nate Assigned To => nate
2008-08-28 05:45 nate Status new => assigned
2008-08-28 10:01 kdevcf Note Added: 0015390
2008-08-28 12:52 nate Note Added: 0015391
2008-08-28 13:06 kdevcf Note Added: 0015392
2008-08-28 13:10 kdevcf Note Edited: 0015392
2013-01-09 09:55 syzop Assigned To nate =>
2013-01-09 09:55 syzop Status assigned => feedback
2013-01-09 09:55 syzop Product Version 4.0-devel =>
2013-01-09 09:55 syzop Summary The ability to customize host masking. => Custom cloak module
2013-01-13 20:31 katsklaw Note Added: 0017352
2013-01-14 08:44 nenolod Note Added: 0017356
2013-02-11 18:27 repton77 Note Added: 0017412
2013-02-11 18:29 repton77 Note Edited: 0017412 View Revisions
2013-02-12 06:49 dummy Status feedback => has patch
2013-02-19 22:55 syzop Status has patch => feedback
2013-05-20 03:50 nenolod Relationship added child of 0004188
2013-05-20 04:06 nenolod Note Added: 0017614
2013-05-20 04:06 nenolod Status feedback => resolved
2013-05-20 04:06 nenolod Fixed in Version => 3.4-alpha1
2013-05-20 04:06 nenolod Resolution open => fixed
2013-05-20 04:06 nenolod Assigned To => nenolod