Re: are these enough now?

Re: are these enough now?

[Antony Stone]

On Friday 04 October 2002 8:17 am, PayalR wrote:

> Hello,
> I am providing webspace, email services etc. to few institutes. I have
> drafted a firewall policy for my server. Can you please check if it is
> right and tell me if I have gone wrong anywhere? I have formulated
> suggestion by various list-members in past.
>
> The script contains,
>
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

I assume the services are actually running on the same machine as netfilter - 
this is not a routing firewall sitting in front of the real server/s ?

> iptables -A INPUT -i eth0 -p $proto --dport $port -j ACCEPT
> To keep the script short in this e-mail I am replacing $proto with tcp and
> udp in each line of the actual script.
> $port is replaced by,
> 21, 22, 23, 25, 53, 80, 110,143, 161, 162, 199, 953, ,993,3306, 8007, 8009

21 - ftp - okay
22 - ssh - good
23 - telenet - ugh !   Why ???
25 - smtp - fine
53 - dns - only one in this list I can see which needs UDP as well TCP
80 - http - okay
110 - pop3 - yup
143 - imap - yup
161 - snmp - are you managing this system from elsewhere, or is this machine 
the snmp monitor ?   UDP 161 only needs to be inbound if this machine is 
being monitored from elsewhere
162 - snmptrap - again, are you managing this from elsewhere, or is this 
machine managing others ?   UDP 162 only needs to be inbound if this is the 
monitoring machine
I don't immediately recognise any of the higher port numbers so won't coment 
on those.

> We are SNNP client, so I think I need 161 and 162 open, right?

SNMP ?   Yes :-)   But check the direction.   UDP 161 is inbound to machines 
being monitored, outbound from machines being monitored.   UDP 162 is the 
other way round.

> Also, nmap shows that 2002/udp globe is open. Shall I close it?

Suggest you close the port, and also check very carefully to see if your 
machine already has the Slapper worm on it, since that opens UDP port 2002 to 
provide remote access to a root command shell on your system :-)

>
> So for e.g each line will actually look like this in the script,
> iptables -A INPUT -i eth0 -p tcp --dport 25 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --dport 25 -j ACCEPT
>
> I understand that ACCEPT for udp for 21, 22, 23, 80, 3306 is not required.
> I just wanted to confirm this from the list.

That is correct, also for 25, 110, 143 and maybe some of your higher ports as 
well.   I recommend you do create separate lists for TCP and UDP because very 
few things (DNA 53 is the only common example) need both.

> Also, I want to know if I should put the same rules for OUTPUT? Shall I
> just copy the above rules and replace INPUT with OUTPUT in them?

I would recommend setting your OUTPUT chain to ESTABLISHED,RELATED and then 
add any rules for traffic which is supposed to originate on your server (such 
as DNS queries).

> Also, do I set FORWARD to DROP?

Yes, if this machine is not supposed to forward packets between other systems.

> I know that there must be a elegant way of doing this, but it is just a
> start for me. For now, I want to get the whole thing working properly. I am
> losing bandwidth due to some stupid programs from inside and outside.

Such as Slapper :-) ?

> Please tell me if I am making a mistake anywhere. I will be remotely login
> in the server to do this? I certainly don't want ssh to stop :)
>
> Thanks a lot in advance and eagerly waiting for the replies (especially
> about the OUTPUT part, of which I have some reservations which i will
> discuss later).

Go on then - discuss.....  :-)

Hope this hellps,

Antony.

-- 

90% of network problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.

Re: are these enough now?

[PayalR]

Hi all,
Thanks a lot for the mails.
> 161 - snmp - are you managing this system from elsewhere, or is this
> machine the snmp monitor ?   UDP 161 only needs to be inbound if this
> machine is being monitored from elsewhere
Well, I don't know anyting about SNMP thing. But the guys at the server farm 
suggested I make some changes as told by them in my snmpd.conf, so that they 
say I there will be able to monitor my machine. I guess so I am just a client 
SNMP. So, which ports to keep open?

> > Also, nmap shows that 2002/udp globe is open. Shall I close it?
> machine already has the Slapper worm on it, since that opens UDP port 2002
well, my machine had a slapper worm. I removed the .bugtraq file from /tmp. 
Now still the port is open. This is very important to me. How do I close the 
port???? nmap report says,
2002/udp   open        globe
How do I know where and what is globe? How do I shut it?

> I would recommend setting your OUTPUT chain to ESTABLISHED,RELATED and then
do you mean similar to INPUT rule i.e using -m and all?

> add any rules for traffic which is supposed to originate on your server
> (such as DNS queries).

Thanks a lot and eagerly waiting for the mails.
Bye and thanks.
-Payal

ilimit problem

[HareRam]

Hi all

iam trying to use iplimit in iptables, iam getting the below problem
can any one help what is the caused problem

[root@cache root]# iptables -A INPUT -p tcp --syn --dport http -m
iplimit --iplimit-above 4 -j REJECT
iptables: No chain/target/match by that name


thanks in advanced

hare

Re: are these enough now?

[Antony Stone]

On Friday 04 October 2002 12:25 pm, PayalR wrote:

> Hi all,
> Thanks a lot for the mails.
>
> > 161 - snmp - are you managing this system from elsewhere, or is this
> > machine the snmp monitor ?   UDP 161 only needs to be inbound if this
> > machine is being monitored from elsewhere
>
> Well, I don't know anyting about SNMP thing. But the guys at the server
> farm suggested I make some changes as told by them in my snmpd.conf, so
> that they say I there will be able to monitor my machine. I guess so I am
> just a client SNMP. So, which ports to keep open?

UDP 161 inbound - to listen for SNMP commands
UDP 162 outbound - to generate SNMP traps

> > > Also, nmap shows that 2002/udp globe is open. Shall I close it?
> >
> > machine already has the Slapper worm on it, since that opens UDP port
> > 2002
>
> well, my machine had a slapper worm. I removed the .bugtraq file from /tmp.
> Now still the port is open. This is very important to me. How do I close
> the port???? nmap report says,
> 2002/udp   open        globe
> How do I know where and what is globe? How do I shut it?

Sorry - don't know - never had Slapper :-)   Anyone else here got any 
experience or pointers ?

> > I would recommend setting your OUTPUT chain to ESTABLISHED,RELATED
>
> do you mean similar to INPUT rule i.e using -m and all?

Yes.

Antony.

-- 

Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.

 - William Gibson, Neuromancer (1984)

How to Find what are the Patches installed

[HareRam]

hi all

how do i find out what are the patches installed in existing system
and how to find after p-o-m what are installed

where can i see this
thanks
hare

Re: are these enough now?

[PayalR]

Hello all,
Thanks a lot for the time and patience. I have written the script and am
posting it here. If such kind of posting is not allowed please tell, so
next time I will post it on a webpage and paste the link. But since ppl.
might be reluctant to launch there browsers for this thing, I took the
liberty of pasting it here.
I have a single PC with all servers on the same machine.
I am not forwading anything.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

[Is this OUTPUT rule OK?]

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 23 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 110 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 143 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 161 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 162 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 3306 -j ACCEPT

iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 161 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 162 -j ACCEPT

[udp for these are sufficent I guess]

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

[please see if the state rule looks OK?]

iptables -A OUTPUT -i eth0 -p tcp --sport 21 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 22 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 23 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 25 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 53 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 110 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 143 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 161 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 162 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 3306 -j ACCEPT

[is the tag --sport appropriate here? or do I have to use --dport? I always 
get confused between the usage of these two :)]

iptables -A OUTPUT -i eth0 -p udp --sport 53 -j ACCEPT
iptables -A OUTPUT -i eth0 -p udp --sport 161 -j ACCEPT
iptables -A OUTPUT -i eth0 -p udp --sport 162 -j ACCEPT

[udp here also seems enough]

Shall I block ICMP? I intend to have some logging for SMTP, HTTP and POP3.
I have yet to formulate the rules for them. I will do it in day or two and let
ask here for opinion.

Also, as Anthony said I am looking forward for pointers on slapper. Or you 
might just tell how do I know where the service is which is accessing port 
2002, plain UNIX :)

Thanks a lot in advance and eagerly waiting for your comments.
Bye.
-Payal

p.s I will drop the telnet also in a day or two :)

RE: are these enough now?

[Clint Todish]

More than likely, someone pushed over a root kit to cover their
tracks...if netstat -an doesn't show 2002 open, then you can be sure of
it. Chances are, they've also replaced ps as well to hide the
process...try:
'/usr/sbin/lsof -I udp:2002' to get the PID. If you are running a RedHat
install - 'rpm -Va' and look for a '5' in the 3rd position as that
indicates a MD5 checksum difference from the binary on your machine and
the original package. 

Personally, I would recommend a reinstall as you never know for sure
what may be left lurking around.

-C

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Friday, October 04, 2002 8:09 AM
To: netfilter@lists.netfilter.org
Subject: Re: are these enough now?


On Friday 04 October 2002 12:25 pm, PayalR wrote:

> Hi all,
> Thanks a lot for the mails.
>
> > 161 - snmp - are you managing this system from elsewhere, or is this
> > machine the snmp monitor ?   UDP 161 only needs to be inbound if
this
> > machine is being monitored from elsewhere
>
> Well, I don't know anyting about SNMP thing. But the guys at the 
> server farm suggested I make some changes as told by them in my 
> snmpd.conf, so that they say I there will be able to monitor my 
> machine. I guess so I am just a client SNMP. So, which ports to keep 
> open?

UDP 161 inbound - to listen for SNMP commands
UDP 162 outbound - to generate SNMP traps

> > > Also, nmap shows that 2002/udp globe is open. Shall I close it?
> >
> > machine already has the Slapper worm on it, since that opens UDP 
> > port 2002
>
> well, my machine had a slapper worm. I removed the .bugtraq file from 
> /tmp. Now still the port is open. This is very important to me. How do

> I close the port???? nmap report says,
> 2002/udp   open        globe
> How do I know where and what is globe? How do I shut it?

Sorry - don't know - never had Slapper :-)   Anyone else here got any 
experience or pointers ?

> > I would recommend setting your OUTPUT chain to ESTABLISHED,RELATED
>
> do you mean similar to INPUT rule i.e using -m and all?

Yes.

Antony.

-- 

Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.

 - William Gibson, Neuromancer (1984)

Re: How to Find what are the Patches installed

[Antony Stone]

On Friday 04 October 2002 2:09 pm, HareRam wrote:

> hi all
>
> how do i find out what are the patches installed in existing system
> and how to find after p-o-m what are installed

I think that's a more difficult question than asking "what options was this 
kernel compiled with ?", and if anyone's got any ideas how to work that one 
out I'd be interested.....

Antony.

-- 

The first ninety percent of an engineering project takes ninety percent
of the time, and the last ten percent takes the remaining ninety percent.

Re: are these enough now?

[Antony Stone]

On Friday 04 October 2002 4:22 pm, PayalR wrote:

> Hello all,
> Thanks a lot for the time and patience. I have written the script and am
> posting it here. If such kind of posting is not allowed please tell, so
> next time I will post it on a webpage and paste the link. But since ppl.
> might be reluctant to launch there browsers for this thing, I took the
> liberty of pasting it here.
> I have a single PC with all servers on the same machine.
> I am not forwading anything.
>
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
> iptables -P OUTPUT DROP
>
> [Is this OUTPUT rule OK?]

This is okay, provided you have a rule to allow reply packets out (you have - 
that's the ESTABLISHED,RELATED rule below) and also rules to allow out any 
connections you expect to be initiated from this machine (most likely being 
DNS lookups - agin, you do have these later on).

> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 23 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 25 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 53 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 110 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 143 -j ACCEPT

> iptables -A INPUT -i eth0 -p tcp --dport 161 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 162 -j ACCEPT

You don't need these last two - SNMP uses UDP, not TCP.

> iptables -A INPUT -i eth0 -p tcp --dport 3306 -j ACCEPT
>
> iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --dport 161 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --dport 162 -j ACCEPT
>
> [udp for these are sufficent I guess]

Correct, but remove UDP 162 inbound, because you only need to send SNMP 
traps, you are not expecting to receive them.

> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> [please see if the state rule looks OK?]

Yes.

> iptables -A OUTPUT -i eth0 -p tcp --sport 21 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 22 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 23 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 25 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 53 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 80 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 110 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 143 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 161 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 162 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 3306 -j ACCEPT

Remove all of the above rules.   They are not needed because you have the 
ESTABLISHED,RELATED rule which will allow out the reply packets to all the 
onews you let in in your INPUT chain.

> [is the tag --sport appropriate here? or do I have to use --dport? I always
> get confused between the usage of these two :)]

It would be correct, yes, if you needed the rules.   The way to remember 
whether it's Source port or Destination port is that services are requested 
by clients, and servers a sitting there listening on specific port numbers, 
waiting for a client to ask for something.   Therefore the server is the 
destination of the request, and it is listening on the correct port numbers 
for whatever services it is offering.   Therefore a client sends its requests 
to the server's destination port.   When the server replies, it replies from 
the same port, so the responses come from the server's source port.

> iptables -A OUTPUT -i eth0 -p udp --sport 53 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p udp --sport 161 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p udp --sport 162 -j ACCEPT
>
> [udp here also seems enough]

No, add TCP for DNS on port 53 as well.

Remove UDP 161 outbound; you only need this inbound, for a device being 
monitored but not monitoring anything else.

> Shall I block ICMP?

No !!!   ICMP is a very important part of traffic management, and you should 
not block it outright.   However, I cannot think of any ICMP message codes 
you should explicitly allow on this system, since everything you need should 
be handled by you ESTABLISHED,RELATED rules (ICMP forms the bulk of the 
RELATED category, except for things like ftp).

> I intend to have some logging for SMTP, HTTP and POP3.
> I have yet to formulate the rules for them. I will do it in day or two and
> let ask here for opinion.

If you use syslogd to send log messages to a remote machine you will need to 
allow UDP port 514 out of your server.

> p.s I will drop the telnet also in a day or two :)

Good :-)
 

Antony.

-- 

Perfection in design is achieved not when there is nothing left to add,
but rather when there is nothing left to take away.

 - Antoine de Saint-Exupery

Re: are these enough now?

[Alistair Tonner]

On 2002.10.04 15:13 Antony Stone wrote:
> On Friday 04 October 2002 4:22 pm, PayalR wrote:
> 

	Bulk of message snipped for brevity.


> being
> monitored but not monitoring anything else.
> 
> > Shall I block ICMP?
> 
> No !!!   ICMP is a very important part of traffic management, and you
> should
> not block it outright.   However, I cannot think of any ICMP message
> codes
> you should explicitly allow on this system, since everything you need
> should
> be handled by you ESTABLISHED,RELATED rules (ICMP forms the bulk of
> the
> RELATED category, except for things like ftp).

	Anthony ... My icmp chain ... (seems to work for me,
	and you can toss in limit rules as well)

	 
# $IPTABLES -A icmp_packets -j LOG --log-level 4 --log-prefix "IPT icmp 
IN:"
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 0 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 3 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 5 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT
# $IPTABLES -A icmp_packets -j LOG --log-level DEBUG --log-prefix "IPT 
icmp DROP :"
$IPTABLES -A icmp_packets -j DROP



    With debugging rules commented out above,  ... I don't get hammered 
on
	all that often, but once in a while it helps to use both the 
logging rules,
	and I've on occasion had to put in limit rules....

	(P.S. this block is straight out of one of Oskar's HOWTO 
guides...
	thanks for the good tips Oskar)

	Alistair






> 
> > I intend to have some logging for SMTP, HTTP and POP3.
> > I have yet to formulate the rules for them. I will do it in day or
> two and
> > let ask here for opinion.
> 
> If you use syslogd to send log messages to a remote machine you will
> need to
> allow UDP port 514 out of your server.
> 
> > p.s I will drop the telnet also in a day or two :)
> 
> Good :-)
> 
> 
> Antony.
> 
> --
> 
> Perfection in design is achieved not when there is nothing left to
> add,
> but rather when there is nothing left to take away.
> 
>  - Antoine de Saint-Exupery
> 
> 

Re: are these enough now?

[PayalR]

Hello all,
Thanks a lot for the mails. Well, I will reply to all the mails but first 
here is some more info/problem :)
I tried this script on my dummy server. 
But I faced 3 problems.

1. I could not ping to any ip/domain name.
I got an error that ping: operation not permitted, even though I had not 
specifically told it to drop ICMP.

2. I could not resolve host names, even though I had rules for port 53 like 
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 953 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 953 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 53 -j ACCEPT
iptables -A OUTPUT -i eth0 -p udp --sport 53 -j ACCEPT
iptables -A OUTPUT-i eth0 -p tcp --dport 953 -j ACCEPT
iptables -A OUTPUT-i eth0 -p udp --dport 953 -j ACCEPT
I am using BIND 9.1.3

3. If I give a OUTPUT rule for e.g.,
iptables -A OUTPUT -i eth0 -p tcp --sport 21 -j ACCEPT
I get an error saying I cannot specify -i eth0. It works properly when 
I remove -i eth0. Is it OK?

I have all the default policies of INPUT, OUTPUT and FORWARD set to drop.

Thanks a lot for helping me out and bye 
-Payal

Re: are these enough now?

[Antony Stone]

On Saturday 05 October 2002 12:39 pm, PayalR wrote:

> 1. I could not ping to any ip/domain name.
> I got an error that ping: operation not permitted, even though I had not
> specifically told it to drop ICMP.

Yes you have.   You have a default DROP policy on your output chain, and you 
have no rule saying "allow out new icmp packets".

If you want to be able to send pings from this machine you must add something 
like:

iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT

The replies will be allowed back in by the ESTABLISHED,RELATED rule in your 
INPUT chain.

> 2. I could not resolve host names, even though I had rules for port 53 like
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 53 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --dport 953 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --dport 953 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT

These rules are INPUT with a *destination* port of 53 - that is for *your* 
machine acting as a DNS server - this may be the case, I don't know, but it 
has nothing to do with your machine being able to access another DNS server.

> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A OUTPUT -i eth0 -p tcp --sport 53 -j ACCEPT
> iptables -A OUTPUT -i eth0 -p udp --sport 53 -j ACCEPT

No, the OUTPUT rules should specify a destination port of 53, because you are 
trying to contact another DNS server which is listening on port 53.

> iptables -A OUTPUT-i eth0 -p tcp --dport 953 -j ACCEPT
> iptables -A OUTPUT-i eth0 -p udp --dport 953 -j ACCEPT

I don't know what these are for.

> I am using BIND 9.1.3
>
> 3. If I give a OUTPUT rule for e.g.,
> iptables -A OUTPUT -i eth0 -p tcp --sport 21 -j ACCEPT
> I get an error saying I cannot specify -i eth0. It works properly when
> I remove -i eth0. Is it OK?

What is an input interface supposed to mean for a rule in the OUTPUT chain ?

Rules in the OUTPUT chain apply only to locally-generated packets.   There is 
no input interface, because they didn't come in to the machine.


Antony.

-- 

What is this talk of software 'release' ?
Our software evolves and matures until it becomes capable of escape,
leaving a bloody trail of designers and quality assurance people in its wake.

Re: are these enough now?

[Antony Stone]

On Friday 04 October 2002 9:32 pm, Alistair Tonner wrote:

> 	Antony ... My icmp chain ... (seems to work for me,
> 	and you can toss in limit rules as well)
>
>
> # $IPTABLES -A icmp_packets -j LOG --log-level 4 --log-prefix "IPT icmp
> IN:"
> $IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 0 -j ACCEPT
> $IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 3 -j ACCEPT
> $IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 5 -j ACCEPT
> $IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT
> # $IPTABLES -A icmp_packets -j LOG --log-level DEBUG --log-prefix "IPT
> icmp DROP :"
> $IPTABLES -A icmp_packets -j DROP

Interesting.   You're allowing ICMP message types 0, 3, 5 and 11....

0 is echo reply
3 is destination unreachable
5 is redirect
11 is time exceeded

Comments:

1. Why allow echo reply if you don't also allow echo request (type 8) ?

2. I think you should also allow source quench (type 4) so that systems can 
slow each other down if they start sending too fast.

Out of interest, what sort of log entries do you see from the "log just 
before dropping the rest" rule ?

Antony.

-- 

Most people have more than the average number of legs.