http://www.ecst.csuchico.edu/~dranch/LINUX/TrinityOS-security/TrinityOS-security.tgz
If you are unfamiliar with how TCP/IP packet filters work, the following should
give you a decent start. Please understand that if you don't understand what
is being described below, you should probably do a little research on how TCP/IP
works.
Think of a IPCHAINS or IPFWADM rule set like the following:
All interfaces (any network cards, PPP connections, the localhost
interface, etc) on a Linux box have INPUT, OUTPUT, and FORWARD rules.
What is the difference between DENY and REJECT?
DENY:
If you TELNET to a box that "denies" TELNET traffic, your TELNET will
just sit there and seem to try and try and try to connect. Ultimately,
the TELNET request will eventually timeout.
REJECT:
If you TELNET to a box that "rejects" TELNET traffic, your TELNET will
almost immediately return with a "Connection Refused". This is the
normal behavior for a machine that does not SUPPORT telnet access such
as stock versions of MS Windows9x, NT, etc.
Why do I prefer REJECT over DENY?
If someone connects to your server and you REJECT their traffic, it seems to
them as if your computer cannot serve, say, TELNET connections. If you DENY
the traffic, then their TELNET traffic just dies and their TELNET client
eventually times out. So, with REJECT, a hacker doesn't know if your machine
can or can not do TELNET. With DENY, a hacker KNOWS that you are filtering
them. I feel that a REJECT make your box look "dumber".
How a packet firewall works
Say you have a TELNET packet (port 23) from the Internet that wants
to reach your Linux box: The TELNET packet is sent from the remote
computer on the Internet. The packet is received on PORT 23 to the
INPUT rule on the -External NIC card-. If the TELNET packet is matched
on the INPUT to allow the packet through:
Some ideas of possible packet firewall rules can include:
source and destination IP addresses
TCP or UDP traffic
specific source and destination ports (TELNET, etc)
Then let the packet IN though the packet firewall. If not matched, the packet
is either REJECTED or DENIED. You can also log the fact that this packet was
killed. If passed, the TELNET packet then goes to the TELNET daemon on the
Linux box to be processed.
Once the reply TELNET traffic is generated, the actual return traffic will be
returned on a HIGH PORT ( port > 1024 ) and NOT on port 23. If you don't
understand this, please read up on TCP/IP fundamentals. For this example, lets
say the return TELNET traffic is on port 3200. Now, this return port 3200
traffic is then sent to the OUTPUT filter of the EXTERNAL NIC card.
If the packet is matched to allow the packet OUT, then let through. If not
matched, its either REJECTED or DENIED. You can also log the fact that this
packet was killed.
Next, if the packet is on a DIFFERENT network than the destination address,
the packet needs to be "forwarded". If the rule matches, forward the packet
onto the correct network. If not matched, its either REJECTED or DENIED.
You can also log the fact that this packet was killed.
NOTE: This is is what a "router" does on a basic level.
If finally passed, the HIGH PORT packet leaves the Linux box to go over the
Internet connection destined to that remote computer.
+-------------------------------+
| Linux TCP/IP stack |
|_______________________________|
| (3) Telnetd Server |
{PORT 23} |_______________________________| (Port 3200)
(2) +--->| Input: Forward: Output: |-------------+ (4)
| +-------------------------------+ |
| |
| |
+------------+ | +------------+ |
| Input | | | Output |<--+
| Rule | | | Rule | ^
{PORT 23} | | | | | |
(1) +-IN--->| P a s s ? |---+ +--------------| P a s s ? | |
| | or | | | or | |
^ |Deny/Reject?| | (5) |Deny/Reject?| |
--------- +------------+ | +------+-----+ |
*Send* | | | |
--------- v Check if packet v |
Remote Dump Packet No +---- needs to be Dump Packet |
Internet (possibly log it) | forwarded (possibly log it) |
site | | |
--------- | (6) | Yes |
*Received* | | |
--------- | v |
^ | +--------------+ +---------------^------+
| {PORT 3200} | | Forward | | Write the packet for |
(7) +-----------------------------+ | Rule | | the destination |
| | | network address |
| | | |
Dump Packet <------|Don't Forward?| | Possibly re-write the|
(possibly log it) | | |SRC addresses for MASQ|
| Forward? | +----------------------+
| or | ^
|FWD & MASQ it |-----------------------+
+--------------+
How IP Masquerade (IP MASQ) works:
Basically, IP MASQ's main mechanism works when an INTERNAL machine initiates
traffic to the outside world. External machines on the Internet CAN directly
communicate to an internal machine(s) with the aid of PORTFWing but this is
better explained in the IP Masquerade HOWTO. PORTFW support IS included in the
TrinityOS firewall ruleset but for a full explination, again, please see the IP
Masqerade HOWTO.
Anyway, when an internal machine (for now, in that diagram in the URL above,
think of the "Remote Internet Site" on the left with your internal machine.
If this diagram confuses you, just skip it and read through this example:
1. Say the internal machine trys to TELNET to some server out on the Internet.
For this explict example, this example is:
Source src IP: 192.160.0.10
src port: 3200
dst port: 23
Linux : src IP: 111.222.212.222
External src port: 64000
dst port: 23
Destination: dest IP: 222.020.222.111
dst port: 23
2. The MASQ server receives this request from the MASQed PC over the Internal
interface and it hits the Input firewall. Here, the input firewall can
either accept the packet or deny it. For this example, assume it will be
ACCEPTed.
3. Now, if the packet was also allowed through the OUTPUT firewall, the
TELNET would be finally forwarded through the MASQ server unchanged
except...
3M. Notice that src port IP address of the TELNET is a private RFC1918 address?
These addresses aren't routable on the Internet so it must be changed to
a public address. To be able to track this change, the SRC port address
will be changed as well.
The changes in IP address and port number is IP MASQ in action! What Masq
basically does is RECORDs the traffic type (for this example, 23, TELNET),
where the traffic is going (DST IP address, 111.222.212.222) and the
original SRC port (SRC port 3200) from the MASQed client. It takes all
this information and puts it into a MASQUERADE table.
It then will re-send this TELNET traffic out on its EXTERNAL NIC but it
will also alter the packet. It will both re-addresses the Source IP address
(SRC IP) with the MASQ server's own external IP address and change the
source port (SRC port) to something in the range of 61000-64096. So, the
packet would now look something like:
Source: SRC IP: 111.222.212.222
SRC port: 64000
Destination: DST IP: 222.020.222.111
DST port: 23
4. When the response comes back from that remote TELNET server, the Linux
MASQ server will recognise that this traffic as coming back from a server
that is in the MASQ table. It would then take the packet and first verify
that it should be allowed through the INPUT section of the firewall.
Next, it would then replace the destination IP address (DST IP) with the
correct FINAL IP address of original internal TELNET client and also change
the original SRC port address back to 3200.
The returning packet now looks like:
Source: DST IP: 222.020.222.111
DST port: 23
Destination: SRC IP: 192.160.0.10
SRC port 3200
Differences between Packet and Statefull Firewalls
Now, I want to quickly comment on the use of HIGH TCP/IP ports and what is the
difference between a PACKET firewall and a STATEFULLY INSPECTED firewall.
Though you might let port 23 OUT of your Linux box (TELNET), if you don't also
allow ports 1024-65535 back INTO your Linux box, TELNET won't work.
Now you might be thinking that letting in ALL high ports back into your Linux
box is a BAD thing. YOU'RE RIGHT! Realistically, it would be nice to only allow
in only the return HIGH ports that you need. This is what the "-k" option in
IPFWADM or "! -y" is for IPCHAINS. The problem is, IPFWADM and IPCHAINS aren't
smart enough yet to understand all TCP/IP programs such like TELNET, WWW, SSH,
etc. So, some programs you can lock down the high ports with the "-k" or "! -y"
options while other programs will have to be configured to allow all 1024-65535
ports in.
So your next question should be "Do others firewalls have this problem?" NO!
Why? Because they use a technology called "Stateful Inspection".
Stateful firewalls actually listen to ALL network traffic step-by-step to make
sure that everything is going 100% correctly.
Analogy:
Packet firewall:
A packet firewall only checks for source and destination IP addresses
and port numbers. Kinda like a strainer for different colored marbles.
Stateful Firewall:
A stateful firewall not only checks for source and destination IP
addresses and port numbers, but it also LISTENS to all TCP/IP
communications to make sure that all of the "communications" are
following all procedures. Think of it as a realtime grammer and
spell checker for "languages" like TELNET, WWW, etc. Hackers try
to re-write the "language" to try to break into it, crash it, etc.
A stateful firewall will see a given TCP/IP connection running a
"language" like TELNET doing weird stuff that it shouldn't be doing
and then it simply drops that weird packet. Much better huh?
Once you setup one of the firewalls shown below, you might have
some problems getting running or your might be getting strange
new messages on the console. What do these messages mean?
In the below rule sets, any lines that either DENY or REJECT any
traffic also have a "-o" to LOG this firewall hit to the SYSLOG
messages file found either in:
Redhat: /var/log
Slackware: /var/adm
If you look at one of these firewall logs, you would see something like:
The kernel logs this information looking like:
IPFWADM:
Feb 23 07:37:01 Roadrunner kernel: IP fw-in rej eth0 TCP 12.75.147.174:1633
100.200.0.212:23 L=44 S=0x00 I=54054 F=0x0040 T=254
IPCHAINS:
Packet log: input DENY eth0 PROTO=17 12.75.147.174:1633 100.200.0.212:23
L=44 S=0x00 I=54054 F=0x0040 T=254
There is a LOT of information in this just one line. Let break out this example
so refer back to the original firewall hit as you read this. Please note that this
example is for IPFWADM though it is DIRECTLY readable for IPCHAINS users.
- This firewall "hit" occurred on: "Feb 23 07:37:01"
- This hit was on the "RoadRunner" computer.
- This hit occurred on the "IP" or TCP/IP protocol
- This hit came IN to ("fw-in") the firewall
* Other logs can say "fw-out" for OUT or "fw-fwd" for FORWARD
- This hit was then "rejECTED".
* Other logs can say "deny" or "accept"
- This firewall hit was on the "eth0" interface (Internet link)
- This hit was a "TCP" packet
- This hit came from IP address "12.75.147.174" on return port "1633".
- This hit was addressed to "100.200.0.212" to port "23" or TELNET.
* If you don't know that port 23 is for TELNET, look at your
/etc/services file to see what other ports are used for.
- This packet was "44" bytes long
- This packet did NOT have any "Type of Service" (TOS) set
--Don't worry if you don't understand this; not required to know
* divide this by 4 to get the Type of Service for ipchains users
- This packet had the "IP ID" number of "18"
--Don't worry if you don't understand this; not required to know
- This packet had a 16bit fragment offset including any TCP/IP packet
flags of "0x0000"
--Don't worry if you don't understand this; not required to know
* A value that started with "0x2..." or "0x3..." means the "More
Fragments" bit was set so more fragmented packet will be coming in
to complete this one BIG packet.
* A value which started with "0x4..." or "0x5..." means that the
"Don't Fragment" bit is set.
* Any other values is the Fragment offset (divided by 8) to be later
used to recombinw into the original LARGE packet
- This packet had a TimeToLive (TTL) of 20.
* Every hop over the Internet will subtract (1) from this number. Usually,
packets will start with a number of (255) and if that number ever reaches
(0), it means that realistically the packet was lost and will be deleted.