From: "Marfig" Subject: How to setup Tiny Personal Firewall (Parts 0, I, II) Date: mardi 8 mai 2001 01:44 How to Setup Tiny Personal Firewall ----------------------------------- 0 - Introduction I - General (very!) TCP/IP II - What is TPF? What is Not? III - TPF Screens IV - Single Machine Configuration V - LAN configuration VI - A note about personal firewalls VII - Further readings (URLS and books) ----------------------------------- 0 - Introduction ---------------- I'll try within this series of posts to document the setup of Tiny Personal Firewall. I'll be calling it Tiny, TPF or Tiny Personal Firewall according to my mood, so bear with me. I will not explain how to install TPF. Just install it as any other application and get on with it. There's nothing much to it. One final note. It is strongly recommended that you use some kind of fixed-size font when reading this (like the Courier font). I try to design some pure ASCII graphic representations below, and they will look pretty strange if you choose otherwise. If you don't know how to change your font on your newsreader, then don't install a firewall. So, without any further delay... I - General TCP/IP for Tiny --------------------------- One of the things that most drive people away from Tiny is that they have to deal with port numbers, IP addresses, inbound and outbound connections. And all of this at the same time within a single firewall rule. This is actually a misconception, as Tiny can be configured just at the application level. But for Tiny to work as *just* an application level personal firewall, it takes away much of it's charm and functionality. If you feel like not learning a little about TCP/IP, go for Zone Alarm. It does it's job quite well and you will need not face all the "hassles" (I call them "challenges") that Tiny offers. The first notion someone working with Tiny needs to have, is of how communications are established at the TCP/IP level. Without digging too much at this concept (that is to say, I don't know it that well myself), let's show what Tiny needs and what you need to know in order to properly configure Tiny. All communications are established between a *Client* and a *Server*. The Client is the one making a request and the Server is the one getting the request. In most cases, the Client is you. The Server, some machine on the Internet. Let us say, you want to "go" to a web site named http://www.lockergnome.com. You fire your browser and type the address. Your browser will act as a Client and make a *Request* to the Server were www.lockergnome.com resides. Simple enough... But this request has more to it. Once the Server process your request, it will actually send to your browser the home page. This is called a *Response* to your Request and it means that the server will send you the page you requested. A graphical bird's view: Browser -> Send Request -> www.lockergnome.com -> Send Reply -> Browser On your side what will happen is that you send a request over the Internet and in return you get a response. The sending is called *outbound* and the response that follows is called *inbound*. These connections take the form of *packets*. (consider *packets* like snail mail envelopes with the letter inside being the data and the mailer and receiver addresses written outside the envelope. We will return to this shortly). This to say that, from your perspective (and that of Tiny) all outbound connections are connections were you SEND packets and all inbound connections are connections were you RECEIVE packets. So: Browser -> packet(s) -> www.lockergnome.com -> packet(s) -> Browser Let's stop a little bit here and revive the terminology we just discussed. Client, Server, Request, Response, Inbound, Outbound. Good. Now let's get on with it... Among what we already discussed, TCP/IP also works with *Ports*. A port is much like an entryway. When a request or response is issued, attached to the information of the source and destination addresses, there is also information about the source and destination Port. These two port numbers (source and destination) may not match (and usually they don't). One of these ports is called the "Contact Port". The other port is called the "Caller port". As you may notice from their unofficial naming, the Contact port is the one belonging to the Server, and the Caller Port is the one belonging to the Client. A packet is then composed of two parts. The header and the body. The header has information about IP addresses and ports, both for the source as for the destination. It also holds several other information like Time-To-Live flags and such, but these are really beyond the scope of this explanation. The body holds the actual data that is to be sent or received. So, let's try to give a crude graphical representation of a packet, the unit that reaches or leaves your computer and is processed by TPF. Note that "crude" means I don't know better: Header part Body part ---------------------------------------------------------------------- |Source IP Address | Actual data being sent. It can be an HTML |Source Port number | page, an "hello" string, a file being |Destination IP Address | downloaded, a request to any of the above, |Destination Port Number | or whatever... |--------------------------------------------------------------------- There are 65536 ports. They range from 0 to 65535. Each port number can belong to one of two types of communication. *TCP* (Transmission Control Protocol) or *UDP* (User Datagram Protocol). There is no need to enter into details of what these are. Suffice to say that TCP is different from UDP in which the former is a reliable protocol and the later is not. By reliability I mean, it guarantees delivery and requires a connection. TCP does, UDP does not. Furthermore, port numbers are divided into three classes. Well Known Ports (ranging from 0 to 1023), Registered Ports (1024-49151) and Private Ports (49152-65535). Usually the so called "Contact Port" (or the port that belongs to the server) is either within the Well Known Ports (80, 443, 25, 110, for HTTP, SSL, POP3, SMTP, respectively) or within the Registered Ports (1433, for Microsoft SQL Server). The contact port helps define what connection is being established. But apart from those within the Well Known Ports, this is unfortunately not true for all connections, as many developers don't respect the port assignments above 1023 (and some even below it!). So, were does this leads up to? - When you connect to the Internet, there will be packets leaving and reaching your computer. - Packets leaving are called outbound and packets reaching are called inbound. - The machine making the request is called the Client and the machine receiving the request is called the Server. - The server port number defines the type of connections being established (usually). The client port number defines nothing (usually). - You will find two types of packets (or connections). One will be UDP and another will be TCP. - These connections also have information on the client and server IP addresses. One final note. It is common for your machine to act as a server. It is actually VERY common. When discussing clients and servers above, I'm strictly talking about who makes a request and who receives a request. As you later will see, there will be a lot of times where your machine will act as a server, no matter if you have "server" software installed or not. II - What is TPF? What is Not? ------------------------------- Tiny Personal Firewall is a Personal Firewall (give the man a medal!) TPF is NOT an anti-virus or a full-fledged firewall. This firewall thing started a lot of years ago with the so called hardware firewalls. These were and are "boxes", resembling a router, that protect the network behind it from the outside (and also protect the outside from the inside!). What kind of protection they give is solely to their administrator discretion. But typically they act as filters from what/who can "get in" and what not and what/who can "get out" and what not. Some very sophisticated firewalls can even hide themselves from the outside, so that there is no evidence of anything (much less a network) on some IP address. Rapidly after these hardware firewalls, the so-called software firewalls showed up (Linux/Unix helped propagating the concept). These, work much like the hardware ones, but instead of a marvel of electronic development, they are a marvel of software development. For some reason, I'm yet to understand, contrary to the philosophy on Linux, the Windows world insists on coupling software firewalls on proxy servers type-of software. But no matter what, software firewalls are considered less secure than hardware ones, simply because they rely on an operating system, disk usage, free memory and the inevitable problems that arise from those. They are also slower to deal with a lot of traffic, exactly because of the same reasons. Linux/Unix introduced the concept of blackboxes (IIRC, they being called that way). These are computers that have one sole purpose in life, to host a firewall. Some of them don't even have an hard disk and rely on a floppy drive to fire up the firewall. I just wished we had something like that on Windows... (you can actually have a Linux or Unix blackbox protecting a Windows network) Well, fairly recently, the Personal Firewalls showed up. I seem to have in mind that the first one to actually gain some notoriety was Sygate Personal Firewall (and also IIRC, the first one to use that term). These firewalls (on which TPF belongs) are very similar to software firewalls, but introduced two new concepts: - Easy to administer so that everyone can use it - Application level security Until now we had either expensive or PhD demanding firewalls (or both). Now, finally everyone can use a firewall and protect their computers at home. But the most surprising thing about these firewalls is that they no longer rely on port numbers, inbound or outbound connections or IP addresses. They're main focus now is Applications. In other way, with personal firewalls, you can say that Internet Explorer can connect to www.sex.com but not to www.lockergnome.com (I have my priorities right, you bet!) This addition really helps against a kind of attack that traditional firewalls can't do a thing about, Trojans. And most probably this is why they became so popular in such a short time. Well, that and the fact that big brother is watching and we don't want that to happen. But also because of that trojan protection, Personal Firewalls are seen by many as another kind of virus protection. One that specializes in Trojans... Needless to say, I strongly resent that notion. TPF places the bar higher. It's actually a Personal Firewalls with all the whistles and bells that ships with user-friendly windows applications, but is also a Protocol based firewall. This because you can not only protect based on the applications you use, but also based on port numbers, IP addresses, inbound and/or outbound connections. It's perfect for those of us that want that added security and control over communications that personal firewalls the likes of Zone Alarm don't offer. And this is what TPF is all about. Nothing more. I've been using it for 2 years now, maybe. Despite the fact that it's still a work in progress (currently at beta 2.0.13), it does its work better than any other and with a stability difficult to match (not once, not even a single time in these past 2 years did TPF crashed Windows). -- Mario Figueiredo -- Quiet Technology, Inc. At last something a little less noisy