Re: blocking RFC 793 ports 1024-49151
From: Ben Webb (ben@bellatrix.pcl.ox.ac.uk)Date: 02/03/02
- Next message: Charles Williams: "Re: POP Proxy Help"
- Previous message: Hal Burgiss: "Re: ICMP type 3, an attack?"
- In reply to: gaius.petronius: "Re: blocking RFC 793 ports 1024-49151"
- Next in thread: L. Walker: "Re: blocking RFC 793 ports 1024-49151"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: ben@bellatrix.pcl.ox.ac.uk (Ben Webb) Date: Sun, 3 Feb 2002 20:09:20 +0000 (UTC)
On 1 Feb 2002 18:18:41 -0800, gaius.petronius <rut@linuxmail.org> wrote:
> The problem is in the port range 1024-65535
> My previous policy was to allow this range for tcp only and some
> services (like DNS) failed to get udp client sockets. i then opened
> up 1024-65535 for udp and seemed to have opened up a can of worms.
But of course. You need to allow replies to your outgoing packets,
otherwise nothing is going to work, and these replies will generally be
coming in on the high-numbered ports. This is what connection tracking
(e.g. iptables) does. If you really want to stick with ipchains, then there's
not much you can do about UDP, but for TCP just block all packets with the
SYN bit set, except on the DNS, ftp and http ports. If the SYN packet doesn't
get through, a TCP connection cannot be formed.
> tcp 1 0 172.168.0.154:21 10.1.1.97:32954
> CLOSE_WAIT 23834/tcpd
> tcp 0 0 172.168.0.154:22 10.1.1.97:33048
> ESTABLISHED 32269/sshd
>
> So as you can see there are sockets in the high range.
>
> i wanted to capture the RFC 793 sockets in the input chain and then in
> my forward chain allow all in the range 1024-65535.
>
> is this a bad way to do it?
Yes, because those high-numbered sockets aren't listening; they're
connected. The port numbers are chosen by the kernel, and as far as I know
is perfectly possible for these to be RFC 793 port numbers.
> Yes i need to learn iptables.
> as soon as i catch up that is my next move.
A very very simple iptables firewall for your setup is extremely easy,
due to connection tracking worrying about most stuff for you. You don't have
to worry about DNS lookups, SYN bits, or anything of the sort. See below.
Ben
*mangle
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*filter
# We don't forward packets, and deny incoming stuff by default
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Accept local stuff (loopback) and ICMP (pings etc.)
[0:0] -A INPUT -i lo -j ACCEPT
[0:0] -A INPUT -p icmp -m limit --limit 10/sec -j ACCEPT
# Accept all fragments
[0:0] -A INPUT -f -j ACCEPT
# Allow services
[0:0] -A INPUT -p tcp -m tcp --dport http -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport ftp -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport ssh -j ACCEPT
# Allow through packets that belong to existing or related
# connections, so outgoing connections (and active FTP) work
[0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Log at least some of the dropped packets
[0:0] -A INPUT -m limit --limit 3/hour -j LOG
COMMIT
- Next message: Charles Williams: "Re: POP Proxy Help"
- Previous message: Hal Burgiss: "Re: ICMP type 3, an attack?"
- In reply to: gaius.petronius: "Re: blocking RFC 793 ports 1024-49151"
- Next in thread: L. Walker: "Re: blocking RFC 793 ports 1024-49151"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|