Update of /cvsroot/leaf/doc/guide/user-bering-uclibc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10449
Modified Files:
bucu-upnpd.xml
Log Message:
update for new upnpd.lrp with shorewall 2.4 integration
Index: bucu-upnpd.xml
===================================================================
RCS file: /cvsroot/leaf/doc/guide/user-bering-uclibc/bucu-upnpd.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** bucu-upnpd.xml 28 Apr 2005 17:44:30 -0000 1.2
--- bucu-upnpd.xml 4 Aug 2005 11:25:47 -0000 1.3
***************
*** 53,76 ****
clients act as temporary servers, but these clients may be desktop
machines that are assigned dynamic addresses and use dynamic port
! assignment. Hand configured DNAT and FORWARD rules on the firewall don't
! work well in such an environment.</para>
<para>For more information on UPnP, search the Intel and Microsoft
websites for descriptions of UPnP. Alcatel has provided a <ulink
url="http://www.speedtouch.com/pdf/UPnP_AppNote_ED01P01.pdf";>good
! overview</ulink> of UPnP and how it works with their SOHO routers, the
! basic concepts are similar and can be used to understand this
! implementation.</para>
<warning>
! <para>Universal Plug-n-Play can be misused to bypass controls on your
! firewall. A malicious or compromised client on your internal network can
! potentially open up a hole in your firewall from the Internet to any
! port or any machine on your internal network. Additionally, this
! particular implementation has not undergone rigorous security testing
! and may be vulnerable to buffer overflows, allowing a malicious control
! point to gain unauthorized access to the firewall. It is imperative that
! only trusted hosts be allowed to interact with the UPnP services running
! on the firewall.</para>
</warning>
--- 53,80 ----
clients act as temporary servers, but these clients may be desktop
machines that are assigned dynamic addresses and use dynamic port
! assignment. Hand configured <code>DNAT</code> and <code>FORWARD</code>
! rules on the firewall don't work well in such an environment.</para>
<para>For more information on UPnP, search the Intel and Microsoft
websites for descriptions of UPnP. Alcatel has provided a <ulink
url="http://www.speedtouch.com/pdf/UPnP_AppNote_ED01P01.pdf";>good
! overview</ulink> of the internals of the UPnP protocol and how it works
! with their SOHO routers, the basic concepts are similar and can be used to
! understand this implementation.</para>
<warning>
! <para>The Universal Plug-n-Play IGD protocol assumes that the devices on
! the inside of your firewall are trusted, -and- that there is only one
! exterior interface that requires NAT traversal. This is the common case
! in small offices and homes. Most SOHO routers shipped today support UPnP
! because it is such a useful feature. However, a malicious or compromised
! control point (client on your internal network) can potentially open up
! a hole in your firewall from the Internet to any port on any machine on
! your internal network. Additionally, this particular implementation has
! not undergone rigorous security testing and may be vulnerable to buffer
! overflows, allowing a malicious control point to gain unauthorized
! access to the firewall. It is imperative that only trusted hosts be
! allowed to interact with the UPnP services running on the
! firewall.</para>
</warning>
***************
*** 82,87 ****
different security policies, it is your responsibility to insure that your
firewall policy does not allow a UPnP client on one interface to open up a
! hole in your firewall to a host on another interface. The UPnP protocol
! allows any host to poke any arbitrary rule into a firewall table.</para>
</section>
--- 86,90 ----
different security policies, it is your responsibility to insure that your
firewall policy does not allow a UPnP client on one interface to open up a
! hole in your firewall to a host on another interface.</para>
</section>
***************
*** 98,211 ****
<tgroup cols="3">
<thead>
-
-
<row>
-
-
<entry align="left">Protocol/Port</entry>
-
-
<entry align="left">Destination</entry>
-
-
<entry align="left">Remarks</entry>
-
-
</row>
-
-
</thead>
-
-
<tbody>
-
-
<row>
-
-
<entry align="left">UDP 1900</entry>
-
-
<entry align="left">fw to/from local</entry>
-
-
<entry align="left">SSDP announcements</entry>
-
-
</row>
-
-
<row>
-
-
<entry align="left">TCP 49152</entry>
-
-
<entry align="left">fw from local</entry>
-
-
<entry align="left">HTTP/XML mini-server</entry>
-
-
</row>
-
-
<row>
-
-
<entry align="left">TCP <emphasis>any port</emphasis></entry>
-
-
<entry align="left">fw to local</entry>
-
-
<entry align="left">HTTP/XML queries of other UPnP devices</entry>
-
-
</row>
-
-
<row>
-
-
<entry align="left">UDP <emphasis>any port</emphasis></entry>
-
-
<entry align="left">fw to local</entry>
-
-
<entry align="left">respond to remote SSDP requests</entry>
-
-
</row>
-
-
</tbody>
</tgroup>
</table>
! <para>Additionally, SSDP is multicast to 239.255.255.250 and does IGMP
! joins to 224.0.0.22. You must have a route covering that multicast group
! pointing towards your internal network or the announcements will be sent
! towards your default route, which is almost always not what you
! want.</para>
<para>When a client requests NAT traversal, rules will be created in the
! <filename>forwardUPnP</filename> and <filename>PREROUTING</filename>
! tables. This is not the default behavior for UPnP.</para>
<important>
--- 101,163 ----
<tgroup cols="3">
<thead>
<row>
<entry align="left">Protocol/Port</entry>
<entry align="left">Destination</entry>
<entry align="left">Remarks</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left">UDP 1900</entry>
<entry align="left">fw to/from local</entry>
<entry align="left">SSDP announcements</entry>
</row>
<row>
<entry align="left">TCP 49152</entry>
<entry align="left">fw from local</entry>
<entry align="left">HTTP/XML mini-server</entry>
</row>
<row>
<entry align="left">TCP <emphasis>any port</emphasis></entry>
<entry align="left">fw to local</entry>
<entry align="left">HTTP/XML queries of other UPnP devices</entry>
</row>
<row>
<entry align="left">UDP <emphasis>any port</emphasis></entry>
<entry align="left">fw to local</entry>
<entry align="left">respond to remote SSDP requests</entry>
</row>
</tbody>
</tgroup>
</table>
! <para>Additionally, both UPnP on the router and on your control-point
! clients generate SSDP packets which are multicast to 239.255.255.250. Both
! also send and listen to IGMP join messages on 224.0.0.22. You must have a
! route covering these multicast groups pointing towards your internal
! network or the announcements will be sent towards your default route,
! which is almost always not what you want. The UPnP wrapper scripts
! provided in this package will set up a multicast route for you, or you can
! specify what you want in <filename>/etc/default/upnpd</filename>.</para>
<para>When a client requests NAT traversal, rules will be created in the
! <filename><code>forwardUPnP</code> <code>FORWARDING</code>
! table</filename> and UPnP <filename><code>PREROUTING</code></filename>
! table. This is not the default behavior for UPnP -- it normally writes
! directly to <code>FORWARDING</code> and <code>PREROUTING</code>.</para>
<important>
***************
*** 227,231 ****
<listitem>
<para>edit <filename>/etc/default/upnpd</filename> to specify your
! external and internal network interfaces</para>
</listitem>
--- 179,184 ----
<listitem>
<para>edit <filename>/etc/default/upnpd</filename> to specify your
! external and internal network interfaces and to disable/modify
! multicast route generation</para>
</listitem>
***************
*** 249,286 ****
conditions and is a good starting place.</para>
! <para><filename>upnp.lrp</filename> created new user-defined actions with
! shorewall through:</para>
!
! <itemizedlist>
! <listitem>
! <para><filename>/etc/shorewall/action.forwardUPnP</filename></para>
! </listitem>
!
! <listitem>
! <para><filename>/etc/shorewall/action.allowinUPnP</filename></para>
! </listitem>
!
! <listitem>
! <para><filename>/etc/shorewall/action.allowoutUPnP</filename></para>
! </listitem>
! </itemizedlist>
! <para>These actions should need to be "registered" with Shorewall in order
! to be used with the firewall system. Edit the file
! <filename>/etc/shorewall/actions</filename> and add the following lines to
! the file:</para>
! <screen>forwardUPnP
! allowinUPnP
! allowoutUPnP</screen>
! <para>Invoke these actions in your shorewall configuration. In this
! example, <emphasis>loc</emphasis> is your internal network zone where UPnP
! clients are located, <emphasis>net</emphasis> is the upstream network
(Internet):</para>
! <screen>forwardUPnP net loc
! allowinUPnP loc fw
! allowoutUPnP fw loc</screen>
</section>
</chapter>
\ No newline at end of file
--- 202,230 ----
conditions and is a good starting place.</para>
! <para>Shorewall uses the <filename>ipt_owner.o</filename> kernel module
! for UPnP support. <filename>ipt_owner.o</filename> can be found in the
! Bering-uClibc kernel modules distribution. Add it to
! <filename>/lib/modules</filename> and make sure it is loaded in
! <filename><filename>/etc/modules</filename></filename> at system startup.
! If you see an error message when Shorewall runs trying to add an iptables
! rule with the <code>--cmd-owner</code> option,
! <filename>ipt_owner.o</filename> is not loaded.</para>
! <para>Specify in <filename>/etc/shorewall/interfaces</filename> which
! interface is your upstream interface (your Internet interface) which will
! receive inbound connection requests after UPnP has authorized them. Add
! the "upnp" option to that interface.</para>
! <para>Example:</para>
! <para><screen>net ppp0 -
upnp,tcpflags,blacklist,routefilter,norfc1918,nosmurfs</screen>Apply
! the UPnP specific rules in your shorewall rules file. In this example,
! <emphasis>loc</emphasis> is your internal network zone where UPnP clients
! are located, <emphasis>net</emphasis> is the upstream network
(Internet):</para>
! <screen>forwardUPnP net loc # dynamic rules inserted here
! allowinUPnP loc fw # allow from control points
! allowoutUPnP fw loc # allow communication to control points</screen>
</section>
</chapter>
\ No newline at end of file
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
leaf-cvs-commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-cvs-commits
