Wednesday, July 9, 2008

Linux Networking Tutorial

http://blacksun.box.sk



Linux Networking Tutorial

By: Ghost_Rider

(ghostrider@boxnetwork.net)



======

Index

======



.Index

.Intro

.Basics for networking:



- - Ethernet card

- What should I read?

- Detection

- Configuration

- Making Startup Script



- - LAN

- What should I read?

- Setting up LAN

- Making some configs



- - IP masquerading:

- What should I read?

- What is that?

- How does it work?

- Configuration

- Security



.Things you should also know:



- - Remote Port Fowarding

- What should I read?

- Why do I want this?

- Configuration

- Security



- - Transparent Proxy:

- What should I read?

- What is it?

- How can I support it?

- Configuration



- - NFS

- What should I read?

- What is it?

- Is it really usefull?

- Configuration

- Security



.Final notes



Intro

=====



Hello, here I am again, after sometime of inactivity I'm back to the article writing life, this time I'll talk about Linux Networking. This is the tutorial that was promissed when I was setting up a lecture about the same topic. The index you've just read was my plan file for that lecture, with some little alterations. In this tutorial my goals are to explain better, with examples, and giving places to get more information about each topic, so in a way we can say that each one, the lecture and the tutorial are standalone but still both can complete each other. Besides, due to

problems of time constraints, the lecture was kinda cut off short. I didn't have the time to talk anything about Transparent Proxy and the NFS topic which had to be described in about 7-10 lines. Here you'll find more indepth information on those two topics. I think it's enough of intro and we should just start getting our reading. Good reading...



Ghost_Rider







.Basics for Networking







Ethernet Cards

==============





What should I read?

-------------------





Setting up ethernet cards won't give you much problems, unless the NIC's

chip isn't supported. In this topic I advice you to read:



. Ethernet HOWTO - if you installed the HOWTOs check /usr/doc/

otherwise go to

http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO.html





Detection

---------



To be perfectly honest with you, all the ethernet cards I've used

got detected, and if you get a ethernet card not-detected I really

dunnow what to do, the only thoughts about that kind of problem is that

your card isn't supported, check section 5 at the ethernet-howto, still I

might be wrong.

But here is the way to see if your card is really detected:





. If your card is ISA as root type isapnp > ./dump (make sure there's no

file ./dump) now just go inspect the dump file, and check for the string

that defines your ethernet card like "Accton EN1666..." or you can just

check by card number. On boot-up right after the RAM check the ISA cards are detected by BIOS and you'll see something:



CARD 1 something

CARD 2 ethernet card bla bla bla



So you just have to check if card 2 is listen on isapnp.

If your ethernet card is listed by your isapnp kernel detected it.



. If you card is pci as root type cat /proc/pci > ./pci (once more make

sure there's no ./pci) and inspect the ./pci file looking for your ethernet

card. It should show up something like Ethernet Controller: ...



Remember even if your card is detected it doesn't mean that is

supported. We now know that our ethernet card is detected. Next step...





...Configuration

-----------------



To configure your card you have to know what kernel module supports your

ethernet card, the best way to know what module supports your card is by

knowing what chip it uses. Checking the documentation that comes with your

ethernet card might help. Otherwise, if no documentation is available or it

isn't documentated what kind of chip it uses, you can check section 5. of

the ethernet howto or read the help of each ethernet card kernel module they tell the major chips they support.

If it's ISA all this work might be reduced, since all ISA cards are

NE2000 compatible so you can just install the kernel modules for it and load ne.o module. On the otherhand PCI cards are not that regular, still if

you stick to cards from 3com, SMC (old accton) or realteak you'll be making

you kernel module selection much easier. If you are still thinking in buying your NICs (network interface cards, the ethernet card) I advice you to give a look at the ethernet howto and check for the supported cards.

I just have messed with actton cards. I have 2 ISA EN1666 which I had any problems at all setting them up and one EN2242 on my laptop which is PCI and uses DECchip, now the kernel module for DECchip support doesn't act well with this card so you have to download a newer version of that module and compile it. At the time I'm writting this article kernel 2.4.x (right now on 2.4.1) doesn't have the driver that supports it. (Search on google for EN2242 with linux if you need the module, you'll find a page that talks

about how to setup linux on a Omini HP laptop they have their the module

version that supports it).



So you finally found out that you module is that nice xpto module xpto.o

What you have to do is just load the module using modprobe.



root@ExampleBox: ~# /sbin/modprobe xpto

root@ExampleBox: ~# /sbin/lsmod

Module Size Used By

xpto xxxx 1



Your NIC's module is loaded so you now have a new interface the eth0, you can make sure of it doing



root@ExampleBox: ~# /sbin/ifconfig



lo: (...)



eth0: (...)



Or if you just checking the /proc directly doing



root@ExampleBox: ~# cat /proc/net/dev



And it also has to be listed the eth0 interface besides the lo.

But it's better to use ifconfig in my opinion, because you can check

card's status. To make sure your NIC is active check for a line like



UP BROADCAST RUNNING MULTICAST

or

BROADCAST MULTICAST



Now if your case is the 1st one there is no problem, the card is already

active, but if 2nd you have to start the card to do this you use once more

ifconfig giving the command



root@ExampleBox: ~# /sbin/ifconfig eth0 up



We now have a 100% working card, but we aren't, yet, able to send or

receive data from a LAN. This is because we still didn't gave an IP address

to the ethernet card. Since we are talking about a LAN@home we can use the

reserved IPs for LANs those are:



- 10.0.0.0/8

- 172.16.0.0/12

- 192.168.0.0/24



These address are unrouted from the internet, they are for intranet use

only.



- ------SIDE NOTE------

You already should know this but since I'm talking about IPs I'll also

talk about what are those /number after each ip. Well to understand it you just have to know 2 simple things, there are mainly 3 types of IP address:

- Class A which are IPs XXX.abc.abc.abc

- Class B which are IPs XXX.YYY.abc.abc

- Class C which are IPs XXX.YYY.ZZZ.abc

Where:

the upper case letters are the ones that represent the network they are called the NETWORK ID.

the lower case letters are the ones that define the host, they are called the HOST ID.



This means that in the same network all hosts will have the same network ID. Now if you realized in a IP X.X.X.X 0 < X < 255, and the higher value

that 1byte can store is, yes, 255. So each X is 1byte. Since 1 byte = 8 bits the /X number tells you how many bits are fixed that way you can know what network Class we are talking about without having it's netmask.

8 bits = 1 byte so the 1st octect if fixed the other 3 changes Class A

16 bits = 2 bytes so the 1st and the 2nd octect are fixed the other 2

changes Class B 24 bits = 3 bytes so the all octects are fixed except the last one Class C 32 bits = all octects are fixed, so this means we are talking about a single IP, no network now.

12 bits = 1bytes + 4bits this as no special Class name it's a type of

Class B it means that the 2nd octect can be between 16 and 32

- ---------------



Since we are talking about a simple LAN@home we gonna setup a Class C

address this will allow us to set hosts up to 253 hosts. More than enough.

So let's say we want to give the IP 192.168.0.1 to one of our boxes, once

more we would use ifconfig.



root@ExampleBox: ~/# /sbin/ifconfig eth0 192.168.0.1 netmask 255.255.255.0



After you type that command you'll probably have another routing entry on

your route table, still it's better to check



root@ExampleBox: ~/# /sbin/route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo



If the 192.168.0.0 entry wasn't automatically added you have to add it.



root@ExampleBox: ~# /sbin/route add 192.168.0.0 netmask 255.255.255.0 dev

eth0



And there you go, you have a fully configured ethernet card you can now

test your LAN. (will take care of this in the next topic LAN)







Startup Script

--------------





#!/bin/sh

# Simple Startup Script

# for linux networking tutorial

# by Ghost_Rider

# NOTE: if you wanna use this script change MODULE to your NIC's module

# and IP to the NIC's IP.



echo "Starting up Ethernet Interface"

/sbin/modprobe MODULE

/sbin/ifconfig eth0 IP netmask 255.255.255.0







LAN

===



What Should I read?

-------------------



. Networking HOWTO

If howtos were installed check /usr/doc/ and look for the howto dir or go to http://www.linuxdoc.org/HOWTO/Net-HOWTO/index.html





Setting up the LAN

------------------



You now have the computers configured each one with it's one 192.168.0.x IP and the route entry for 192.168.0.0 it's now time to connect the computers and see if everything is working. I'm assuming that you are using RJ-45 connectors (those ISDN plugs)instead of BNC (connectors like the ones from your TV cable).



Example 1:



Host1 eth0 (192.168.0.1) <---> eth0 Host2 (192.168.0.2)



Now this is a direct ethernet to ethernet connection. In this case

you'll have to use a crossover cable instead of a CAT3 or CAT5 cable. Why?



RJ-45 uses 2 wire pares. Check the following diagram to understand

why you have to use crossover

Connectors of each card:

------ + + ------- Where - and + are the polarity of each

------ - - ------- connector now since you can't connect + with +

------ + + ------- or - with - you'll have to make a crossover to

------ - - ------- make + connect to - so the signal could be

sent throught the line(this is

electricity/electronic).



Ok so you got the cable you connect both computers. Now try to ping the

other computer. Does it work? Good you now have a working LAN.

If it doesn't check if you haven't a firewall messing with the connection to make clear that the problem isn't from the firewall allow everything from eth0 interface:



root@ExampleBox: ~# /sbin/ipchains -A input -i eth0 -j ACCEPT



If it wasn't that, make sure you are using a crossover cable and make sure you ethernet card is really working (ping the ethernet interface from

the same host lo interface).





Now let's say that instead of just 2 hosts you want to make an LAN with 3

or 4, you can connect them directly to each computer, well actually you can

if you had NICs to make different interface so they can comunicate 2 by 2

but not even someone completly insane would do that. So you buy a HUB or a

Switch, the main difference between both is that HUB works under broadcast

and Switch doesn't. HUB are less expensive and they work fine in home LANs.

So now your network should be something like





Host 1 eth0 <--> HUB <--> eth0 Host 2

(192.168.0.1) | (192.168.0.2)

|

eth0

Host 3 (192.168.0.3)





Using HUBs you don't need to use crossover cables, instead you use CAT 3

or CAT 5 depending of your LAN speed. CAT 3 works at 10mbit/s CAT 5 works

at 10/100 mbit/s. If you are having problems do what was sayed about testing on the ethernet to ethernet connection example. (For the ones that are wondering what CAT stands for, it's not cat the animal, it's a category).



Congradulations you now have a working LAN!!!





Making some configs

- -------------------



Ok now let's say you ping the the IP 192.168.0.2 from host 192.168.0.1

everything goes just fine, but what about if you ping using 192.168.0.1

hostname? Unknown Host, right?. Well since we don't have any DNS server on our network ping can't resolve the hostname. So what we do is editing /etc/hosts this is the alias file so you can put something like



192.168.0.2 Hostname2

192.168.0.3 Hostname3



As mikestevens pointed on the lecture is better to list and before

the hostname the FQDN (Fully Qualified Domain Name) since we don't really

have a domain we'll call it local.

So our entries would now look like



192.168.0.2 Hostname2.local Hostname2

192.168.0.3 Hostname3.local Hostname3



Still I don't use FQDN on my LAN and never had problems. But some software might like to have the FQDN, well it's up to you. If you don't put the FQDN just remember that if you are having problems with some software might be it.

Now after editing you can now give the alias Hostname2 and it will be

resolved into 192.168.0.2.

Same thing can be done to your network address (192.168.0.0) you just have to edit /etc/networks and add an entry like



192.168.0.0 MYLAN





IP masquerading

===============



What should I read?

-------------------



.IP masquerading howto

As usual /usr/doc dir or

http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html



.ipchains howto

/usr/doc or

http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html



.ipchains man page

man ipchains



What is that?

-------------



IP masquerading is a NAT (Network Address Translation) system. But let's start from the beginning. When we were configuring the IP addresses I told you that we were using private ones if you set a package on the Internet to those IPs the routers won't know what to do, because those address are UNROUTABLE on the Internet.

Let's imagine that one of you boxes has dial-up access to the Internet, but you want all the the LAN to have it, IP masquerade is your saviour. The IP masquerading will operate like a router pretending to be the host that is requesting the data from the internet and when it gets the data it routes the packages to the internal IP address of our LAN box.





How does it work?

-----------------



Well basically a connection using IP masquerading is something like the

diagram below







INTERNET HOST <--ppp0--> masquerading host <--- eth0---> masqueraded host

(204.12.41.42) (195.35.12.33) (192.168.0.1) (192.168.0.3)



We'll get to the configuration of this baby soon, but first I want you to know how this really works.

The masqueraded host for example telnets to the INTERNET HOST, 204.12.41.42, since it's configure to have the masquerading host has it's gateway it sends the package to him expecting that he knows how to route it. The masquerading host receives a datagram like:



Source IP: 192.168.0.3

Destination IP: 204.12.41.42

Source Port: 1034

Destination Port: 23

rest of data



So what it does is opening a new connection to the Destination IP

using as new source port an Higher port like 33567. It now changes the

datagram so it may be read:



Source IP: 195.35.12.33

Destination IP: 204.12.41.42

Source Port: 33567

Destination Port: 23

rest of data



At the same time the masquerading host stores in a table, called the

masquerading table (in other words a database) the masqueraded host IP it's

source port and the new connection source port. So when he receives a

datagram on port 33567 that will look like:



Source IP: 204.12.41.42

Destination IP: 195.35.12.33

Source Port: 23

Destination Port: 33567

rest of data



The masquerading host will check it's database and will see that for

his local port 33567 he has the masqueraded host 192.168.0.3 and port 1034

so once more the masquerading host changes the datagram to look like:



Source IP: 204.12.41.42

Destination IP: 192.168.0.3

Source Port: 23

Destination Port: 1034

rest of data



And sends it to the masqueraded host which will receive the data

thinking that he was contacting directly with 204.12.41.42.

This is the principle of masquerading.

You are now thinking on services like ftp that a new connection is

originated from the remote host, well yes, that can give you troubles

with masquerading, afterall it had to have some problems. But the good thing is that there are already kernel modules to support such services. FTP, IRC DCC, Real Audio and some other services. The ones mentioned I managed to make them work. The others I never tried.





Configuration

--------------



.On the box that will be masquerading:



You have to re-compile your kernel with IP masquerading support and also

with firewall support.



Networking options -->



(...)

[*] IP: firewalling

[*] IP: Masquerading

--- Protocol-specific masquerading support will be built as modules.

[*] IP: ICMP masquerading

--- Protocol-specific masquerading support will be built as modules

(...)



Now you compile, if you never re-compiled it's better to check the

Kernel HOWTO (http:// ) and bootup with the new kernel. After this there

is just one more thing is to set the ipchains rule to masquerade packages

coming from your LAN that are going to internet hosts.



root@ExampleBox: ~# /sbin/ipchains -A forward -s 192.168.0.0/24 -d !

192.168.0.0./24 -j MASQ



If you already have a firewall script just add that line to you script,

otherwise check the firewall script example on the security section, or just do as in the example type on your console.

Just one more thing, IP forwarding is disabled by default so all this

work you have to echo "1" > /proc/sys/net/ipv4/ip_forward.



.On the masqueraded hosts



You have to add a default route using masquerading host as gateway

Beeing 192.168.0.1 the IP masquerading host you would type:



root@ExampleBox: ~# /sbin/route add default gateway 192.168.0.1



Besides of this you need to add the following entries to the file

/etc/resolv.conf



search ISP.com

nameserver IP



where:

ISP.com is your ISP domain, like telepac.pt, freeisp.com, teleweb.au...

IP is the ip of your ISP DNS server





And your done with configuration. You now can test IP masquerading on your

network. Do the following tests from a masqueraded host:



. ping masquerading host internal IP

. ping masquerading host external IP

. ping an external IP

. ping the same host but using hostname

. browse to a site



If it fails on the 1st you don't even have the network set correctly

check the LAN section, if it doesn't ping external IPs check if you really

add a default route if you get an error message like IP: No route to host

the default route wasn't set or it's misconfigured, re-check this section.

If it pings external IPs but doesn't work with hostnames you didn't set

your DNS server at /etc/resolv.conf re-check this section.





Congradulations you now have IP masquerading working on your LAN!!!





Security

--------



Even having your internal LAN protected by NAT, it's always good to

implement a good security policy on your internet gateway, ipchains, or the

new iptables for kernel 2.4.x will help you with this. Besides you already

needed to use it since you need to set the masquerading. This is by any

means a section about ipchains if you wanna learn about ipchains check it's

howto and man page.

Script follows



#!/bin/sh

# Example ipchains Script

# By Ghost_Rider

# For linux networking tutorial



IPCHAINS="/sbin/ipchains"

DNSSERVER="PUT UR DNS SERVER HERE"



# flush rules



$IPCHAINS -F input

$IPCHAINS -F output

$IPCHAINS -F forward



# Set policies



$IPCHAINS -P input DENY

$IPCHAINS -P output accept

$IPCHAINS -P forward DENY



# Accept all local traffic



$IPCHAINS -A input -i lo -j ACCEPT

$IPCHAINS -A input -i eth0 -j ACCEPT



# Deny private address comming from ppp0

# Attemps of spoof to use our host to masquerade



$IPCHAINS -A input -i ppp0 -s 10.0.0.0/8 -j DENY

$IPCHAINS -A input -i ppp0 -s 172.16.0.0/12 -j DENY

$IPCHAINS -A input -i ppp0 -s 192.168.0.0/24 -j DENY



# Let's set IP Masquerading



echo "1" > /proc/sys/net/ipv4/ip_forward

$IPCHAINS -A forward -s 192.168.0.0/24 -d ! 192.168.0.0/24 -j MASQ



# Allow DNS



$IPCHAINS -A input -i ppp0 -p tcp -s $DNSSERVER --sport 53 -j ACCEPT

$IPCHAINS -A input -i ppp0 -p udp -s $DNSSERVER --sport 53 -j ACCEPT



# Reject auth so you don't have to wait till timeout when sending mails



$IPCHAINS -A input -i ppp0 -p tcp --dport 113 -j REJECT



# Allowing ICMPs necessary

# 0 = echo reply

# 3 = Destination unreachable

# 11 = time exceeded



$IPCHAINS -A input -i ppp0 -p icmp --dport 0 -j ACCEPT

$IPCHAINS -A input -i ppp0 -p icmp --dport 3 -j ACCEPT

$IPCHAINS -A input -i ppp0 -p icmp --dport 11 -j ACCEPT



# Log everything else..

# Let's see what is on the next door



$IPCHAINS -A input -i ppp0 -j DENY -l





Remote Port Forwarding

======================



What should I read?

-------------------



.ipmasqadm man page





Why do I want this?

-------------------



If you want to allow people to access some services inside your LAN like

webservice or shell, instead of setting services on the firewall, you

redirect the connection to an inside host.

Why not to run services on the firewall? Well because running services

on the firewall will expose it, so you redirect the traffic to inside your

network. Ok, right now you are thinking that I'm stupid, I'm concerned

about the firewall but I'm routing data to inside the network which is

a greater risk. Well it's now time to introduce to you the concept of DMZ.

DMZ stands for De-Militarized Zone, a fancy term that started being used from the gulf war if I'm not wrong, but it also got ported to the networking language. DMZ is a subnet that has un-trusted hosts and has no contact to the trusted subnet. So right now our LAN will start having 2 subnets, both of them are being NAT, but one is still invisible and the other subnet will be acessible by the internet.

Since this is not the kind of network topology we set at our home, we

are probably talking about more than one registered internet IP, no more

dial-up but a set of IPs that are payed to be used, in this case the DMZ

won't need to be behind masquerading but will be assign public IPs. But we

will get to both network typologies the one where DMZ is also masquerade and

when DMZ isn't.





Configurations

- --------------



To support remote port forwarding you have to download an application

called IP masquerading additional modules administration (aka ipmasqadm)

written by Juan Ciarlante. For this application work you have to compile

kernel with masquerading special module support.



Network options -->



[*] IP: firewalling

[*] IP: masquerading

--- Protocol-specific masquerading support will be built as modules

[*] IP: ICMP masquerading

--- Protocol-specific masquerading support will be built as modules

[*] IP: masquerading special modules support

<M> IP: ipautofw masq support (EXPERIMENTAL)

<M> IP: ipportfw masq support (EXPERIMENTAL)

<M> IP: ip fwmarkk masq-forwarding support (EXPERIMENTAL)



If you don't see the option IP: masquerading special modules support

remember to see if you have selected to be prompted for code in development

since this feature is still experimental. To check this go enable:



Code maturity level options -->



[*] Prompt for development and/or incomplete code/drivers



When you enable this options the all the options listed will be shown.



After compiling, rebooting the new kernel and loading just ipportfw or

all the 3 modules (for what we are talking just ipportfw is required).

Now you can just nicelly type



root@ExampleBox: ~# ipmasqadm portfw -a -P tcp -L ppp-ip 80 -R 192.168.1.3

80



And then redirection will start to be done.





Security

--------



Now how it was said starting to run services inside your LAN can expose

to much your LAN. So it's time to start thinking in DMZ. Check the two

diagrams bellow.





Example 1:

------ (eth0) ---- DMZ

| 192.168.0.0/16 network

Internet --- ppp0 --- Router/Firewall ---

|

------ (eth1) ----- Trusted LAN

192.168.1.0/16 network



In this case our Router/Firewall will have 3 IPs, the internet IP, then the IP for the eth0 interface and the IP for eth1 interface. Now as you can both subnets are behind a masquerading host. The firewall will run ipmasqadm fowarding traffic like web service to our DMZ. This way even if a script kiddie roots one of those boxes he's inside the DMZ and since the trusted LAN is invisible from the DMZ (you have to deny everything from 192.168.0.0/16 to 192.168.1.0/16) the trusted LAN isn't in direct risk, of course you'll have to implement strong loggging and IDS (Intrusion Detectiong System) on the DMZ.

This kind of network topology is called 2 legs network.





Example 2:



Internet -- ppp0 -- Router/Firewall --- DMZ with registered static IPs

| (eth0)

Masquerading Host

| (eth1)

Trusted LAN



In this case the Router/Firewall host will be a normal routing host since

the DMZ will have static IPs registered from Internic, inside this DMZ

you'll have a box running no services the which will be the Masquerading

Host hidden behind this host there will be a trusted LAN, completly

invisible to the outside as always.





Transparent Proxy

=================



Since I actually never messed with Transparent Proxy I'll be short in

this section still giving the main topics to set things up, besides squid.



What should I read?

-------------------



.Transparent Proxy Mini howto

/usr/doc and look for the mini howto directory

or http://www.linuxdoc.org/HOWTO/mini/TransparentProxy.html





What is it?

-----------



Transparent Proxy is away that proxies connections without client

noticing. This means that if you browse to www.yahoo.com when this request

reachs your gateway it will be re-directed to another port where a proxy

service like squid will be active. The client thinks that it's exchanging

data with remote host but in the reality it's just exchanging data with the

gateway.





How can I support it?

---------------------



To support Transparent Proxy once more you'll have to re-compile your

kernel this time the main features to support are:



Networking Options -->



(...)

[*] IP: firewalling

[*] IP: Transparent Proxy support

(...)



Of course you'll probably enable mascarade on your host, to know which

options have to be enabled check the IP masquerade section.



Configuring

-----------



Finally to make Transparent Proxy work you have to add a redirection

action on ipchains just simply giving the command:



root@ExampleBox: ~# /sbin/ipchains -A input -p TCP --dport 80 -s

192.168.0.0/24 -j REDIRECT 8080



Then you just have to configure squid, honestly I never messed with it so

I really don't know what to tell you, but I've seen squid.conf file it's

full of information, read it and it will help configuring. Also look at the

transparent proxy mini howto.



NFS

===



What should I read?

-------------------



. NFS HOWTO

/usr/doc

or http://www.linuxdoc.org/HOWTO/NFS-HOWTO/index.html



. rpc.portmap man page



. rpc.mountd man page



. rpc.nfsd man page



. exports man page



What is it?

-----------



NFS stands for Network File System. Like I said in the lecture, once I

read a really simple definitition of NFS "it's like windows file sharing but better" and indeed it's a way of sharing HDs (totally or partially) inside a network. NFS is widelly used on networks where we have diskless boxes, or like in Beowulfs. Still you can just setup NFS on your local NFS to share some files between your computer, or like just have one /home directory and every single box of your LAN mounts that partition.





Is it really usefull?

---------------------



Well... If you are in a small LAN like the ones we set at home, and each

box you still want to have each computer working without any essential OS

part like /var or /home mounted from one single host, it might not be really usefull. If you are thinking in just setting up NFS to share some files you have and you want to copy them from box to box I tell that it's better to use FTP because of 2 main reasons speed and security. Actually NFS is slow as hell, and well security it's not it's best also. I know about a couple of worms that use vunerabilities in the portmap to spread. Of course if you start running NFS on your LAN the daemons used will be the latest ones...still we know that the code is buggy as hell.





Configuration

-------------



You have to compile your kernel with NFS support to add NFS support to

your kernel enable the option



Filesystems -->

Network File Systems -->

<*> NFS filesystem support

(...)



Compile and you are ready for playing with nfs.

There are 3 main files that allow you to configure NFS at your will:



/etc/hosts.allow

/etc/hosts.deny

/etc/exports



. hosts.allow

This file holds which IPs have access to the portmap services.

This file has the syntax SERVICE : ALLOWED IPs

So in our case we would read in the /etc/hosts.allow something like



rpc.portmap : 192.168.0.0/24

rpc.nfsd : 192.168.0.0/24

rpc.mountd : 192.168.0.0/24



. hosts.deny

This file holds which IPs don't have access to the portmap services. When portmap is queried, it grabs the IP, first it checks

hosts.allow if it's there it accepts, if it isn't check hosts.deny file if

it's there it will deny it, otherwise if not listed in both it will accept

the connection. The syntax it's the same as hosts.allow, so since we don't wanna accept any IP that is not listed on hosts.allow we can just add a single entry to host.deny were we read



ALL : ALL



This will deny everything that didn't match on the hosts.allow file.



. exports

Finally we have the exports file, this file holds which directories

can be exported and to where and with what options.

The syntax of this file is:

directory IP(options)



Where options can be:



noaccess: just the dir listed will be mounted the subdirs won't

rw: will give read and write permissions when mounted

ro: will give read only permission when mounted

root_squash: users with UID and GID iqual to 0 will be mapped

for the anonymous UID and GID

insecure: the source port can be any of the 65536

secure: the source port have to be a reserved port (<1024)



This is not by any means a complete list of options still I think

they are the most used. To have an exaustive list of available options check exports man page.





Security

--------



As I told you NFS services are buggy and you are making your LAN vulnerable when using this kind of services, so make sure your firewall is blocking the portmap port (111) tpc and udp. And remember to allow just your LANs hosts and deny all the rest on those hosts.allow and hosts.deny.

As a last advice, if you don't really need NFS don't use it.





Final notes

===========



Well this is the end, I hope you enjoyed it and learned something. Remember to set secure firewall policies, logging and never forget to be paranoid :) If you are planning on installing linux right now, go get tripwire it will also help you a lot. Don't install tripwire after you have exposed your lan to the Internet, because of the chance of compromise, which would render tripwire useless. Also the most important thing, have fun while setting all this up. See you soon, I got some ideas to write about.



Ghost_Rider



root@ExampleBox: ~# shutdown -h now

(...)

Power Down



Now it's time to say *PUF*



EOF







No comments:

க்ரீன் பீஸ் மசாலா - Green peas Masala

*க்ரீன் பீஸ் மசாலா*     பச்சைப்பட்டாணி - 250 கிராம்     (அல்லது) காய்ந்த பட்டாணி - 150 கிராம்     பெரிய வெங்காயம் - 2     தக்காளி - 2 அல...