by Josh Rollyson - dracus@EFNet - with contributions from Jolo, RuyDuck, Vamps,
This page is part of IRChelp.org's security section at http://www.irchelp.org/irchelp/security/
updated Jan 29, 2003
Many users are on IRC from systems behind firewalls. Firewalls can provide
an additional layer of security for systems which would otherwise be directly
exposed to the internet, especially those systems with 24/7 connections to the
internet. This guide provides a complete overview of technical terms and issues
related to firewall use, then at the end there are lots of useful links to more
specific or advanced guides as necessary, such as specific recommendations for
firewall software, or fixing DCC send problems for Linksys routers, Windows
You should read through the whole table of contents below (it's just 18 questions)
to make sure you know what is in this FAQ. That way you can just jump to the
questions that affect you. Then, if you're trying to solve a specific problem,
you may elect to look through the links at the very end.
Some of the solutions and advice presented here may have an adverse affect
on the security of a firewall and the systems protected by it. If you do not
have a thorough understanding of your network, do not attempt to apply any of
the information presented, and instead seek direct assistance from a network
security professional. We do not take any responsibility for your use of the
information presented here (see our official disclaimer).
USE THIS FAQ AT YOUR OWN RISK.
Table of Contents
- What is IRC?
- What is a firewall? (including software firewalls e.g.
ZoneAlarm, Windows XP ICF)
- What is a proxy?
- What is Network Address Translation (NAT)? (including cable/DSL
modem and router)
- What is DCC?
- What is identd?
- Why do IRC servers require identd?
- "Spoofing"? Whats that?
- Will a firewall protect my system?
- Security Policy?
- What are public (routable) addresses?
- What are private (non-routable) addresses?
- How does a firewall interfere with DCC?
- How does NAT interfere with DCC?
- How does a firewall interfere with identd?
- How does NAT interfere with identd?
- What about the so-called personal firewalls? Are they any
- Where can I get specific information about fixing firewall-related
- 1. Q: What is IRC?
- A: Internet Relay Chat. If you are asking this question, you are
reading the wrong FAQ. Go see our general help files.
- 2. Q: What is a firewall? (including software firewalls
e.g. ZoneAlarm, Windows XP ICF)
- A: Traditionally, a firewall has been a dedicated piece of hardware
meant to allow two networks to communicated in a limited way. A typical setup
is to allow users behind the firewall to access web pages and email without
allowing users on the outside to access any computers on the internal network.
In recent years, software firewalls have come into use, and they pose a cost
effective solution for many users, such as those with home or small office
broadband networks. Note that Windows XP comes with a software firewall built
in called Internet Connection Firewall, which is often the source of connection
problems. (See help links in Firewall Products section
- 3. Q: What is a proxy?
- A: A proxy is an application level gateway, typically placed between
two networks. Proxies have various uses, including use in a firewall to further
isolate two networks. Proxy software is often marketed as a way to share a
single internet connection between computers.
- 4. Q: What is Network Address Translation (NAT)? (including
cable/DSL modem and router)
- A: Quite simply, network address translation is a way to rewrite
the addresses of packets as they travel through a system. Typical uses include
allowing several computers to share a single internet connection. NAT can
also reinforce the security provided by a firewall, and in some cases provide
equivalent levels of security. Typical devices that perform NAT functions
for the average computer user may be routers, cable/DSL modems or hardware
firewalls that allow multiple computers to connect to it, or computers dedicated
to the task of "masquerading" or "internet connection sharing" (ICS). If you
are a cable/DSL modem/router user and you're having problems, first look through
questions 1-17 to understand the terminology, then see #18 at the bottom to
find specific help for many router setups.
- 5. Q: What is DCC?
- A: DCC stands for DIRECT CLIENT TO CLIENT (see technical
specification). DCC is a crude hack used to allow two IRC clients to communicate
directly without involving the IRC server. Typical uses include accessing
IRC robots (or 'bots) for short, extended private conversations between two
users, and file transfers.
- 6. Q: What is identd?
- A: identd is a server for the "Identification Protocol" defined by
[ext. link]. Essentially, it provides for the accountability of individual
users beyond the local system. It was originally created at a time when most
systems on the internet were large, multi-user systems. It is still used today,
mostly by IRC, SMTP, and FTP servers.
- 7. Q: Why do IRC servers require identd?
- A: Even though identd is intended for multiuser systems, IRC servers
typically require it to be installed, even for single user systems. One reason
for this is that it increases the technical difficulty of "spoofing" attacks
(see next question). Another is that operators of unsecured proxies typically
don't provide for identd. By requiring identd, the servers reject potentially
abusive connections from those proxies.
- 8. Q: "Spoofing"? What's that?
- A: "Spoofing" means using various means to forge the addresses on
network traffic so that it looks like the traffic came from another machine.
Traditional internet protocols provide little protection against this, and
anyone with sufficient technical knowledge can often pull off an attack of
this type. In this way, someone could masquerade as another user, possibly
gaining ops in one of that users channels, or damaging that users reputation
in the process. And that's just the tip of the iceberg, any security relying
on addresses alone can be completely compromised with relative ease in this
manner, and security partially reliant on the "security" of addresses is significantly
- 9. Q: Will a firewall protect my system?
- A: It will help. There is no such thing as a magic bullet that will
provide 100% protection for every possible threat 100% of the time. That said,
a firewall can be a very effective part of a good security policy.
- 10. Q: Security Policy?
- A: A security policy is a set of rules for keeping systems secure.
Any system connected to the internet, directly or indirectly, should have
a security policy. For a typical home system, this doesn't have to be very
complicated, and it doesn't have to exist as a formal document, just a set
of rules that set out what you are trying to accomplish, and what anybody
using your computers is expected to do to protect them. For more information,
see RFC 2196
and also the CERT guide to home
network security [both ext. links].
- 11. Q: What are public (routable) addresses?
- A: Public addresses are addresses which are routable over the internet,
and which can be made directly accessible to hosts on the internet. Public
addresses are always formally assigned by one of the regional address registries,
such as ARIN, RIPE, or APNIC, and may be sub-delegated (reassigned) in part
by the providers which they are issued to. As the cost of IP registration
and assignment via the regional registries is prohibitive for smaller networks,
small networks and smaller ISPs almost always receive their IP address assignments
as a sub-delegation from their upstream providers.
- 12. Q: What are private (non-routable) addresses?
- A: Private addresses are addresses which are not intended to be routable
over the internet. They are typically used for home networks, and in other
applications where direct accessibility is not required. In the past, it was
common practice to choose any random range of addresses for this purpose.
This practice is depreciated, and there are presently several blocks of network
addresses permanently reserved for private use. This prevents the problems
that may occur when a network not originally intended to be connected to the
internet is later connected to the internet.
1918, ext. link]
The Internet Assigned Numbers Authority (IANA) has reserved the following
three blocks of the IP address space for private internets:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Unless you have other addresses formally assigned by your provider or
regional internet registry (very unlikely for a home network), these are
the ONLY addresses which are acceptable to use for internal use. These addresses
will never be assigned for other purposes, preventing address "collisions"
on the global internet.
- 13. Q: How does a firewall interfere with DCC?
- A: DCC uses randomly selected ports, typically in the range 1024-65535
(mIRC uses 1024-5000 by default, this can be constrained in DCC options).
As it is common security policy to block all "unused" ports, a firewall is
often configured to block all traffic outside of common ports, or to block
all inbound traffic not intended for authorized services, such as web servers.
In the DCC protocol the receiver initiates the connection to the sender, so
a common problem is that a firewalled user can receive but not send. In this
case the firewall is not restricting the outbound connection, therefore the
receiver can connect to the sender to retrieve the file, but when the roles
are reversed, with the firewalled user sending, the receiver cannot connect
through the firewall to retrieve the file.
Solutions for users who cannot send or receive because of a firewall:
- Disable the firewall. Probably the easiest solution, but also the least
desirable, as you lose all security provided by the firewall this way.
- Configure the firewall to permit outgoing connections on any port, if
it fits within your security policy.
- Configure the firewall to permit incoming connections to a range of
ports, and configure clients to use those ports for DCC send, unless the
ability to transmit files outside of your network is against your security
Solutions for users who cannot send because of a firewall.
- Configure the firewall to permit incoming connections to a range of
ports, and configure clients to use those ports for DCC send, unless the
ability to transmit files outside of your network is against your security
- 14. Q: How does NAT interfere with DCC?
- A: NAT implementations are typically not aware of ports being opened
on client systems behind the NAT gateway, and generally have no idea that
they need to forward the incoming connections needed for DCC SEND to work.
Generally, most NAT implementations will allow receiving files, but won't
allow sending them. There are a few ways to work around this:
- Use the DMZ feature in many cable & DSL routers. This feature causes
all untracked connections to be redirected to a single internal machine.
Be aware that the machine is then effectively exposed to the internet,
as if it were directly connected without the router. This method will
weaken the security of the machine exposed in this manner, and will only
get DCC working properly for that one machine.
- Forward a range of ports to each machine which needs to be able to send
files via DCC, and configure the client to use those ports. This takes
a little more work, and is more secure, but only a few transfers can be
managed at the same time, and the ports for those transfers become easier
to guess, potentially enabling someone to "steal" a DCC send by connecting
before the intended receiver does.
- Use an implementation which tracks IRC connections, and monitors them
for the CTCP handshake used to initiate a DCC transfer, automatically
forwarding the needed ports.
- Implement a SOCKS5 proxy server, and DCC via it. Just make sure you
configure the proxy to only allow authorized users to connect, misconfigured
proxy servers are commonly used to mask the source of malicious activity,
by redirecting from one internal host to another internal host. Also,
a misconfigured proxy server can be used to gain access through a firewall,
potentially subverting that firewall.
- Implement special client software which interacts with the firewall
to request port forwardings for DCC transfers transparently to the user.
This would be difficult, but would work.
- 15. Q: How does a firewall interfere with identd?
- A: Firewalls are often configured to block unused ports, particularly
those in the 1-1024 range of "privileged" ports, which under many operating
systems, require administrative privileges to run services under. Firewalls
also providing NAT further interfere with identd, see next question for more
- 16. Q: How does NAT interfere with identd?
- A: NAT is typically used in a one-to-many configuration, that is,
one routable IP address is shared between several systems. Identd is designed
to identify the "owner" of a connection on a single, multiuser system. Typical
Identd implementations do not account for NAT, and therefore will respond
"unknown" for systems behind a NAT gateway. Further complicating the situation
is the fact that the gateway may translate ports as well, and that to properly
implement Identd on a network running NAT, an implementation must do the following:
- Identify the machine for which the Identd request is intended for behind
the NAT gateway, and direct that request to that machine. Once forwarded
to the machine responsible for the network, identify the user responsible
for that connection, accounting for differences caused by port translation.
- Respond to every request with a generic reply, simply to satisfy the
requester's requirement that clients be running identd. Considerably easier
to implement, but this isn't exactly true to the spirit of RFC
1413 for identd [ext. link].
There are a few implementations out there which are capable of solving
these problems, two that I am aware of for *nix are oidentd and midentd.
Note that if you're using mIRC behind something like midentd, you need to
set mIRC to turn off the default identd setting of "enable only when connecting".
- 17. Q: What about the so-called personal firewalls? Are
they any good?
- A: While they can provide some limited protection, software or personal
firewalls have many weaknesses. No matter what the manufacturer of any personal
firewall would like you to believe, there is no software product which will
protect you against all types of attacks, nor from an "internal" compromise,
that is, if you (or somebody else with access to your PC) run software on
your machine which takes control of that machine and subverts the firewall.
While we STRONGLY recommend that a hardware firewall be used, in most
circumstances, you are better off with a software firewall than with no firewall,
due to the difficulties in closing off the many insecure services bundled
with Windows. We will list the pros and cons of using personal firewalls
Personal firewall PROs
- A personal firewall can be used to prevent access to certain services
built into Windows which are notoriously difficult or even impossible
to disable, such as NetBIOS.
- A personal firewall can prevent certain Denial Of
Service attacks, most notably disconnects due to spoofed
unreach aka "click" - this is perhaps its most important (and some
would say only unique) contribution to your security.
- A personal firewall can block inadvertent holes in your computer's security
if you unintentionally leave open services such as file or print sharing
or an FTP daemon. Instead of relying on a firewall, however, you should
check your security (try the Shields
UP! site) and just fix these vulnerabilities.
- This is barely a pro at all. Personal firewalls can block the action
of certainTrojan horses, by
preventing them from "phoning home" and by preventing a would-be attacker
from connecting to them, but this is false security! Trojan horses
can already circumvent personal firewalls, and this will become typical
behavior. The only effective protection against trojan horses is
to totally avoid untrusted software, and scan
even "trusted" software with an up-to-date virus scanner. Even then, active
scripting vulnerabilities which are unfortunately common in popular browsers
and mail programs may still expose your system to viruses or trojan horses.
While no firewall can totally protect against an attack from within, dedicated
hardware firewalls stand a much better chance at blocking a trojan's activity.
Even then, you should be aware that a trojan can disguise its network
traffic as legitimate traffic to pass through a firewall unaffected, or
even worse, can attach to or interface with an application which is normally
allowed to access the internet, circumventing the "per-application" restrictions
in certain personal firewalls.
- A personal firewall can make it impractical for others to port scan you to identify your vulnerabilities. It does so by making scanning more time
consuming, by preventing the usual RST response on closed ports so that
the scanner has to wait for the connection attempt to time out. The personal firewall can also defeat automated scanning for
active hosts by disabling ICMP ECHO replies (aka "pings").
Personal firewall CONs
- Since a personal firewall runs on the same computer as it protects,
it can be reconfigured, disabled, or otherwise subverted by malicious
software running on your computer.
- Personal firewalls cannot protect you against serious floods,
because it is only software and is run on the tail-end of your relatively
slow connection, rather than at the ISP's high-bandwidth side. Consider
if a river is threatening to overflow, you have to try to stop the flood
with barriers at the river banks. If you don't do that, by the time 10-foot
flood waters surround your house, it's useless to try to stop it just
by sandbagging your front door. This is a very important point, so let
me repeat it: No matter what clever software or hardware you run at home,
you will always be vulnerable to flood attacks.
- Personal firewalls are very noisy. They report normal background traffic
as harmful activity, leading to panic among users of personal firewalls
who in turn cause a great deal of grief for ISP abuse desks, who now receive
endless reports of "attacks" every time someone executes a totally innocuous
- Personal firewalls are not a "plug and play" magic fix that you download,
run, and forget. They take time to set up, can be confusing to people
without a lot of computer experience, and require constant configuring
and updating to adapt to new attacks.
- Personal firewalls often get in the way of your legitimate network activity.
Although most firewalls are configured by default to allow things like
web browsing, they may need to be taught about DCC, identd, ICQ, net gaming,
- Personal firewalls cannot block, find, or remove traditional viruses
which do not generate any network activity; that is the role of virus-scanning
software. For example, if you get an email virus attachment, your firewall
will let it through since email by itself is an allowed activity, and
if you run the virus designed to erase your disk, it can still do so,
since that doesn't involve any network activity that the firewall monitors.
- Many ISPs won't support users with firewalls. For example, Road Runner
requires firewalls be totally uninstalled before any advanced technical
support. They just create too many support headaches. Indeed, the first
troubleshooting step for a user with a firewall should be to make sure
the firewall isn't interfering before calling support.
- Some providers legitimately perform certain probes to determine if a connection is still active. Blocking these probes could cause you to get disconnected.
- Blocking TCP RST replies on closed ports
has the side effect that any connection attempt to a closed port takes
an extremely long time (sometimes over a minute) to fail.
This can affect mail, ftp, and IRC servers which attempt
to make an identd connection, and expect it to succeed or fail quickly.
For more information, see the home
PC firewall guide and this much more critical
view of "personal firewalls" [ext. links]. Almost all reasonably adequate
personal firewalls are commercial software costing anywhere from $30 to
much more, often with additional annual "update" license fees. Note that
Windows XP comes with its built in Internet
- 18. Q: Where can I get specific information about fixing
- A: The above should arm you with the proper general knowledge for
fixing your problem, provided you consult with the documentation that came
with your firewall, router, etc. In case that's still not enough, the following
links may be useful [almost all external links]:
Some general resources:
an objective list from the Open Directory
Project of all things related to firewalls - products, help guides,
- DALnet ident FAQ:
DALnet made this FAQ dealing with ident problems related to routers, proxies,
ICS, and firewalls.
Firewall products (hardware and software):
For mIRC or Windows:
- Proxies and Firewalls,
by the makers of mIRC, provides Windows help with proxies.
- DCC Help - a list of URLs
from DALnet #mIRC helpers, includes many of the ones listed below and
then some, such as specific fixes for certain router brands or software
- mIRC and ICS, a log of
an IRC chat where users discuss how to do NAT and proxy and allow DCC/CTCP
protocols to continue to function in mIRC.
- Using mIRC with...
ICS, Firewalls, and Wingate. Detailed configuration advice, but assumes
you know more than the beginner.
ICS Related FAQ - from HomeNetHelp.com, includes help on installation,
using protocols like IRC, ICQ, etc.
message boards - connection issues forum: when all else fails, the
mIRC forums are a great place for the patient reader to dig up specific
information for that weird router brand, or just to ask your question.
For UNIX/Linux/Mac OS etc.:
Feel free to report broken URLs to the webmaster.
all pages © IRCHELP.ORG or original