Google Talk is moving away from XMPP in the near future, towards the proprietary Google Hangouts feature from Google+. As of right now, I can still connect to it with bitlbee, and can talk to non-Google XMPP users with it, but I wouldn't recommend building anything new around Google services. (For the same reason, I wouldn't recommend building anything around Twitter or Facebook, either.)

_________________

/* TODO: need to add signature to posts */

The vast majority of people out there don't have Jabber clients installed, and asking the users of a website to install software on their computer to use your website should hopefully raise a big red flag to the typical user. It depends on the target audience of the website. Is it techies? Then such a thing might be feasible. Is it your average person? Requiring software installations is a bad idea.

I think I might just use a Mibbit IRC web based iframe in a webpage like irc.sturmkrieg.com. Or the simple IRC that was recommended. I like the idea of a web based client though.

_________________
Homepage www.sturmkrieg.com
Social network Gamernet
Development website Sashaweb Development
Imageboard img.sturmkrieg.com
WikiHub free wiki host Community Wiki

Could you please quickly go through some of the important setup for it? Just stuff like the directory to extract it in, port it uses, unblocking the port in the firewall, that sort of thing.

I found this guide, which looks useful.
http://www.techrepublic.com/article/run ... th-ngircd/

_________________
Homepage www.sturmkrieg.com
Social network Gamernet
Development website Sashaweb Development
Imageboard img.sturmkrieg.com
WikiHub free wiki host Community Wiki

You don't need to "extract" anything, your distro's package manager (e.g. apt-get, yum, ...) should do that when you go to install it.

It uses 6667 by default (very common for IRC), but that can be changed in the configuration file. You should definitely go through that file before starting ngircd. It contains a lot of comments explaining each option, so it should be easy for most people to figure out. It should be either /etc/ngircd.conf or /etc/ngircd/ngircd.conf.

_________________
Kris the Piki Geeker

Thanks. I used apt-get. Do you know what I should add to open the port on the firewall? I used this guide for making it: https://library.linode.com/securing-you ... a-firewall I could probably figure it out but I don't want to do it wrong.

_________________
Homepage www.sturmkrieg.com
Social network Gamernet
Development website Sashaweb Development
Imageboard img.sturmkrieg.com
WikiHub free wiki host Community Wiki

iptables is fairly easy to use once you know the basic syntax:

iptables -A INPUT -p tcp --dport 6667 -j ACCEPT

• -A should specify INPUT or OUTPUT (FORWARD is mostly for routers).
• -p should be (usually) tcp or udp. If I remember right, IRC uses tcp.
• --dport stands for "destination port", in this case the destination of the traffic of people connecting to your server.
• -j should be followed by either ACCEPT or DROP.

The part to keep track of is whether you should use --dport or --sport (source port), e.g. using the above example to allow port 80: you'd use --dport to allow people to access your web site, while you'd use --sport to allow yourself to access outside web sites.

Another useful thing to add, right before "-j ACCEPT":

• -m state --state ESTABLISHED,RELATED

This is usually most useful only for specifying INPUT without any ports/protocols -- something that guide already does. (though if you wish to be ultra-paranoid like me, you can set it to drop everything on OUTPUT, set the ESTABLISHED,RELATED rule for OUTPUT, then set individual rules in both directions)

After you make your changes, verify they've taken effect, then save them:

iptables -L
iptables-save > /etc/iptables.firewall.rules

Note: iptables requires that you either log in as root, or that you use sudo.

_________________
Kris the Piki Geeker

Thanks. So would the code with the additional element be?

iptables -A INPUT -p tcp --dport 6667 -m state --state ESTABLISHED,RELATED -j ACCEPT

_________________
Homepage www.sturmkrieg.com
Social network Gamernet
Development website Sashaweb Development
Imageboard img.sturmkrieg.com
WikiHub free wiki host Community Wiki

Using connection states isn't absolutely necessary if you're just aiming to allow access to a specific port on your server, the rule will work with or without it, so you can omit '-m state --state ESTABLISHED,RELATED' if you wish or move it to its own rule in the chain. Up to you.

That effectively blocks any connection which isn't already established when you set that rule, meaning new connections can't come in. The "-m state --state ESTABLISHED,RELATED" bit should be use with --sport for INPUT, or --dport for OUTPUT, otherwise the connection better already be established and maintained.

Alternatively, you could keep the stat and use NEW,ESTABLISHED,RELATED , however it's easier just to exclude them.

_________________
Kris the Piki Geeker

You could also just avoid running a firewall. If you're running a website and an IRC server, there really isn't a reason for a firewall.

-Tim

_________________
'If debugging is the process of removing bugs, then programming must be the process of putting them in.' //Edsger Dijkstra
'Nothing is withheld from us which we have conceived to do.' | 'Do things that have never been done.' //Russell Kirsch

I can think of many reasons to run one: SQL server intended to run on localhost only, VPN or otherwise networking with insecure hosts, DDoS mitigation, limit access to trusted IP addresses, reduce log spam, lock yourself out of your own server, ..............

_________________
Kris the Piki Geeker

If you standardize your configuration methods and be sure to triple check, you should avoid having a SQL server listening on the wrong port. Even so, it's trivial to write a small script to make sure you only have important services listening on the public network.

DDoS mitigation? If someone is attacking your system and causing congestion upstream, your software firewall isn't going to do anything.

And yes, firewalls can be used to limit access to trusted IP address. But simply blocking all ports (except the ones you have services on) isn't really beneficial to security. Those services that are listening are still listening...

_________________
'If debugging is the process of removing bugs, then programming must be the process of putting them in.' //Edsger Dijkstra
'Nothing is withheld from us which we have conceived to do.' | 'Do things that have never been done.' //Russell Kirsch

Sure, but what about keeping it blocked from the public? Sure, there's good chance the SQL server will allow this, but no garuntee...



Depends on where the congestion occurs. On the routers at Linode's datacenters? Nothing I can do about that. At my specific Linode? Firewall can help (though I realize it's not a sure thing).



It's more an issue of blocking ports for service daemons that don't let you listen only on localhost. Sure, it's better to not run any such service daemons, however in the (extremely) unlikely case I'd require such a service, I'd rather just be prepared.

There may also be instances where people want to allow stuff only on their internal network (e.g. to utilize XMPP internally for a business), however it's unlikely a Linode will be used for that.

Also, IIRC from my networking class, servers will respond to open ports with no services to say "no service here". While sending such a response would se a miniscule amount of bandwidth, it could add up quickly on a busy site.

_________________
Kris the Piki Geeker

A TCP RST packet is 20 bytes, 40 bytes with the IP header. The smallest Linode server includes 2000GB of transfer. To consume even 1% of the cheapest Linode server's monthly transfer, you would have to respond to 537 million connection attempts, or an average of roughly 200 per second.

In other words, no, it could not add up quickly.