Update of /cvsroot/leaf/doc/docmanager
In directory sc8-pr-cvs1:/tmp/cvs-serv18814
Modified Files:
docid_10171.html docid_12525.html docid_12592.html
docid_14504.html
Log Message:
processed and activated
Index: docid_10171.html
===================================================================
RCS file: /cvsroot/leaf/doc/docmanager/docid_10171.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** docid_10171.html 2 Feb 2003 19:00:19 -0000 1.1
--- docid_10171.html 8 Mar 2003 20:47:27 -0000 1.2
***************
*** 1,42 ****
! <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
--- 1,38 ----
! <!-- Title: HOW-TO create a Bering boot cd -->
! <!-- Short description: Expert users only :) -->
! <!-- Last modified: $Id$ -->
! <!-- DocManager ID: 10171 -->
! <h3>HOW-TO create a Bering boot cd</h3>
! <p><em>Authors:  <br />
! Revision:  <br />
! Date:  2003-03-08</em></p>
! <hr />
! <p style="margin-top: 0cm; margin-bottom: 0cm">
! <strong><a href="http://leaf-project.org/pub/doc/docmanager/docid_10171.html";>
! Print Document</a></strong></p>
! <hr />
! <!-- begin document body -->
! <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> <em>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</em> You will need an ide-enabled
! kernel and the corresponding initrd.lrp package. <strong>Creating
! directory structure</strong> Create this structure:
<pre>
root
***************
*** 46,86 ****
--- 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.
!
--- 42,69 ----
--- 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.
! <!-- end document body -->
! <hr />
! <p style="margin-top: 0cm">If you still have questions or concerns
! regarding this document, please feel free to either
! <a href="http://lists.sourceforge.net/lists/listinfo/leaf-user";>post
! on the mailing list</a> or
! <a href="/tracker/?func=add&group_id=13751&atid=213751">submit
! a support request</a>. A member of the LEAF community will be glad
! to assist you further.</p>
Index: docid_12525.html
===================================================================
RCS file: /cvsroot/leaf/doc/docmanager/docid_12525.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** docid_12525.html 2 Feb 2003 19:00:21 -0000 1.1
--- docid_12525.html 8 Mar 2003 20:47:27 -0000 1.2
***************
*** 1,6 ****
! 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)
--- 1,38 ----
! <!-- Title: Bering - DNSCache on 2 internal networks -->
! <!-- Short description: Why DNSCache doesn't work on 2 internal networks -->
! <!-- Last modified: $Id$ -->
! <!-- DocManager ID: 12525 -->
! <h3>Bering - DNSCache on 2 internal networks</h3>
! <p><em>Authors:  <br />
! Revision:  <br />
! Date:  </em></p>
! <hr />
! <p style="margin-top: 0cm; margin-bottom: 0cm">
! <strong><a href="http://leaf-project.org/pub/doc/docmanager/docid_12525.html";>
! Print Document</a></strong></p>
! <hr />
! <!-- begin document body -->
! <p>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.</p>
! <p>Solution:<br />
! 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</p>
! <p>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)</p>
! <!-- end document body -->
! <hr />
! <p style="margin-top: 0cm">If you still have questions or concerns
! regarding this document, please feel free to either
! <a href="http://lists.sourceforge.net/lists/listinfo/leaf-user";>post
! on the mailing list</a> or
! <a href="/tracker/?func=add&group_id=13751&atid=213751">submit
! a support request</a>. A member of the LEAF community will be glad
! to assist you further.</p>
Index: docid_12592.html
===================================================================
RCS file: /cvsroot/leaf/doc/docmanager/docid_12592.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** docid_12592.html 2 Feb 2003 19:00:22 -0000 1.1
--- docid_12592.html 8 Mar 2003 20:47:27 -0000 1.2
***************
*** 1,286 ****
! <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>
!
--- 1,285 ----
! <!-- Title: Firewall FAQ -->
! <!-- Short description: Is LEAF a good firewall? -->
! <!-- Last modified: $Id$ -->
! <!-- DocManager ID: 12592 -->
!
! <h3>Firewall FAQ</h3>
! <p><em>Authors:  Jack Coates<br />
! Revision:  <br />
! Date:  2002-03-19</em></p>
! <hr />
! <p style="margin-top: 0cm; margin-bottom: 0cm">
! <strong><a href="http://leaf-project.org/pub/doc/docmanager/docid_12592.html";>
! Print Document</a></strong></p>
! <hr />
! <!-- begin document body -->
! 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>
! <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>
! <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>
! <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:</p>
! <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>
! <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:</p>
! <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>
+ <td></td></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>
! <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>
! <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>
! <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>
! <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>
! <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. <em>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.</em></li>
! <li style="list-style: none">
! <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>
! <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>
! <!-- end document body -->
! <hr />
! <p style="margin-top: 0cm">If you still have questions or concerns
! regarding this document, please feel free to either
! <a href="http://lists.sourceforge.net/lists/listinfo/leaf-user";>post
! on the mailing list</a> or
! <a href="/tracker/?func=add&group_id=13751&atid=213751">submit
! a support request</a>. A member of the LEAF community will be glad
! to assist you further.</p>
Index: docid_14504.html
===================================================================
RCS file: /cvsroot/leaf/doc/docmanager/docid_14504.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** docid_14504.html 2 Feb 2003 19:00:23 -0000 1.1
--- docid_14504.html 8 Mar 2003 20:47:27 -0000 1.2
***************
*** 1,4 ****
! <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
--- 1,18 ----
! <!-- Title: lshd HowTo -->
! <!-- Short description: v 1.0 by Bering-uClibc team -->
! <!-- Last modified: $Id$ -->
! <!-- DocManager ID: 14504 -->
!
! <h3>lshd HowTo</h3>
! <p><em>Authors:  Bering-uClibc team<br />
! Revision:  1.0<br />
! Date:  2002-12-28</em></p>
! <hr />
! <p style="margin-top: 0cm; margin-bottom: 0cm">
! <strong><a href="http://leaf-project.org/pub/doc/docmanager/docid_14504.html";>
! Print Document</a></strong></p>
! <hr />
! <!-- begin document body -->
! <h3>Getting lshd to work</h3>
<p>LSH is a free (GPL license) implementation of the SSH version 2
protocol and a replacement for OpenSSH. The daemon package lshd.lrp
***************
*** 9,17 ****
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
--- 23,28 ----
to be done to have a secure shell added to the Bering uClibc floppy
distro.</p>
! <h4>Add lshd.lrp to the floppy</h4>
! Mount your Bering-uClibc image and copy lshd.lrp.
<pre>
mount /dev/fd0u1680 /floppy
***************
*** 19,26 ****
umount /floppy
</pre>
-
Take a second floppy, assumingly a normal floppy and copy
! lshkey.lrp to it.
!
<pre>
mount /dev/fd0 /flopppy
--- 30,35 ----
umount /floppy
</pre>
Take a second floppy, assumingly a normal floppy and copy
! lshkey.lrp to it.
<pre>
mount /dev/fd0 /flopppy
***************
*** 28,38 ****
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
--- 37,44 ----
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.
! <h4>Generate the keys</h4>
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
***************
*** 41,48 ****
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 /
--- 47,52 ----
***************
*** 53,90 ****
/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>
--- 57,92 ----
/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
! <h4>Copy Files to the router with lcp</h4>
lsh comes with a scp like command named lcp. Note that this is
! <strong>NOT</strong> 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 <strong>not</strong> 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>
+ <!-- end document body -->
+ <hr />
+ <p style="margin-top: 0cm">If you still have questions or concerns
+ regarding this document, please feel free to either
+ <a href="http://lists.sourceforge.net/lists/listinfo/leaf-user";>post
+ on the mailing list</a> or
+ <a href="/tracker/?func=add&group_id=13751&atid=213751">submit
+ a support request</a>. A member of the LEAF community will be glad
+ to assist you further.</p>
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Leaf-cvs-commits mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-cvs-commits
