Update of /cvsroot/leaf/doc/docmanager
In directory sc8-pr-cvs1:/tmp/cvs-serv2270
Added Files:
docid_10171.html docid_12020.html docid_12525.html
docid_12592.html docid_13313.html docid_13427.html
docid_14274.html docid_14491.html docid_14504.html
Log Message:
Pending: review, xhtml cleanup, header+footer addition, etc.
--- NEW FILE: docid_10171.html ---
<strong>Audience</strong>
This HOW-TO was written with expert users in mind.
All standard disclaimers apply.
<strong>Preparing the distro</strong>
First make sure you have your Bering floppy distro already working.
You may want to take one or more of the following actions:
- Change root password.
- Generate the ssh keys, if you will use it.
Thoroughly check each and every aspect of your distro.
<strong>Downloading required packages</strong>
Note: I use Windows to develop. Linux users should have no problem in following.
You will need some files from two packages, Syslinux and Cdrtools.
This was where I found the Syslinux version I used to make this HOW-TO:
http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-1.67.tar.gz
This was where I found the cdrtools version I used to make this HOW-TO:
ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha/win32/cdrtools-1.10-win32-bin.zip
>From these packages, we will need only three files:
- isolinux.bin, from syslinux
- mkisofs.exe, cygwin1.dll from cdrtools
<strong>Additional files...</strong>
<i>As of this time, I'm not an official LEAF project develloper, so I have no space
yet to host these packages.
I hope this will change soon.
This doc will be updated to include the links</i>
You will need an ide-enabled kernel and the corresponding initrd.lrp package.
<strong>Creating directory structure</strong>
Create this structure:
<pre>
root
|
--- BCD
|
--- x
</pre>
<strong>Copying files</strong>
Copy mkisofs.exe and cygwin1.dll to BCD.
Copy isolinux.bin to BDC\x
Copy all files from the floppy(ies) to BCD\x
Delete ldlinux.sys from BCD\x
In BCD\x, rename syslinux.cfg to isolinux.cfg
Edit BCD\x\isolinux.cfg, change references from /dev/fd0u1680 to /dev/cdrom
Copy the ide-enabled kernel and initrd.lrp to BCD\x
<strong>Making the CD</strong>
You may also want to create a batch.
Go to the BCD directory and run this command:
mkisofs -o bering.iso -b isolinux.bin -c isolinux.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-hide isolinux.cat -hide isolinux.bin x
You should have now a BERING.ISO, burn it into a CD and test it.
Note: use a cd r/w :)
<strong>Support:</strong>
Well...
So support will be done through the [leaf-devel] mailing list.
<strong>Thanks:</strong>
Charles Steinkuehler for creating the *stein series,
Eric Wolzak & Jacques Nilo for the Bering series,
my friend Jo�o Alves for helpfull linux support,
all other regular LEAF developpers and
Mike Noyes for keeping up his excelent work on the LEAF site.
--- NEW FILE: docid_12020.html ---
Depending on how much work you want to do....
<br><br>
Here's sources of parts (prices on 7/13/02 without shipping):<br>
www.pcengines.com Compact Flash to IDE converter (use a 8MB CF card to boot off of)
$13 or $20 depending on model
<br><br>
www.bananapc.com 8mb CF Card $7.56
VIA c3 700Mhz plus Soyo 7VEM Mobo and HSF $62.67
and the fan shouldn't be a necessity.
<br><br>
www.computer123.com Encore 10/100 (Realtek) $4.00
<br><br>
www.buyaib.com Generic pc133 64MB $11.00
<br><br>
Of course the real pain is a small PSU and case... Good luck, I haven't had any. A
PacTec dm-3 or dm-4 might do, it's an all ABS plastic case you can customize yourself.
<br><br>
Now if you want to spend more money but get a "pretty" solution complete with case:<br>
www.caseoutlet.com has an ITX size setup that includes:<br>
VIA 533Mhz CPU, <br>
Motherboard with onboard video, sound, VIA LAN 10/100, and 1 PCI slot, <br>
External transformer power supply,<br>
and it comes in Black or Beige. Price: $189<br>
<br>
Toss in the CF to IDE adapter, 8MB CF card, and 64MB of memory and you have a complete
machine. Add a second ethernet (and look real close at the case, looks like it's got
an ethernet port punchout inline with there the PCI slot is should be easy work) and
you have a firewall or router<br>
<br>
<br>
If I new how to code an HTML comment off the top of my head I would... But anyhow,
Leman Strout mailto: [EMAIL PROTECTED] signing off.<br>
--- NEW FILE: docid_12525.html ---
When you configure 2 internal networks and you have DNSCache running and you have
DNSCache accept from 192.168 (And therefore both internal networks) it still won't
work. Why? When you are on network 192.168.0 and your DNSCache is configured with IP
address 192.168.0.254 it wil work on the 192.168.0 network but it won't work on the
192.168.1 network. If you then configure the IP to 192.168.1.254 then it's the same
the other way around.
Solution:
Configure your IP in DNSCache to 192.168.0.254, then your DNS-server to 192.168.0.254
on both your 192.168.1 network and your 192.168.0
I couldn't find a way to configure DNSCache to 2 IP addresses and I didn't have any
trouble in Dachstein but Bering seemed to have the problem and this is an easy
solution (if your 2 networks are routed together)
--- NEW FILE: docid_12592.html ---
<HTML><HEAD>
<link HREF="http://www.monkeynoodle.org/global_css"; rel="stylesheet" type="text/css">
<TITLE>LRP Firewall FAQ</TITLE></HEAD><BODY>
<TABLE WIDTH=100%>
<TR>
<TD>
<A HREF="http://zapatopi.net/afdb.html";><IMG ALIGN=LEFT
SRC="/alumbutn.jpg" ALT="AFDB"></A>
</TD>
<TD>
<IMG ALIGN=RIGHT SRC="green-logo-small.jpg" ALT="logo">
</TD>
</TR>
</TABLE>
<P>
LRP Firewall FAQ<BR>
Jack Coates, <A HREF="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A>
<HR>
Revision History:<BR>
12-5-00, lengthened and modified an email, nothing LRP specific yet.<BR>
1-16-01, discussion of proxy servers on firewalls.<BR>
9-10-01, typos, URLs.<BR>
<HR>
<P>
The proper policy is default deny, then open up required ports if needed.
While this sounds overly simplistic, it's the best policy possible. The
weakness comes about in the ports that are required. If you really want to
know more, <A HREF="http://www.oreilly.com/catalog/fire2/";>Building Internet
Firewalls</A> by Chapman & Zwicky is a good
start. In the meantime, here's a quick overview.
<P>
When a client wants to talk to a server, generally it will choose a random
port between 1025 and 65535 as the source port. Destination is the
server's well known service port, such as 80, 25, 443, &c. There are
exceptions and this isn't a published standard, but most of the time
that's the way it works in real life.
<P>
If you want to make your network more secure, you might use Access Control
Lists (ACL's) to build a policy that denies traffic. Depending on the platform
you're working with, this might mean ipfwadm statements, ipchains statements,
or Cisco IOS commands. Unfortunately, if you want to make a server available
you can't predict where the clients will be or what source port they'll use,
so you have to write a rule that allows any client to come from any port
1025:65535 into your port 80.
<P>
If you don't like the idea of doing that, you might implement a stateful
inspection engine, such as Check Point's FireWall-1 or Cisco's CBAC. Those
work by maintaining a table of known sessions:
<table border=1>
<tr>
<td>outside</td><td>firewall</td><td>inside</td>
</tr>
<tr>
<td>SYN request, 1025 -> 80</td><td></td><td></td>
</tr>
<tr>
<td></td><td>does policy allow connection to port 80? If yes, then open 1025 <->
80, forward this packet.</td><td><td>
</tr>
<tr>
<td></td><td></td><td>SYN-ACK, 1025 <- 80</td>
</tr>
<tr>
<td></td><td>session is real, so enter it into the state table. Future traffic on TCP
1025 <- 80 can be accepted without inspection until timeout.</td><td></td>
</tr>
</table>
<P>
Only traffic that is from the originally initiated session will be allowed
in. Theoretically this means that the session will be harder (though not
impossible) to hijack, though in real life it means very little. Hijacking
a session is too hard and has too little payoff compared to the real
threats: distributed denials of service (DDoS), breaking into servers, and
snarfing useful information out of the traffic stream. More on these
later. The stateful inspection engine vendors will also tell you that stateful
inspection allows the firewall to "make sure that [telnet] is really [telnet]"
or even "make sure that the commands in the traffic stream are proper [telnet]
commands." The first statement is marketingspeak for "deny client ports that
are known service ports." In other words, here's a possible attack:
<table border=1>
<tr>
<td>outside</td><td>firewall</td><td>inside</td>
</tr>
<tr>
<td>SYN request, 21 -> 23</td><td></td><td></td>
</tr>
<tr>
<td></td><td>policy allows connection to port 23,so open 21 <-> 23, forward this
packet.</td><td></td>
</tr>
<tr>
<td></td><td></td><td>SYN-ACK, 21 <- 23</td>
</tr>
<tr>
<td></td><td>session is real, so enter it into the state table. Future traffic on TCP
21 <- 23 can
be accepted without inspection until timeout.</td><td></td>
</tr>
<tr>
<tr>
<td>Kill telnetd with a buffer overflow and initiate FTP connection from inside
server.</td><td></td><td></td>
</tr>
</table>
<P>
So Check Point will deny SYNs from source ports that are well known service
ports. Of course, since well-known service ports are merely a convention and
TCP connections can be made from any port to any port, I fail to see how this
behavior, in and of itself, provides very much protection against a tool like
<A HREF="http://www.monkey.org/~dugsong/ftp-ozone.c";>ftp_ozone.</A>
<P>
Now if the firewall was actually able to analyze the payload of packets for
valid commands in the service which is supposedly being allowed, that would
be pretty keen and would make the second Check Point marketing statement
accurate. However, it's not true and won't be true any time soon because doing
so would soak performance, even if it were possible to implement. If you want
to analyze the application level payload you have to use a proxy, not a
stateful inspection engine.
<P>
One cool thing that is very simple which Check Point does is deny incoming
packets which aren't SYN packets, unless they match an entry in the state table.
These generate a log message, "received packet from unknown established TCP
session." (This functionality is broken by service pack 2 to the 4.1 release,
unfortunately.) Categorically denying this sort of traffic is a good idea, so
let's all look forward to trying out the stateful inspection engine in kernel
2.4. Another nice thing Check Point trains its admins to do is implement a
"stealth rule." This rule silently drops any packet which is destined for one
of the firewall's interfaces. This can and should be done with LRP as well.
<P>
If you really want tight control, you use a proxy server. This is a server
that provides the same service(s) that you wanted to make public, but it
relays the traffic between the client and the real server. By making the
proxy server tight and featureless, the security admin can reduce the
foothold presented to a hacker. In a DoS attack, the solution fails safe
by crashing the proxy, not real systems. However, proxies are relatively slow,
difficult to configure, and usually don't support the latest and greatest
bells and whistles. Both CPFW and Cisco provide some limited proxy service
for common things like SMTP and HTTP. It is architecturally flawed to do so,
and the only reason they do it is to provide a lower price. The "single box for
a single purpose" model has been evolved through experience, not vendor whim.
I cannot stress enough that you should be very careful when choosing proxy
software. If the proxy itself is vulnerable to buffer overflow, you've just
given the bad guys a root shell on your firewall with access to the networks
that the firewall is supposed to protect. If you're going to use a proxy,
<STRONG>INSIST</STRONG> on a well audited open source platform. If the network
you're protecting is valuable, I recommend using an <A HREF="http://www.openbsd.org";>
OpenBSD</A> server with <A HREF="www.postfix.org">Postfix</A>
for the SMTP and another OpenBSD server with <A HREF="http://squid.nlanr.net";>
Squid</A> for the HTTP. Using commercial software because it is enough to show
due diligence may make your lawyers happy, but it won't keep out the bad guys.
Commercial security software may or may not be safe and if you get the right
people to talk to you off-the-record, the companies involved will admit it.
Quality of the software and market capitalization have no correlation.
<P>
If you're not yet fully convinced that putting a proxy onto your firewall box
or border router is a bad idea, think about this. Even if the proxy software
you want to use is certifiably 100% bug free and otherwise invulnerable to the
common buffer overflow (snicker), it is still a single process operating on a
server/router/whatever which has other things to do (e.g. analyzing and passing
or denying traffic). This means that events which cause high CPU utilization or
RAM utilization will take away from the effectiveness of your firewall. It
also means that your firewall needs to receive traffic on the ports which the
proxy application listens to, so bye-bye stealth mode.
<P>
Now, here's how these solutions stack up against the real world attacks:
<P>
<UL>
<LI>DDoS: There are two general families out there, SYN flooders and bandwidth
hogs. Flooders are elegant tools which exploit a poorly considered
implementation choice or protocol flaw to consume the resources of a piece of
equipment. Hogs are brute-force tools that simply use hardware to overpower
hardware. <I>For the detail-oriented, I'm grouping frag-bombers like rape.c
under SYN flooders, even though the plumbing is different, because the intent
is the same.</I></LI>
<UL><LI>ACLs are no defense against SYN flooders, because they don't monitor
TCP connection status. Bandwidth effects can be theoretically minimized by
use of QoS tools (WFQ and WRED in Cisco, kernel 2.2 and iproute2 in Linux), but
it's an escalation game. Sooner or later they'll get enough TFN nodes to take
your site down.</LI>
<LI>Stateful inspection engines can help a little against SYN flooders.
Both CPFW-1 and CBAC have some simple DoS prevention tools, but they only
work against a single attacker at a time. Search for Tribe Flood Network
and Trinoo for more info.</LI>
<LI>Proxy servers will fall on their faces in a SYN flood. That's what they're
supposed to do, it's called failing safe. Personally, I'd rather see it
happening on a dedicated server in a DMZ than in the firewall's process
space.</LI></UL>
A common mistake is to assume that DoS isn't that big of a deal since the pipe
to the Internet is low bandwidth and therefore won't be enough traffic to crash
a server or anything. Setting aside the fact that for many companies the
Internet connection is as important as the phones, this attitude fails to take
into account that the ISP may take corrective action (up to cutting you off
permanently or billing you for the hours required to isolate and stop the
attack). The other mistake in the dismissal of DoS attacks is the assumption
that attacks are originating from outside. Disgruntled employees are just as
capable of running evil tools as bored teenagers, and have much better
motivation and bandwidth. Don't underestimate DoS tools -- they're simple, but
so is a club.
<LI>
Breaking into servers: An alarmingly large amount of software will crash
if you feed it too much information or unexpected information. Frequently
when the software crashes it leaves its network ports open and a command
prompt with its permissions waiting to be accessed. Servers may also allow
remote execution of arbitrary code through a number of exploits. Search
<A HREF="http://www.securityfocus.com/";>www.securityfocus.com</A> and
<A HREF="http://www.rootshell.com/";>www.rootshell.com</A> for some examples,
but if you don't see your software there, it may not mean anything. Generally
a problem or exploit shows up in public for one of four reasons: the
discoverer is a security professional who wants to help the vendor or get
recognition, or the discoverer is a hacker/cracker who wants to embarrass the
vendor or get recognition. Ask yourself this: if you were cracking into
systems for fun and profit, would you sacrifice your best tools into a public
arena where administrators, vendors, and other crackers could get at them? So,
let's return to how our defensive tools stack up against software exploits:
<UL>
<LI>ACLs are no defense.</LI>
<LI>Stateful inspection engines are no defense.</LI>
<LI>Proxy servers could theoretically be able to defend against some attacks
by doing bounds-checking, but I'm not aware of any actual implementations that
actually do so.</LI></UL>
Server software can be thought of as the plate glass window at a store.
There's no way to prevent someone throwing a rock and breaking it, but you
can put an alarm on the window and/or bars behind it. By securing the rest
of the server system, using good passwords, avoiding clear text protocols,
using <A HREF="http://www.tripwire.org";>Tripwire</A> and the
<A HREF="http://www.tripwire.com";>NT equivalent,</A> using an
<A HREF="http://www.lids.org";>IDS</A> and
<A HREF="http://www.ethereal.com";>other </A>
<A HREF="http://www.snort.org";>management </A>
<A HREF="http://www.insecure.org/nmap";>tools</A>
one can prevent <A HREF="http://www.monkey.org/~dugsong/dsniff";>a lot of </A>
<A HREF="http://www.bo2k.com";>damage</A> from taking place.</LI>
<LI>
Snarfing useful information: If the hacker can get access to a machine
long enough to download some software, he can scan the network segment and
discover what machines are connected, what protocols they're using, what
operating systems they run, and in some cases what versions of certain
programs are in use. Given more time the local or domain password file can be
cracked (and no, Windows domain passwords are not safe). If clear text
protocols are in use, such as POP3 and Telnet, he can snarf passwords out of
them. He can also grab files from the wire if they're passed with NFS or SMB.
Switched architecure is the best way to slow this process down, though some
switches are vulnerable to attacks which will break down the boundaries between
VLANs.</LI></UL>
<P>
To summarize, you wouldn't see much benefit from switching away from Linux
Router Project onto a commercial firewall package for security policy
implementation. While it is theoretically tighter to use a stateful inspection
engine, the true value to a package like Check Point is in the management GUI,
support channel, and added services such as VPN and virus scanning.
<P>
Jack Coates<BR>
<A HREF="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A>
<TABLE WIDTH=100% CELLPADDING=2 CELLSPACING=2>
<TR>
<TD>
<P><B><I><FONT SIZE=2>Last modified: Mar 19, 2002 8:24 pm.
<BR><A HREF="mailto:[EMAIL PROTECTED]";><FONT
COLOR="#800040">Contact me.</A></FONT></I></B></P>
</TD>
<TD>
</TD>
</TR>
<TR>
<TD>
<a href="http://www.zope.org/Credits"; target="_top"><img
src="http://www.monkeynoodle.org/p_/ZopeButton"; width="115" height="50" border="0"
alt="Powered by Zope" /></a>
</TD>
<TD>
<P ALIGN=RIGHT><A HREF="http://www.apache.org";><IMG
SRC="apache.gif"></A></P>
</TD>
</TR>
</TABLE></BODY></HTML>
--- NEW FILE: docid_13313.html ---
Hi...
Im new to this LRP stuff. I have a home network and I want each computer to run on
the internet. I want to use IRC (dalnet) to chat and so forth. But you need and
ident for that to work... I also have problems with DCC chating and sending. If
anyone can help me with this it would be greatly apreciated. My e-mail is
[EMAIL PROTECTED]
I currently am running Dachstein on a dynamic internet.
Thanks
--- NEW FILE: docid_13427.html ---
Can anyone help? I want to connect to my office via VPN, but I get no responce back
through the dachstein-v1.0.2-1680.exe image. I get internet and all my regular stuff.
Thanks.
--- NEW FILE: docid_14274.html ---
http://www.lex.com.tw/index1.htm
Very nice hardware available there.
http://www.mini-itx.com/
http://www.linitx.com/
The first link is probably the best. They have a system with 1x10/100/1000, 2x10/100,
Wireless, Disk-on-chip and a CompactFlash slot. And it's fanless to boot!
Good luck.
--- NEW FILE: docid_14491.html ---
PK
--- NEW FILE: docid_14504.html ---
<h2>Getting lshd to work</h2>
<p>LSH is a free (GPL license) implementation of the SSH version 2
protocol and a replacement for OpenSSH. The daemon package lshd.lrp
is small enough, to add it to a standard Bering-uClibc floppy
image. Anyway, to get it up and running you have to build keys on
your router. The lshkey package is far too big to fit onto the
floppy but it's only needed once. Read on, and you'll see what has
to be done to have a secure shell added to the Bering uClibc floppy
distro.</p>
<h3>Add lshd.lrp to the floppy</h3>
Mount your Bering-uClibc image and copy lshd.lrp.
<pre>
mount /dev/fd0u1680 /floppy
cp lshd.lrp /floppy
umount /floppy
</pre>
Take a second floppy, assumingly a normal floppy and copy
lshkey.lrp to it.
<pre>
mount /dev/fd0 /flopppy
cp lshkey.lrp /floppy
umount /floppy
</pre>
Now boot your router with the Bering-uClibc floppy. If done, login.
Don't worry about an error message from lshd during boot. It'll go
away after the next step.
<h3>Generate the keys</h3>
You have to generate keys for lshd, to get it up and running. This
has to be done once, the keys will be saved in the lshd package
lshd.lrp In short you have to load lshkey.lrp from another floppy
(see above), generate the keys, save lshd.lrp and restart lshd. If
you know how to do it, stop reading and just do it, otherwise
follow the recipt:
<p>After login, quit lrcfg, now you are on the shell prompt. Remove
the boot disk, insert the second disk and type:</p>
<pre>
cd /
mount /dev/fd0 /mnt
cp /mnt/lshkey.lrp .
umount /mnt
tar -xvzf lshkey.lrp
/usr/bin/makekey
</pre>
The last command may take a while. Once it's ready, remove the
floppy and insert your Bering-uClibc floppy again. Save with lshd
as usual with
<pre>
lrcfg
</pre>
Now you are ready to reboot or restart lshd from /etc/init.d
<h3>Copy Files to the router with lcp</h3>
lsh comes with a scp like command named lcp. Note that this is
<b>NOT</b> compatible to the scp command from openssh! But you can
copy files from linux/unix systems using <a
href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/src/bering-uclibc/contrib/lcp";>
this version of lcp</a>, it works with openssh. Just copy it to
/usr/bin on your machine and use it like scp:
<pre>
lcp /home/test/lcp.lrp router.mynetwork.net:/root
</pre>
Their is one pitfall for users that normally use scp, you have to
provide a directory name when using lcp, e.g.
<pre>
lcp /home/test/lcp.lrp router.mynetwork.net:
</pre>
does <b>not</b> work with lcp (with scp it would).
<p>Thanks to Ewald Wasscher, who build the lsh-packages first.</p>
<p><font size="-1">11/ 2002</font></p>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Leaf-cvs-commits mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-cvs-commits
