Network Configuration Change: Common IRC Ports Blocked

[DanL@VPSLink]

Our system administrators plan to block the following ports at the network level:

- 6660 - 6669 (inclusive)
- 7000

This change will be effected within the next 24-48 hours.


The decision to block IRC traffic was made after thorough deliberation - our system administrators, management, and support staff determined that the closure of these ports would be the most effective way to ensure the highest quality of service and security for all customers.

IRC processes running under VPS accounts tend to disproportionately consume hardware resource, resulting in diminished performance for other virtual private servers hosted on the same hardware node - for this reason, the use of IRC remains a violation of our Acceptable Use Policy.

We do not plan on blocking any other ports in the future.

Please feel free to post back on this thread with any questions or concerns.

[bfp]

Thanks for posting that info.

It is useful to know the ports involved because some of us have 1 or 2 standard services running on non-standard ports.

Oh, and good riddance to IRC on VPSlink.

[jcsix]

My client was cut off Wednesday so today I filed a support ticket and it was closed with this response:

IRC connections have been explicitly banned in accordance with our Acceptable Use Policy since day one. As many users (such as yourself) have been ignoring this stipulation, a decision was made to actively block connections over the standard IRC ports to enforce this policy.

First of all, I resent the unfounded accusation that I've been knowingly violating the AUP. "Since day one" is not true. The IRC client issue has popped up here [1] [2] [3] before and VPSLink staff stated that IRC clients were not a violation of the AUP. I recall checking the AUP each time the issue came up to familiarize myself with the situation, and the current AUP language explicitly banning IRC clients was never present.

I only became aware today of the change to the AUP, so thanks for assuming the worst of a customer who has been with VPSLink almost "since day one". The conflicting information and vagaries given by VPSLink staff in this thread should be enough of a hint for VPSLink to give its customers the benefit of the doubt on this issue, especially those who've never fallen afoul of the written AUP before (I wasn't aware of some unwritten AUP as apparently alluded to at the end of that thread).

Secondly, is it really's VPSLink's position that too many node resources are consumed by running a lightweight client such as Irssi to connect to a couple of small channels on Freenode? If that's the case, then VPSLink must be overselling resources far beyond what I would consider acceptable.

[DanL@VPSLink]

Originally Posted by jcsix

My client was cut off Wednesday so today I filed a support ticket . . .

The wording of the reply did not accurately reflect our position, and I am sorry that offense was (understandably) taken.

I have taken this opportunity to discuss the ticket in question with our support manager - you were not in the wrong with the use of an IRC client in the past (as you noted, we updated our AUP in February to include clients).

Our support department will be advised to take past practices into account to avoid any future misunderstandings.

Originally Posted by jcsix

. . . is it really's VPSLink's position that too many node resources are consumed by running a lightweight client such as Irssi to connect to a couple of small channels on Freenode? If that's the case, then VPSLink must be overselling resources far beyond what I would consider acceptable.

In all honesty, IRC clients have never been considered a resource issue on our network; they do, however, fall under the blanket issue of security as it pertains to IRC - compromised servers are typically configured with an eggdrop to allow malicious users easy access.

As IRC servers (which are considered resource-intensive applications) and IRC-related services tend to be put toward abusive or malicious use more commonly than legitimate use, we have taken the most direct course of action against them.

I am sorry for that fact this issue has inconvenienced your legitimate use of our service, and it is further inconvenient that you should need to file a support ticket to learn about this initiative.

I would recommend that you subscribe to both our Announcements and System and Network Status subforums, if you have not done so already.

[jasonaward]

Originally Posted by DanL@VPSLink

I would recommend that you subscribe to both our Announcements and System and Network Status subforums, if you have not done so already.

I would recommend sending out emails if / when you make such network changes. It's your responsibility to inform us, the paying customers, when you change something so drastic.

[jcsix]

Thanks for the clarification DanL.

As jasonaward pointed out, VPSLink should email its customers whenever there's an AUP change. Placing the burden on the customer to actively (or semi-actively, by subscribing to blogs/threads) keep abreast of such details just leads to strife for both parties.

I know legitimate IRC clients can be difficult to distinguish from IRC bots that might present a security threat, but a blanket ban on the entire IRC protocol seems heavy-handed to me. An approved client whitelist might be worth investigating, or perhaps a lower level policy-enforcing solution involving SELinux or AppArmor. I'd be surprised if OpenVZ/Xen didn't offer some sort of process lockdown or authentication that could be useful in this case.

My home connection isn't always reliable and I need a persistent client connection for development-related IRC communication. VPSLink provided that (among many other important uses) within my budget, but regrettably this new policy forces me to look for another hosting provider.

[rxKaffee]

Originally Posted by DanL@VPSLink

In all honesty, IRC clients have never been considered a resource issue on our network; they do, however, fall under the blanket issue of security as it pertains to IRC - compromised servers are typically configured with an eggdrop to allow malicious users easy access.

Could outbound connections to Freenode IRC be made an exception here? I use an irssi process on one of my servers to coordinate F/OSS projects that I work on, on that network.

When I decided to give my business to VPSLink, I verified that outbound chat connections would be allowed for this purpose. I forget whether it was a written exception in the AUP, or if I read it from one of the VPSLink employees here on the forum.

Also the presence of VPSLink customers on Freenode would be fairly good advertising I would think. I have referred several associates in the F/OSS field from there.

I see no realistic possibility of Freenode being used for "illegitimate" purposes such as collecting zombied clients for botnets... Freenode even checks client version on connect to ensure that it is not a client who is vulnerable to known exploits.

If this were really an issue of the security and safety of "your" customers, we would not have such meager pickings of IPTables modules. Do we have kernel support avail for SELinux or AppArmor? What about a patch to that 2.6.17-2.6.23 kernel splice vulnerability(Released Feb 10 to kernel source, Feb 12 to openvz-Kernel source, I have uptime of 48 days... you do the math).

Unless living by a Reactive instead of Proactive security approach, it really does not sound like this is a "blanket issue of security" to be blocking _out_ bound ports.

[jcsix]

As a last-resort sort of suggestion, maybe VPSLink could run an authenticated IRC proxy which all hosted IRC clients must go through to reach the outside world. That should give you a handy single point of management for outbound IRC traffic. Since this wouldn't actually be an "open" proxy, Freenode, OFTC, and other networks could probably be persuaded to let it past their proxy scanners.

[FastEddie]

I'm honestly surprised by the number of people that *need* IRC capabilities for their VPS. Are all of you running clients on your VPSs and that's what the rub is? As opposed to running the clients on your home machines?

And the question of proactive vs reactive security, proactive is making changes before something happens, reactive is making changes after something happens. I'm not aware of anything that happened yet, so wouldn't this be a proactive change, contrary to what was said above?

-Ed

[FastEddie]

As far as the notifications go when an AUP changes (or any policy, such as privacy, TOS, etc), who does that today? I'm pretty sure that most policies in this wonderful e-world include the ability of the authors to amend/update/modify at any time, and they instruct you to visit it again to check for those updates. I'm not saying that VPSLink can't or shouldn't email users everytime a change is made to their policies, I just wonder at the end of the day, how many users will consider it unsolicited email, and/or actually ready it.

-Ed