Created with The GIMP
   


Features

2007 CHLUGger of the Year!
Mailing List
Archive
Help Open Source
Question of the Day

About Us

Mission
Directions to Meetings
Contact Us
Video
Guest Speaker Info
Acceptable Use
Link To Us!

CHLUG Exclusives

Open Office 3.0- New and Enhanced Features New!
Linux Hacking and the Law New!
VOIP with Asterisk
Assessing OSS
Knoppix Ubiquitous Computing
Filesystem Hierarchy
Virtual Hosting
Wesnoth
Xbox/Linux
udev
Emacs Talk Notes
Home Sweet ~
Top 100 CLIs
Device Drivers
Real Time Linux
Network Considerations Part II
Network Considerations Part I
Amanda Presentation
GNU/Linux Calculators Configuring Rio
ReiserFS
Linux Sound
Samba notes
Network time protocol
C programming in Linux
Boot, startup and shutdown
hdparm HOWTO

Friends of CHLUG

Ubuntu NJ LoCo
New!
Cherry Hill Library
RUSLUG
LUG in Princeton
Useful Links

Loads of Linux Links
LinuxToday.com
Art of UNIX Programming
More Links

Agenda

Contact Congress
Why We Use Linux
Companies Using Linux
Linux in Business



Get Linux!


Get Firefox!

Get OpenOffice.org!




Created with The GIMP



Website Designer- jesran.net



Network Considerations Part I
Gerald Neale
2002-01-03
---------------------
Demonstration Environment :

Machine #1 (Debian potato "internal user")
 -One NIC eth0 (internal ip 192.168.1.2)
 -Connection (crossover cable) to firewall/gateway machine

Machine #2 (Red Hat 7.2 "firewall/gateway")
      -Two NICs
    One external IP eth0 (24.8.206.59)
    One internal IP eth1 (192.168.1.1)
      -Minimal services running on this machine
      -Packet filtering software running
      -Masquerading (NAT) running
 
Machine #3 (Red Hat 7.2 "the internet")
 -One NIC eth0 (external ip 24.8.206.1)
 -Apache webserver and ssh server running for demonstration purposes

-----------------------------------------------
Introduction:

The purpose of the discussion/demostration is to bring a typical Linux network setup into a meeting and discuss the principles involved in setup and administration.
Many specifics will left out, but the main principles will be discussed in some detail.
They are as follows-
     1)Basic Linux Network Setup (as described above)
     2)Packets
     3)Packet Filtering with Ipchains
     4)Network monitoring with tcpdump

--------------------------------------------------
--------------------------------------------------
1)Basic Linux Network Setup-
 A.Private Address space
 Class A- 10.0.0.0 Contains the most available ip addresses
 Class B- 172.16.0.0 Second most available ips
 Class C- 192.168.0.0 Least available ips- We have choosen this for our interal network. IE gateway/firewall 192.168.1.1 internal user 192.168.1.2
 B.Public Address space
 Pretty much anything except above ips
 These are the ips directly visible to the internet
 We have assigned these to our internet visible interfaces. IE gateway/firewall 24.8.206.59, internet 24.8.206.1
 C.Input/output
 Connection concepts
     Output must connect to an input and vice versa
     Due to the standardization of NICs we must use a "crossover" cable to connect two machines directly.
 D.Services that utilize the network
 Common network services (servers) on Linux firewall machines might be the apache webserver and ssh daemon.
 For our internal user they might be sendmail, pop, a web browser, an instant messaging client, etc.
 We must allow certain packets to be forwarded, denied and/or accepted to have a functional secure network.
We forward, deny or accept packets in our ipchains ruleset based on certain criteria.

Common ipchains examples
Forward-
/sbin/ipchains -A forward -s 192.168.1.0/24 -p tcp -j MASQ
/sbin/ipchains -A forward -s 192.168.1.0/24 -p udp -j MASQ
/sbin/ipchains -A forward -s 192.168.1.0/24 -p icmp -j MASQ
Deny-
/sbin/ipchains -A input -i eth0 -p tcp -s 0/0 -d 0/0 0:1023 -y -j DENY
Accept-
/sbin/ipchains -A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT

See ipchains howto for more info.

-------------------------------------------------
2)Packets-
 A.Packets are just chunks of data pakaged nicely for transport and inscribed with a "header".
 B.The three common protocols for packets are icmp, udp and tcp. The last (tcp) being the most common.
 C.TCP handshaking
  client sends syn
  server sends syn ack
  client sends ack
  server sends ack...
 D.The look of a packet
   run tcpdump to watch packets as they hit your default interface.
 E.Common port numbers
   less /etc/services for a description of common port uses
   "priveledged" ports 0-1023 are for root services
   "unpriveledged ports" 1024-65k are for non-root services
 F.Forwarding
  In /etc/rc.d/rc.local enter this line  echo 1 > /proc/sys/net/ipv4/ip_forward
  In firewall script of firewall/gateway macihine allow masquerading from internal users (The Debian internal user in our example)
       -A forward -s 192.168.1.0/24 -p tcp -j MASQ
       -A forward -s 192.168.1.0/24 -p udp -j MASQ
       -A forward -s 192.168.1.0/24 -p icmp -j MASQ
----------------------------------------------------
3)Packet Filtering with Ipchains-
  A.The "chain" filter concept
        -A packet attempts to pass by first rule. If successful, it attempts to pass by the second, third, etc. until it is accepted
        -A reject or deny rule drops the packet or "filters" it
  B.Default policy
     -Accept everything (the one we're demonstrating)
     -Deny everything (tighter security, more difficult to add services)
 C.Blocking packets for an accept everything firewall
     -Based on interface card
     -Based on ports
         priveledged range 0-1023
         unpriveledged range 1023 on up
     -Based on source ip
     -Based on your inteface's Input/Output stream
     -Based on the tcp handshake "flags"
     -Based on protocol
         tcp
         udp
         icmp
------------------------------------------------
4)Network monitoring with tcpdump-
   A.Setting the promiscuous mode for a NIC
   B.An example
   C.Using grep to filter out noise
   D.You may want to limit realtime network monitoring to the machine you are on with direct console access. Remote machines will go into infinite loop.
   E.The solution to the above problem is to output tcpdump to a file on your remote machines.

See Part II for more details on this