Firewall software

Firewall software

[Lawrence - D]

[-- Attachment #1: Type: text/plain, Size: 133 bytes --]

Hi,
    Can anyone recommend firewall software that can work together with IPtables ? User friendly interface.


Lawrence Tang 

[-- Attachment #2: Type: text/html, Size: 621 bytes --]

RE: Firewall software

[Tom Van Overbeke]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]

fwbuilder & firepoint


fwbuilder is a graphic interface with icons representing various firewall
objects (hosts, firewalls, tcp ports), which makes it a lot easier to create
a decent firewall policy.

firepoint is a wrapper around fwbuilder with as main features access control
& automatic activation of firewall policy. firepoint is not perfect (access
control is actually not very secure), but this combo together with iptables
enables one to create a rather professional firewall setup.


Tom.

  -----Original Message-----
  From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Lawrence - D
  Sent: 05 August 2003 10:23
  To: Netfilter
  Subject: Firewall software


  Hi,
      Can anyone recommend firewall software that can work together with
IPtables ? User friendly interface.


  Lawrence Tang

****************************************************************************
Disclaimer: 
This electronic transmission and any files attached to it are strictly 
confidential and intended solely for the addressee. If you are not 
the intended addressee, you must not disclose, copy or take any
action in reliance of this transmission. If you have received this 
transmission in error, please notify the sender by return and delete
the transmission.  Although the sender endeavors to maintain a
computer virus free network, the sender does not warrant that this
transmission is virus-free and will not be liable for any damages 
resulting from any virus transmitted. 
Thank You.
****************************************************************************

[-- Attachment #2: Type: text/html, Size: 3351 bytes --]

Re: Firewall software

[Lawrence - D]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

thanks guy.

Lawrence
  ----- Original Message ----- 
  From: Paul Ammann 
  To: Lawrence - D ; Netfilter 
  Sent: Tuesday, August 05, 2003 9:46 PM
  Subject: Re: Firewall software


  Go to Sourceforge, and look up Firewall Builder. This VERY user friendly interface interacts with IPtables as well as PIX.

  Best regards,

  Paul Ammann

    ----- Original Message ----- 
    From: Lawrence - D 
    To: Netfilter 
    Sent: Tuesday, August 05, 2003 1:22 AM
    Subject: Firewall software


    Hi,
        Can anyone recommend firewall software that can work together with IPtables ? User friendly interface.


    Lawrence Tang 

[-- Attachment #2: Type: text/html, Size: 2844 bytes --]

Re: Firewall software

[Paul Ammann]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

Go to Sourceforge, and look up Firewall Builder. This VERY user friendly interface interacts with IPtables as well as PIX.

Best regards,

Paul Ammann

  ----- Original Message ----- 
  From: Lawrence - D 
  To: Netfilter 
  Sent: Tuesday, August 05, 2003 1:22 AM
  Subject: Firewall software


  Hi,
      Can anyone recommend firewall software that can work together with IPtables ? User friendly interface.


  Lawrence Tang 

[-- Attachment #2: Type: text/html, Size: 1789 bytes --]

How to allow Real Player

[Brad Morgan]

I'm trying to understand how to setup my firewall to allow Real Player.
Based on the text below, I've written the following rules: 

## Allow Real Player
for i in $LANIPS; do
  iptables -A FORWARD -p tcp -s $i --dport 554 -j ACCEPT
  iptables -A FORWARD -p tcp -s $i --dport 7070 -j ACCEPT
done
iptables -A FORWARD -p udp --dport 6970:6979 -j ACCEPT

I limited the number of UDP ports to a much smaller range than they suggest.

This network has both public IP addresses and NAT addresses (a conversion to
use just the NAT address range is taking place).  My test user is on one of
the NAT addresses.

What I don't understand is the statement "The range of UDP ports, on the
other hand, carries the incoming stream. These ports begin to carry traffic
only after RealPlayer and RealServer have performed the authentication
routine, and should be enabled only for incoming traffic."

Is the firewall going to know what to do with an incoming packet to one of
these UDP ports?  If the internal machine initiated the conversation, then
ESTABLISHED would know what to do, but that would be outgoing traffic which
the documentation says won't happen.

Is this another one of those applications that needs a "helper"?  Does one
exist?  I looked but couldn't find it.

Strange thing is, the user's web cast worked after adding the above rules,
but capturing the traffic using Ethereal didn't show any UDP traffic at all,
only TCP and RSTP on 554.  I did however, see realplayer.exe listening on
UDP port 6970.

Thanks for your insight.

Regards,

Brad Morgan   

----- Excerpt from http://service.real.com/firewall/adminfw.html -----

Application-level Firewalls 

Your firewall must be RealPlayer-aware. If it is not, RealNetworks has a
free RTSP proxy service which includes source code and specifications for
building your own proxy. It's simple and easy to set up. To get your copy,
send an e-mail request to firewall@real.com. You will get an immediate
response telling you where to download the proxy. 

Most major firewall vendors support RealPlayer. If your firewall vendor is
not listed as supporting RealPlayer, ask your firewall representative to
contact us about joining our firewall developers program. 


Network-level Firewalls

Network-level firewalls, such as packet filters, use access control lists to
allow traffic destined for some ports to pass from the Internet to the
organization's internal network and to block packets for other ports. To
allow any version of RealAudio Player or RealPlayer to play correctly, it is
only necessary for the router to allow packets to pass to the inner network
that are bound for the following range of ports:

TCP port 7070 for connecting to pre-G2 RealServers
TCP port 554 and 7070 for connecting to G2 RealServers 

UDP ports 6970 - 7170 (inclusive) for incoming traffic only 

The TCP port is used by RealPlayer to initiate a conversation with an
external RealServer, to authenticate RealPlayer to the server, and to pass
control messages during playback (such as pausing or stopping the stream).
RealSystem G2 uses two TCP protocols for conversations between Players and
Servers. 

For an even safer firewall, configure the router's access control list to
allow TCP connections on port 7070 and/or port 554 to be initiated from the
inside network exclusively. Incoming traffic, on the other hand, should only
be allowed if it is part of an ongoing connection. This is assured by
requiring incoming TCP packets to have the ACK bit set in the TCP header
carried by every packet. The syntax for setting the ACK bit varies with the
kind of router you own. For Cisco routers the flag "ESTABLISHED" can be put
at the end of the line in an access rule to specify that an incoming packet
must be part of an ongoing conversation. 

The range of UDP ports, on the other hand, carries the incoming stream.
These ports begin to carry traffic only after RealPlayer and RealServer have
performed the authentication routine, and should be enabled only for
incoming traffic. 

You may also want to use a proxy server in conjunction with a network-level
firewall. 

 

Re: How to allow Real Player

[Tom Marshall]

[-- Attachment #1: Type: text/plain, Size: 3517 bytes --]

Please note most of the following discussion applies to RTSP in general, not
just RealPlayer.

On Tue, Aug 12, 2003 at 09:56:31PM -0600, Brad Morgan wrote:
> I'm trying to understand how to setup my firewall to allow Real Player.
> Based on the text below, I've written the following rules: 
> 
> ## Allow Real Player
> for i in $LANIPS; do
>   iptables -A FORWARD -p tcp -s $i --dport 554 -j ACCEPT
>   iptables -A FORWARD -p tcp -s $i --dport 7070 -j ACCEPT
> done
> iptables -A FORWARD -p udp --dport 6970:6979 -j ACCEPT
> 
> I limited the number of UDP ports to a much smaller range than they suggest.

The RTSP protocol normally uses TCP port 554.  Port 7070 is for an old
proprietary protocol called PNA that has been deprecated for over 5 years.
You may still run into it occasionally, but hopefully that is rare.

RTSP is a control protocol.  It does the equivalent of the play/pause/stop
buttons.  The actual data can flow either in separate UDP packets (this is
preferred), or interleaved within the same TCP connection as RTSP.

> What I don't understand is the statement "The range of UDP ports, on the
> other hand, carries the incoming stream. These ports begin to carry traffic
> only after RealPlayer and RealServer have performed the authentication
> routine, and should be enabled only for incoming traffic."
> 
> Is the firewall going to know what to do with an incoming packet to one of
> these UDP ports?  If the internal machine initiated the conversation, then
> ESTABLISHED would know what to do, but that would be outgoing traffic which
> the documentation says won't happen.

When using UDP, the server usually starts sending packets to the client
first.  This means that the NAT does not have a chance to create a mapping
between client and server, so it doesn't know where to send the UDP packets. 
Newer clients are getting around this problem with techniques such as STUN
and Symmetric RTP, but most clients don't have this ability.

> Is this another one of those applications that needs a "helper"?  Does one
> exist?  I looked but couldn't find it.

Bingo!  :-)

In order to solve this problem, you need to use an RTSP ALG (helper module). 
I wrote one for the 2.4.21-preX kernels some months ago.  It's not been
updated in some time due to lack of response.  The changes to get the patch
running on the released 2.4.21 kernel are fairly trivial.  You can download
it here:

	http://home.tig-grr.com/rtsp/index.html

Only 2.4.21-preX is listed at the moment.  I plan to update the module at
some point in the near future and support various kernel versions. 
Eventually it would be nice to get the module into the Linux kernel.

> Strange thing is, the user's web cast worked after adding the above rules,
> but capturing the traffic using Ethereal didn't show any UDP traffic at all,
> only TCP and RSTP on 554.  I did however, see realplayer.exe listening on
> UDP port 6970.

Typically, the client will realize after a few seconds that it's not getting
any packets and switch over to TCP mode.  Some of the more intelligent
clients (such as RealONE players) will remember which servers are not
accessible via UDP and they won't attempt UDP from that server again for
some time.  This is may be why you aren't seeing any UDP packets from the
server on any arbitrary request.

-- 
I've finally learned what "upward compatible" means.  It means we get to
keep all our old mistakes.
        -- Dennie van Tassel

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]