Question about blocking incomming traffic

Hello,

Like many others, I have continued to get attempts to connect to my local net router from the Asia Pacific Network Information Centre and from RIPE Network Coordination Centre, Amsterdam. I would say that 90% of attempted connections come from these two locations. The originating IP address is usually not registered in ARIN, so there is no specific IP range I can block. It is probably pointless to block individual IP addresses, so I have been thinking about other methods.

I began wondering why I should allow any inbound connections, meaning connection requests that originate off of my local net. After thinking about this, I realize that I don't fully understand these protocols as well as I should. Can someone explain whether or not I should block all incoming connections (I am not running any kind of service that would need incoming connections, ftp, sshd, etc). If I can't block all of them, which ones should I continue to allow? What would such a firewall rule look like, etc?

Thanks for any assistance that you can provide.

LMHmedchem

When planning firewall configurations the first thing you want to do is to plan meticulously what you want to achieve. Planning is of the utmost importance here, otherwise you end up with an unmanageable system in very short time.

First: what is a firewall?

A firewall operates similar to a router, though unlike a router not on layer 3 of the OSI reference model but on layer 4. That is: it has (at least) 2 network interfaces, one "inside" and one "outside". They represent 2 different layer-3 areas (like the interfaces of a router represent different layer-2 areas, so-called collision domains), which would be connected via a common layer-4. "Would be", because per default this layer 4 is completely closed by the firewall software. No package coming in on one interface could leave through the other. Firewall rules now define exceptions to this, so that certain appointed packages in fact can go through and this way connections become possible.

What is so special at this layer 4?

At layer 3 we have one protocol, which dominates traffic: IP. There are other protocols (ICMP, which you can see at work if you use "ping", for instance), but the data transfer itself - the part which the user really care for - is done via IP. IP packages now are used to transport mostly 2 protocols: TCP and UDP. Because UDP has no flow control its use has dwindled for a long time and most of the packets (about 90%) are TCP packets. Inside these TCP packets certain services transport their information: telnet, ssh, ftp, NFS, .... See the extempore for more information about what happens to a packet.

Like IP has an addressing schema to know what belongs where (the "IP address"), layer 4 also has its addressing means: the port. Ports are 16-bit numbers and range from 1-65535. Port numbers below 1024 are so-called "well known services" and only processes running under "root"s user-ID can use these ports. So, like "123.123.123.123" denotes a certain host, "123.123.123.123:1234" denotes a certain port on a certain host. This combinaton of IP address and port number is called a "socket".

Why is this relevant? Because behind each port can listen a "daemon" - or not. If not, then a communication simply won't come to pass. If you try to reach a system via telnet which has no "telnetd" running you will get the "connection refused" error - without any firewall or other security. All the usual means of connecting to a system are on such fixed ports with small numbers - hence the name "well-known services". Have a look in /etc/services to see them.

And what does all that have to do with firewalls?

Now, that we have covered the grounds: firewall rules will allow access from a certain (range of) socket(s) to a (certain range of) socket(s). Rules are always one-way: if IP-A:A is allowed to connect to IP-B:B that does not mean that IP-B:B is allowed to connect to IP-A:A.

Notice that a daemon has to be contacted on its original port but usually shifts communication away from this port when establishing the connection, mainly to be able to serve other incoming requests. These other ports are typically outside the WKS-range 0-1024. It is a good idea therefore to allow the ports above 1024 in both directions and make sure no service is open on any system on your network in this range per default.

____________________
A little extempore: what happens in networks:

For example: you use "telnet" to connect to another host:

"telnet" (the software) puts its information into telnet protocol packets
which are then packed into TCP packets for transmission
which are then packed into IP packets for transmission
which are then packed into, say, 802.3-frames and transmitted over Ethernet

now, on the other side:

the 802.3-frames are transmitted to a router
there, the IP packet is reassembled and relayed to another network
repacked in, say, 802.11-frames because this network is a WLAN

received by the host and unpacked, getting IP packets
unpacked these IP packet and store it in the TCP reassemble buffer (no flow control for IP)
reassembled the orderly queue of TCP packets and
unpacked the TCP packets to get telnet messages
pass these to the telnetd-daemon

So far a little introduction to firewall workings. If you need more detail and help on specific topic just ask.

I hope this helps.

bakunin

Thank you for this very informative post. This is what I was looking for. If I read this right, my router will automatically block incoming connections unless I have set up port forwarding to allow it. Further, unless I am running the service that the connection is looking for, the connection would be refused anyway.

I have been to shields up and this system passes all of their tests there, other than the IP of my router being visible. This is the message that I get, "Your system has achieved a perfect "TruStealth" rating. Not a single packet, solicited or otherwise, was received from your system as a result of our security probing tests." I guess that should provide me some peace of mind.

Is there any way for there to be intrusion on port 80, since that will be used for normal internet traffic?

LMHmedchem

Exactly.

I am not sure if i understand the question correctly. Port 80 is for hypertext transport protocol (http). It is the default port a web server (=httpd, http-daemon) uses. Suppose you use http to surf to some web site:

You send a request to some site, using http and contacting port 80 at, say, remote.site.com.

The httpd (read: apache, tomcat, IIS, ...) sits there at the server and listens at port 80 when your request comes in.

It picks it up, creates an answer (=web page) and sends it to you, using some unspecified free port on its own system and port 80 at yours.

Your http-client (read: web browser) takes this message apart, creates an answer (for instance, by you clicking on a link, etc.) an sends it back, etc..

A "message" in http is similar to an MIME e-mail in format. It can consist of several parts (pictures, scripts, ...) and of course one (or even several) of these parts can contain malicious code. If you download such code and you run a widespread graphical interrupt handler instead of an OS, your system could become infected with some malware, adware, virus, worm, ...

You would have gotten this malicious code through your port 80, like all the other http messages you get. Closing it would simply forbid any http traffic and effectively prohibit http-connections of any sort. You can either use some scanner inspecting what comes through port 80 (this is how virus scanners work - they pose as daemons listening at port 80 and only pass to the originally intended client after having inspected what comes through) or use a system which cannot be affected by malicious code. Code, malicious or not, will not carry out its purpose until being run and it runs with the privileges of the user running it. This is why it is a very bad idea to surf the web as "root" in Unix. Alas, some OSes are only usable as "Administrator" and so the problem starts.

I am not sure if i have addressed your concern. In case i haven't: please ask clearly, what you want to know.

I hope this helps.

bakunin

Sure the remote server uses local port 80 to send pages back? I don't think so; it will use the originating port...

OOps, you are right. Somehow, during the several sessions it took to write the answer, i managed to confuse myself. Thanks for the correction.

bakunin