Okay, so squeeks wants a frontend to handle the file that deals with banned IPs for 4-ch. The way the file works right now is that apache reads in a list of IP addresses in a file, one per line, with comments afterward, i.e.:
127.0.0.1 #for spamming
The frontend would need to provide an interface for adding/reading the IPs, and making sure the file is formatted correctly (no blank lines, etc.)
BUT:
There needs to be some way to obfuscate the IP addresses so that, even though they're listed correctly within the file, the interface shows something else, a la tripcodes. That way the moderators/administration never see anyone's IP addresses, they just see unique strings by which they can identify the posters. The difference here, of course, is that the process has to be reversable so that the frontend can switch between writing actual IPs and displaying the obfuscated string to the moderators.
anyway, DISCUSS.
I'll go on a bit further from where >>1 missed off.
Apache currently uses a rewrite map and some rewrite rules to take care of banning. The layout is different to what >>1 actually said, it's <IP> - # <reason> (note the dash in there). The script must also be able to take HTTP GET vars, most importantly being able to ban IP's by feeding it an obfuscated IP address (for example, "script.pl?ban=<obfuscation>" could be requested. The ability to edit and remove bans also needs to be done and avoiding empty lines.
This code can be created in either PHP 4.3, or Perl 5.8 however the sum used to obfuscate the IP's must be able to be transplanted/converted over into Perl with ease. Don't let that stop you PHP people, Perl is quite good with maths and handling things like md5/sha1 etc. Might be an idea to write out the said maths into pseudo-code or something. Finally, please avoid SQL. There is no point to using it here.
Maybe the mods might complain about all this, but users having anonymity comes towards the top of priorities.
again, how do you plan to deal with dynamic IPs?
>>3
I'm guessing in a situation like this, you don't. Banning IP blocks has its pros and cons anyway, right? I assume certain sacrifices have to be made for the sake of anonymity. It might be possible to impliment something advanced like having the script or the 4-ch script tell you when a certain IP is within range of another, but that sounds like it would be more trouble than it's worth.
What I don't understand is, and this is probably just me being ignorant, how one could create an obfuscation method like this without it being extremely easy to thwart. That is, assuming that the code (and thus the method itself) would be open, since this is going to be written by someone in the community. As long as the method is open and reversable, even something like a secret string hardcoded into the method would be easy to discover given just one IP/ID pair. Right?
> having the script or the 4-ch script tell you when a certain IP is within range of another, but that sounds like it would be more trouble than it's worth.
Easier solution, make the algorithm create similar results for similar IP's. So if the only difference between two IP's is 1 number, then all but one part of the encrypted version should change. Don't get too carried away with making this ultra-secure, a small execution time would be really nice and it doesn't have to be more complex than it has to.
I guess I just don't see the point in the whole thing if it's not secure. It just seems like an empty gesture to me. But I guess it's better than nothing.
Anyway, if that's the case, then just xoring the IP address against some other string and returning the resultant number would produce that effect, of making similar IPs look similar, and it would be quite fast... but it wouldn't really do anything except look different. Ah well, my knowledge of this sort of thing is pretty limited so who knows.
I think admins should be able to see IPs.
This would be, as of now, just one person, but to stop big floods from a certain range of IPs it would be kind of neccessary. Otherwise you'd have to block IP by IP in single steps.
Well yeah I can see them anyway. This isn't really for me, it's for the mods.
> make the algorithm create similar results for similar IP's
related topic: http://wakaba.c3.cx/sup/kareha.pl/1111427295
The stuff described in >>9 is actually already implemented in the latest wakautils.pl files. It's not in the one that comes with Kareha (yet), but in the wakautils.pl file that comes with the notes script, there are two functions, named mask_ip($ip,$key) and unmask_ip($masked_ip,$key) that encode and decode IP addresses in a form that makes similar IPs similar, but don't reveal any information beyond that. If you know the key used to encrypt, you can decrypt the ID code, though.
Perhaps it could be done so that each digit in an IP address is converted to a letter, so 123.231.98.87 would become xrq.rqx.yg.ge or something similar. If the swap key (1=x, 2=r, etc) isn't shared, then people won't have fun decoding the IP (though it would certainly still be possible). Perhaps the key could even be changed every week or so. However, it would be fast to implement code-wise, and it would allow people to see whether IPs are similar. My two cents.
Besides being utterly trivial to break, decimal numbers are not a good representation of IP numbers for this purpose, since subnets are split up on bit boundaries.
>>9 should be as secure as this can get, and also doesn't rely on decimal numbers.
Also, as mentioned in the thread, the first suggestion sucks. The one to pay attention to is http://wakaba.c3.cx/sup/kareha.pl/1111427295/19
I do not see any problems with >>13 with a little study, but nothing extensive. My only suggestion (while not really about the algorithim but more of implementation) is to use different secerts/salts/whatever in different places, to avoid a all of your eggs in one basket situation.
>What I don't understand is, and this is probably just me being >ignorant, how one could create an obfuscation method like this >without it being extremely easy to thwart. That is, assuming >that the code (and thus the method itself) would be open, >since this is going to be written by someone in the community. >As long as the method is open and reversable, even something >like a secret string hardcoded into the method would be easy >to discover given just one IP/ID pair. Right?
For a badly designed method, yes it would be easy to break... but this is a fundamental problem of encryption so people have gotten pretty good at making them resistant to attacks, either by requiring lots of computation or lots of {plaintexts,ciphertexts,whatever}. The only thing that makes this more complicated is the requirement that similar things look the same
While this might be obvious, a change in the ban interface could also allow the method to not be reversible, if that is so desired. (e.g. if magic(ip) matches anything in the list banned) and while this might not be desired for a myriad of reasons I just thought it should be mentioned.
The problem with encrypting IPs is that it's feasible to use brute force. Thus, even a non reversible hash algorithm would not be secure (as long as there are no collisions, which would make it kinda useless for the purpose of banning people), for one could easily hash all 2^32 IPs and then simply look up the ones to be "decrypted".
Only if you were dumb enough not to salt the hash with a secret value. Needless to say, all ID codes generated on these boards are salted.
>>15, >>16 is right the only people that can bruteforce the ips is those that know SECRET
For example, say that SECRET is a 10 character string with the set [0-9A-Za-z!@#$%^&*()-=_+,./?><:;'"[]{}`~] so 93 possible characters (it could easily be 255).
You look at your own ip, masked so and it is computed from K(ip + SECRET) so you know part of it. Now lets try every possibility for a 10 character secret, that is only 48,398,230,717,929,318,249 possible combinations, lets be generous and assume you can compute K 1,000,000 times a second. To try every possiblity it will take ~15,346,978 years to figure out SECRET* and thus be able to brute force all IPs. As you can see even if you had a million computers all trying to break it, it would still take over 15 years to break. It doesn't get any easier as you add more length to SECRET.
*I know that this is the time for an exhaustive search, and you will probably hit it before then.
Who's going to code it?
Supposedly hotaru.
I wish development on Kareha could be synchronized with WAHa, though.
I'll accept patches and add-ons... I could add a mode_4ch for the templates, too, I suppose.
use sha1 or sha256 + a key to hash the IPs.