View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003446 | unreal | ircd | public | 2007-07-15 10:12 | 2009-07-24 01:09 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Platform | All | OS | All | OS Version | All |
| Product Version | 4.0-devel | ||||
| Summary | 0003446: Things that really need an overhaul in Unreal4 that Unreal3 does stupidly | ||||
| Description | Write in comments here things in Unreal3 user interface (IRC client), or even config, that's horridly stupid and should be fixed - ideally with a suggestion on how to do it. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| child of | 0003417 | closed | TODO list for Unreal4.0 |
|
|
<AnMaster> the trying to be smart about +b < <AnMaster> like +bb *!foo@*.bar.com *@*.bar.com will not result in same as +bb *@*.bar.com *!foo@*.bar.com < < < <AnMaster> IMO users should handle that, ircd shouldn't try to help supid users <AnMaster> inspircd does it the right way there |
|
|
If you do /gline <nick|mask> <reason> without intervening time, you get an expiry of 0, and the first word of your reason is cut off. << gline test@mask test thing >> :irc.moocows.dk NOTICE aquanight :*** Permanent G:Line added for test@mask on Wed Jul 18 01:04:44 2007 GMT (from [email protected]: thing) Though more properly this is just an unreal3 bug ;) . This likely applies to kline, zline, and gzline too. |
|
|
1:Botmotd should be send with RAW Number 2:ident/realname Ban should be avaiable like /gzline... eg: /iline /gline <ident> eg: /rline /grline <realname> and then change g/k/z/gzline to @host or ip.ip.ip.ip without ident. 3:SVStklexcept should be added 4:extra operflag for /chghost /chgname /chgident 5:setname should be removed (it´s just good for chan ban invasion, and /chg... is enough) 6:excess flood except for Opers 7:extra operflag for spamfilter access 8:tsctl should be avaiable for services admins too 9:complete maskban should be added (either svsakill or config entry) nick!ident@realhost:realname <--Mask (listed at /stats..) 10:operflags should be send to ulines if someone oper´s up 11:ip and realname should be noticed too when some clients connects, eg: *** Notice -- Client connecting on port 6667: nick (ident@realhost:realname) ip.ip.ip.ip [clients] this would make scripters life much easier ;-) 12:new command /saumode (extra Operflag) 13:ulines should not can kick umode +q users(because +q is senceless then, if a services bot can kick the +q) 14:spamfilter exception Mask at config (nick!ident@realhost:realname) 15:at chmode +L #chan should be a scan if there could be a loop, eg: chan1 +L #chan2 chan2 +L #chan1 this could prevent from a loop with channel redirecting 16:specific spamfilter types for chan an nick ctcp 17:better synchronization between 2 servers global spamfilter lists. At my server is a mysterious error. we set a spamfilter which glines all Users who posts an IRC server address. (irc\.[^ ]+\.(com|org|info|eu)) Because some addresses are at Version replys of scripts, we set an other spamfilter, eg "irc.somenet.net". After a netsplit (it doesn´t matter what kind, connection lost, restart..) some users are glined because they posted "irc.somenet.net". We have to remove and to re-set the spamfilter entry before the one with irc.somenet.net does work again. irc.somenet.net is blocked with spamfilter, not glined. some more can follow, i´m collecting my ideas from my notes ;-) |
|
|
"1:Botmotd should be send with RAW Number" Botmotd is not useful IMO, it should simply be dropped. "4:extra operflag for /chghost /chgname /chgident" What do you mean with this? If you mean access to doing these commands, please have a look at how inspircd/u4 oper system works... With the oper system in inspircd/u4 that is already possible. "7:extra operflag for spamfilter access" See my comment on 4. "8:tsctl should be avaiable for services admins too" This would be /alltime command under inspircd/u4, there is afaik no way to manually set the delta under inspircd/u4. "15:at chmode +L #chan should be a scan if there could be a loop, eg:" Afaik inspircd/u4 will not follow +L if it would result in a loop (or even more than one forward, iirc) |
|
|
[quote]3:SVStklexcept should be added[/quote] Insp/u4 has /eline for this. [quote]13:ulines should not can kick umode +q users(because +q is senceless then, if a services bot can kick the +q)[/quote] I've always been of the opinion that a ulined client is higher than even an oper with all assignable privileges. A service should be able to kick a umode +q user. It should be the service's responsibility that it not make +q worthless (ie, check /cs kick, etc to let only service admins(?) kick someone with mode +q, I do believe some services even do this). |
|
|
one more issue: User, connecting with IP 123.123.123.123 realhost abc.de gline on *@abc.de User reconnects with IP as realhost -> GLine gots no effect There should be a dns Check for this IP to which host it belongs to, and this result should be checked if a g/kline is set on the Host. |
|
|
The way you phrase it is both stupid and impossible. However, it _may_ be possible for a gline to store the IP that it maps to alongside the host, IFF (not a typo) it has a corresponding IP. To be clear, if they connect with an IP as their realhost, then it means that when the server attempted to resolve the IP it FAILED. Attempting again might work, but would only slow down connecting. For everyone. |
|
|
What if the gline is like *@*.some.isp.net then there is not a single corresponding IP. |
|
|
Thank you, Mr I Didn't Read. IFF: If and only If. |
|
|
1. Then bots won't know that it's a MotD. 2. Ident ban = /gline ident@* Realname ban = /svsnline. Moving that function from svs commands to oper commands could be a good idea. 5. Using /chg* on yourself instead of /set* would make the ircd have three less commands, which could be a good thing - means less stuff to remember. That might be outweighed by having to get out of the habit of using /set* 6. I dunno about U4, but in U3 you can set an oper's class in their oper block. If U4 doesn't do this, it should. 9. That sounds good to me, make /gline use the same nick!user@host:realname as spamfilter -u 10. Why? 11. Yeah, would be good to have host, IP and realname in connection server notices. 12. Why do you want people lower than services root to change other's usermodes? 16. CTCP is PRIVMSG with some characters in the right place, so a seperate target for it isn't really needed. And you want spamfilters that look at messages to catch CTCPs, otherwise you'd need to set two of the same spamfilter, ctcp and privmsg. |
|
|
Tabrisnet, here is an example with mIRC. mIRC gots the /dns ip|host command. If you put in a host it returns the IP If you put in an IP it returns the Host to the IP Szenario: gline on *@*.abc.de at mIRC at connecting: /dns 123.123.123.123 returns e.g. *@123hgdhh.abc.de I want this check for gLines and kLines, so if the IP of an User is resolved to an host, the resolved host has to be checked for matching g/klines This Check would make such things like 1. connect realhost, 2. connect IP as realhost impossible. |
|
|
WHAT THE FUCK are you smoking? Did you actually fucking read what I said? Of course you didn't, you BLEEDING MORON. Let's explain it slowly in small words. peer connects to local, IP:port -> IP:port, not that the peer knows what IP/address the peer is yet. local calls accept() and obtains an fd local calls getpeername(fd), stores it in peerAddr local checks the IP against the zline list. local calls gethostbyaddr(peerAddr), stores it in peerHostname local checks peerAddr and peerHostname against the gline list. Sometimes gethostbyaddr will fail to resolve a DNS name, despite the fact that one exists. Usually means there's a DNS server down or just being slow. Checking again may or may not resolve the issue. It will however slow down the connection process, and it takes bloody long enough when the DNS server doesn't respond very quickly. |
|
|
I'll reiterate what one of the other discussion bugs says: this is a technical forum and not a flamefest. Seraph: tabrisnet is right - if you want to ban on the specific IP, you ban the specific IP. If you want to ban on a possible dynamic host, you ban the hostname. People can get through still, but you can fix the issue in most case by .. banning the ip. |
|
|
1 more thing: kill on ip /kill <ip> Cu At the moment it just works with the nick, the IP should get the same effect. |
|
|
sounds like OS MASSKILL (which is actually an alias for OS CLONES KILL), something I implemented in SrSv. Can match on a hostname ( except hostnames w/o dots -.- ), an IPv4 IP, or a username. |
|
|
tabrisnet, i´ve recognized it today again, a turk botnet floods again our network, the ircd wasn´t able to resolve the hostname of the bots, so the glines got no effects, but my mircbot always can resolve the hostname a few seconds later in less than a second. so something seems to be wrong at dns resolving from ircd. |
|
|
Seraph, I hope you didn't forget /gzline |
|
|
no phoenix, we´ve got many gzlines on turkish IP Ranges, but they doesn´t catch all of them. Thats why my bot resolves the hostname and compares it to his ban lists. I just think its stupid that unrealircd is not able to resolve the hostname like mirc and to compare the resolved hostnames with gline/kline lists. |
|
|
Wouldn't that be an issue with your hosting, since Unreal takes its DNS resolving information from the configuration of the system it is running on? |
|
|
unreal can resolve all other hostnames without problems, just these botnet bots are exceptions, unreal can´t resolve any hostname of them, but my bot can do it btw, one more point there should be added an usermode, which hides the oper from whois, so if someone whoisses the oper and the "whoisser" is a non oper there should be the response "no such nick/channel" if this usermode is set. This would be good for Network security Services, so that no normal user can spy out the services who are online to use bugs of them. |
|
|
Hmm...if that usermode gets made, make it uline-only. |
|
|
i thought as usermode for opers for hiding eg BOPM, Defender, Floodworld etc and for setheral normal Bots without ulined server. May it can be an oper flag. I just request these usermode, because no normal user should be able to whois/see security services at any way. +i prevents from /who list +H hides irc op status +p hides Channels +w should hide at /whois command from non-oper So there isn´t any way to find out what security services currently running on the network. |
|
|
Maybe make +S do that? |
|
|
Uhhh. No. +S is used by ChanServ and such. |
|
|
+S is just a marking flag as network services, nothing more. |
|
|
Ok, firstly unreal has had the general policy that security through obscurity is not security at all. Hiding from /whois isn't going to save your bot from getting hacked. If someone knows the service and sees the nick from some other source (eg, things it does), then it's going to get hacked whether it's hidden or not from /whois. Second, this hide from whois thing is not "something that needs an overhaul that unreal3 does stupidly". It's a feature request, and so should get its own bug report. |
|
|
seraph: I am not saying it does not happen, but rather that you do not understand the problem. It is thoroughly possible for an IP to be resolvable from one location and not another, depending on routing problems, traffic filtering, and localized caching effects. Meanwhile, if it consistently does not resolve, likely nothing will make it magically resolve by trying longer. Further, the ircd is already making a good-faith effort. If you want it to try more... adjust set::dns::timeout and set::dns::retries. Feel free to crank it up, and then find out how many users ping timeout b/c they don't finish connecting fast enough. |
|
|
Let's fix the way unreal handles hosts it cant resolve when the user uses mode +x The whole *.*.*.IP thing makes me feel like it's a proxy of some sort, and when the IRCd fails to get someone's hostname before it hashes the ip/host, this can allow the user to evade some bans set on his/her hashed hostname. I'm personally uncomfortable with the *.*.*.IP mask but, that aside... We can still use the *.*.*.IP but have unreal attempt to resolve the user's host AFTER they connect and change to the proper hostname afterwards. We dont want to hold people up during connect so why not code something that will retry a DNS look up after the user connects and run a /chghost <hostname> when it finally gets a hostname from the DNS server. This may mean having to rehash the user's IP so a simple resetting of mode x might do the trick. Though it might be a bit sloppy to code. This might extend the IRCd's 'good faith' effort a bit and would be useful because even if they got connected and joined somewhere they were banned from, or even connected and were g/k/z:lined they'd be killed/silenced because they're banned. Opinions? |
|
|
Pachy, there's a couple reasons why we don't resolve hosts after allowing a connect, and they're probably the same reasons why all other IRCds do the same: 1) It'll cause client desyncs when the host is changed. You'd need to force a quit/rejoin to update the lists. Users already don't like to see massive parts/quits/joins in their channels, this would only double it for each person who joins channels on connect. 2) I think everyone would prefer to have their users delayed a couple seconds when they connect rather than the possibility of having those extra seconds to continue to cause harm to the network which they were banned for. For example, you have someone who manages to take over a bunch of computers in a specific RoadRunner subnet, then uses those to flood the hell out of your network. Your DNS server is 2 seconds slow, and you gline *@*.sc.res.rr.com to stop them. Because your server is 2 seconds slow, any flooder that has not been cached will have 2 seconds to continue flooding! That's can create HUGE problems if the flood is strong enough or has enough clients not immediately affected by that gline. A simple solution to a slow DNS server is to change which one you're going through, or change the values in the set block for DNS and Ident (which is another thing that hangs up connects) As far as resolving hosts, there are many cloaking modules out there that offer an alternative IP cloaking method. We've always used the big ugly *.IP thing because it provides plenty of information without providing anything about the IP. If you take a close look at it, each section of the cloak is a different part of the IP. This gives people the ability to ban full subnets to keep evaders out while still providing 100% security against IP guessing. |
|
|
Ah, thank you for clarifying that Stealth. Though I am concerned about people complaining about a few extra seconds to connect. I personally think the IRCd should definitely put more priority in resolving a hostname, I understand the power of a Z:line but if you're banning based upon a /whowas entry and the user had mode +x, which sadly does NOT display an IP, It definitely should show an IP to an oper. That's probably easily fixed though isnt it? |
|
|
/whowas always displays the real host or IP to an oper, +x or not. EDIT: See here for other ways to get the real IP of a user: http://www.x-tab.org/unreal.html#getrealip |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-07-15 10:12 |
|
New Issue | |
| 2007-07-15 10:12 |
|
Status | new => feedback |
| 2007-07-15 10:13 |
|
Relationship added | child of 0003417 |
| 2007-07-15 10:47 | AnMaster | Note Added: 0014496 | |
| 2007-07-17 20:06 | aquanight | Note Added: 0014516 | |
| 2007-07-19 08:08 | seraph | Note Added: 0014525 | |
| 2007-07-19 08:10 | seraph | Note Edited: 0014525 | |
| 2007-07-19 08:18 | seraph | Note Edited: 0014525 | |
| 2007-07-19 08:20 | seraph | Note Edited: 0014525 | |
| 2007-07-19 08:22 | seraph | Note Edited: 0014525 | |
| 2007-07-19 09:50 | seraph | Note Edited: 0014525 | |
| 2007-07-20 10:24 | AnMaster | Note Added: 0014536 | |
| 2007-07-20 10:57 | aquanight | Note Added: 0014537 | |
| 2007-07-23 09:34 |
|
QA | => Not touched yet by developer |
| 2007-07-23 09:34 |
|
U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2007-07-23 09:34 |
|
U4: Upstream notification of bug | => Not decided |
| 2007-07-23 09:34 |
|
U4: Contributor working on this | => None |
| 2007-07-23 09:34 |
|
Severity | minor => feature |
| 2007-07-23 09:34 |
|
Status | feedback => confirmed |
| 2007-08-05 10:49 | seraph | Note Added: 0014678 | |
| 2007-08-05 13:06 | tabrisnet | Note Added: 0014681 | |
| 2007-08-05 14:46 | AnMaster | Note Added: 0014682 | |
| 2007-08-05 14:50 | tabrisnet | Note Added: 0014683 | |
| 2007-08-05 21:54 | Shining Phoenix | Note Added: 0014684 | |
| 2007-08-06 09:51 | seraph | Note Added: 0014685 | |
| 2007-08-06 10:05 | tabrisnet | Note Added: 0014686 | |
| 2007-08-06 10:07 |
|
Note Added: 0014687 | |
| 2007-08-07 13:01 | seraph | Note Added: 0014695 | |
| 2007-08-07 13:25 | tabrisnet | Note Added: 0014696 | |
| 2007-09-11 11:53 | seraph | Note Added: 0014771 | |
| 2007-09-12 00:58 | Shining Phoenix | Note Added: 0014772 | |
| 2007-09-12 13:34 | seraph | Note Added: 0014773 | |
| 2007-09-15 08:59 | Namegduf Live | Note Added: 0014774 | |
| 2007-09-18 10:17 | seraph | Note Added: 0014783 | |
| 2007-09-18 13:20 | seraph | Note Edited: 0014783 | |
| 2007-09-19 00:34 | Shining Phoenix | Note Added: 0014786 | |
| 2007-09-21 13:33 | seraph | Note Added: 0014791 | |
| 2007-09-24 05:32 | Shining Phoenix | Note Added: 0014797 | |
| 2007-09-24 10:33 | tabrisnet | Note Added: 0014798 | |
| 2007-09-24 10:53 | seraph | Note Added: 0014799 | |
| 2007-09-25 22:31 | aquanight | Note Added: 0014803 | |
| 2007-09-25 22:32 | aquanight | Note Edited: 0014803 | |
| 2007-09-26 01:39 | tabrisnet | Note Added: 0014804 | |
| 2008-07-13 12:46 | Pachy | Note Added: 0015318 | |
| 2008-07-13 12:46 | Pachy | Note Edited: 0015318 | |
| 2008-07-13 12:48 | Pachy | Note Edited: 0015318 | |
| 2008-07-13 12:51 | Pachy | Note Edited: 0015318 | |
| 2008-07-13 16:48 | Stealth | Note Added: 0015320 | |
| 2008-07-13 17:44 | Pachy | Note Added: 0015321 | |
| 2008-07-13 17:49 | Stealth | Note Added: 0015322 | |
| 2008-07-13 17:50 | Stealth | Note Edited: 0015322 | |
| 2009-07-24 01:09 | Stealth | Status | confirmed => closed |
