More neqbie questions

More neqbie questions

[Eric Ellis]

This is one of those things that's been hounding me for the past few 
weeks that I can't understand what's *exactly* going on...

I've been using the IPTables tutorial from 
http://iptables-tutorial.frozentux.net/chunkyhtml/index.html, as has 
been pointed out and recommended by many of the list's pros.  It's a 
great tutorial, and I highly recommend it.

However, I have either glossed something covered in it, or I have a 
fundamental misunderstanding of some part of IPTables.

I know that the route works.  I've verified it.  I can move IPTraffic 
when I set all of my policies on my filter script to accept.  However, 
when I set my policies on my script to drop, Nothing talks any more.  I 
have attached a cleaned up version of the script I'm using to invoke 
IPTables.  The only things that have been removed are comments that help 
me remember what I was doing.

<code>
eellis@firewall:~$ cat /etc/iptables/rc.iptables
#!/bin/bash
### Variables
IPT="/usr/local/sbin/iptables"
INT="eth0"
EXT="eth1"

### Flush everything
$IPT -t nat -F
$IPT -F

### Policies
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

### INPUT chain
# SSH
$IPT -A INPUT -p tcp --dport 22 -j ACCEPT

# HTTP, on port 8000
$IPT -A INPUT -p tcp --dport 8000 -j ACCEPT

# DNS
$IPT -A INPUT -i $INT -p udp --dport 53 -j ACCEPT

### OUTPUT chain
# The only thing doing output on this box are proxy
# servers, and the occasional SSH and HTTP for
# testing.
# SQUID proxy, and local HTTP requests.
$IPT -A OUTPUT -p tcp --dport 80 -j ACCEPT

# SSH
$IPT -A OUTPUT -p tcp --dport 22 -j ACCEPT

### FORWARD chain 

$IPT -A OUTPUT -p tcp --dport 80 -j ACCEPT 


# SSH 

$IPT -A OUTPUT -p tcp --dport 22 -j ACCEPT 


### FORWARD chain 

# Accept anything from the inside requesting http 

# $IPT -A FORWARD -i $INT -p tcp --dport 80 -j ACCEPT 


# Accept anything from the inside requesting SSH 

$IPT -A FORWARD -i $INT -p tcp --dport 22 -j ACCEPT 


# Accept anything from the inside requesting FTP 

$IPT -A FORWARD -i $INT -p tcp --dport 21 -j ACCEPT 


# Accept anything from the inside for mail 

$IPT -A FORWARD -i $INT -p tcp --dport 25 -j ACCEPT 

$IPT -A FORWARD -i $INT -p tcp --dport 110 -j ACCEPT 

$IPT -A FORWARD -i $INT -p tcp --dport 143 -j ACCEPT 


# Accept anything else that's been established 

$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT 


### NAT table 

# let's see what damage I can do here... 

# redirect all FORWARDED requests to SQUID 

$IPT -t nat -A PREROUTING -i $INT -p tcp --dport 80 -j REDIRECT 
--to-port 8080

$IPT -t nat -A POSTROUTING -p tcp -j MASQUERADE 


eellis@firewall:~$
</code>

Now, according to my understanding as it sits right now, that should 
masquerade all traffic in the nat table, and drop everything except 
ports 21, 22, 25, 80 (redirected to port 8080), 110, 143.  Firewall 
should accept ports 22 and 8000 input and should allow ports 22 and 80 
on output.  Thing is that it doesn't move packets.

Thanks for all your help.

-- 
Eric Ellis
Gilchrist County Sheriff's Office
IT Coordinator

Re: More neqbie questions

[Antony Stone]

On Monday 02 August 2004 6:46 pm, Eric Ellis wrote:

> This is one of those things that's been hounding me for the past few
> weeks that I can't understand what's *exactly* going on...
>
> I've been using the IPTables tutorial from
> http://iptables-tutorial.frozentux.net/chunkyhtml/index.html, as has
> been pointed out and recommended by many of the list's pros.  It's a
> great tutorial, and I highly recommend it.
>
> However, I have either glossed something covered in it, or I have a
> fundamental misunderstanding of some part of IPTables.
>
> I know that the route works.  I've verified it.  I can move IPTraffic
> when I set all of my policies on my filter script to accept.  However,
> when I set my policies on my script to drop, Nothing talks any more.

My recommendation is to put a LOG rule at the end of each chain, just before 
the default DROP policy takes effect, and you'll see what packets are getting 
that far and then being lost.

Regards,

Antony.

-- 
If J. Random Websurfer clicks on a button that promises dancing pigs on his 
computer monitor, and instead gets a hortatory message describing the 
potential dangers of the applet - he's going to choose dancing pigs over 
computer security any day. If the computer prompts him with a warning screen 
like: "The applet DANCING PIGS could contain malicious code that might do 
permanent damage to your computer, steal your life's savings, and impair your 
ability to have children," he'll click "OK" without even reading it. Thirty 
seconds later he won't even remember that the warning screen even existed.

 - Bruce Schneier "Secrets and Lies"

                                                     Please reply to the list;
                                                           please don't CC me.

Re: More neqbie questions

[Eric Ellis]

Antony Stone wrote:

> On Monday 02 August 2004 6:46 pm, Eric Ellis wrote:
> 
> 
>>This is one of those things that's been hounding me for the past few
>>weeks that I can't understand what's *exactly* going on...
>>
>>I've been using the IPTables tutorial from
>>http://iptables-tutorial.frozentux.net/chunkyhtml/index.html, as has
>>been pointed out and recommended by many of the list's pros.  It's a
>>great tutorial, and I highly recommend it.
>>
>>However, I have either glossed something covered in it, or I have a
>>fundamental misunderstanding of some part of IPTables.
>>
>>I know that the route works.  I've verified it.  I can move IPTraffic
>>when I set all of my policies on my filter script to accept.  However,
>>when I set my policies on my script to drop, Nothing talks any more.
> 
> 
> My recommendation is to put a LOG rule at the end of each chain, just before 
> the default DROP policy takes effect, and you'll see what packets are getting 
> that far and then being lost.
> 
> Regards,
> 
> Antony.
> 
Now here's something interesting that I discovered when you mentioned 
it...

<code>
root@firewall:/var/log# tail syslog -f|grep 10.1.1.100 

Aug  2 13:41:38 firewall kernel: IN=eth1 OUT=eth0 SRC=10.1.1.100 
DST=212.19.193.43 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=
49518 DF PROTO=TCP SPT=3571 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 

Aug  2 13:41:41 firewall kernel: IN=eth1 OUT=eth0 SRC=10.1.1.100 
DST=212.19.193.43 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=
49558 DF PROTO=TCP SPT=3571 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 

Aug  2 13:41:47 firewall kernel: IN=eth1 OUT=eth0 SRC=10.1.1.100 
DST=212.19.193.43 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=
49660 DF PROTO=TCP SPT=3571 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 

Aug  2 13:42:17 firewall kernel: IN=eth1 OUT=eth0 SRC=10.1.1.100 
DST=66.35.250.151 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=
50070 DF PROTO=TCP SPT=3579 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 

Aug  2 13:42:20 firewall kernel: IN=eth1 OUT=eth0 SRC=10.1.1.100 
DST=66.35.250.151 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=
50113 DF PROTO=TCP SPT=3579 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 

Aug  2 13:42:26 firewall kernel: IN=eth1 OUT=eth0 SRC=10.1.1.100 
DST=66.35.250.151 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=
50187 DF PROTO=TCP SPT=3579 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 

 
                                                  </code>

It appears that all of my HTTP packets are making it through the chains 
without being picked up by my redirect rule.  The same appears to be 
happening with mail.  I put the LOG at the end of the 3 filter tables, 
In, Out, and FWD, so assuming that it's line by line filtering (eg, runs 
until a rule catches it), my packet is making it throught the chains 
without being caught.  Any suggesstions on what could cause that?

Re: More neqbie questions

[Antony Stone]

On Monday 02 August 2004 8:50 pm, Eric Ellis wrote:

> Antony Stone wrote:
> >
> > My recommendation is to put a LOG rule at the end of each chain, just
> > before the default DROP policy takes effect, and you'll see what packets
> > are getting that far and then being lost.

> Now here's something interesting that I discovered when you mentioned
> it...
>
> It appears that all of my HTTP packets are making it through the chains
> without being picked up by my redirect rule.  The same appears to be
> happening with mail.  I put the LOG at the end of the 3 filter tables,
> In, Out, and FWD, so assuming that it's line by line filtering (eg, runs
> until a rule catches it), my packet is making it throught the chains
> without being caught.  Any suggesstions on what could cause that?

Yes.   You have no FORWARD rule allowing packets to TCP port 80 (well, you do, 
but it's commented out...).

Regards,

Antony.

-- 
Bill Gates has personally assured the Spanish Academy that he will never allow 
the upside-down question mark to disappear from Microsoft word-processing 
programs, which must be reassuring for millions of Spanish-speaking people, 
though just a piddling afterthought as far as he's concerned.

 - Lynne Truss, "Eats, Shoots and Leaves"

                                                     Please reply to the list;
                                                           please don't CC me.

Re: More neqbie questions

[Antony Stone]

On Monday 02 August 2004 9:02 pm, Antony Stone wrote:

> On Monday 02 August 2004 8:50 pm, Eric Ellis wrote:
> > Antony Stone wrote:
> > > My recommendation is to put a LOG rule at the end of each chain, just
> > > before the default DROP policy takes effect, and you'll see what
> > > packets are getting that far and then being lost.
> >
> > Now here's something interesting that I discovered when you mentioned
> > it...
> >
> > It appears that all of my HTTP packets are making it through the chains
> > without being picked up by my redirect rule.  The same appears to be
> > happening with mail.  I put the LOG at the end of the 3 filter tables,
> > In, Out, and FWD, so assuming that it's line by line filtering (eg, runs
> > until a rule catches it), my packet is making it throught the chains
> > without being caught.  Any suggesstions on what could cause that?
>
> Yes.   You have no FORWARD rule allowing packets to TCP port 80 (well, you
> do, but it's commented out...).

Sorry, scrub that - you're right about the REDIRECT rule.   However, I don't 
see an INPUT rule allowing packets in to Squid on port 8080.

You also seem to have two OUTPUT rules allowing TCP packets to port 80 - why?

How about showing us the output of "iptables -L -nvx; iptables -L -t nat -nvx" 
so we can see the rules in the right order?

Regards,

Antony.

-- 
Success is a lousy teacher.  It seduces smart people into thinking they can't 
lose.

 - William H Gates III

                                                     Please reply to the list;
                                                           please don't CC me.

RE: More neqbie questions

[Jason Opperisano]

> # DNS
> $IPT -A INPUT -i $INT -p udp --dport 53 -j ACCEPT

is this machine a caching DNS server?

> ### OUTPUT chain
> # The only thing doing output on this box are proxy
> # servers, and the occasional SSH and HTTP for
> # testing.
> # SQUID proxy, and local HTTP requests.
> $IPT -A OUTPUT -p tcp --dport 80 -j ACCEPT
>
> # SSH
> $IPT -A OUTPUT -p tcp --dport 22 -j ACCEPT
>
> ### FORWARD chain
>
> $IPT -A OUTPUT -p tcp --dport 80 -j ACCEPT
>
>
> # SSH
>
> $IPT -A OUTPUT -p tcp --dport 22 -j ACCEPT

if the answer to my previous question was "yes," you're going to need:

	$IPT -A OUTPUT -p udp --dport 53 -j ACCEPT

if not--you're going to need:

	$IPT -A FORWARD -i $INT -p udp --dport 53 -j ACCEPT

> # Accept anything else that's been established
>
> $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>

might i also recommend:

	$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
	$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

(normally i put these as the first rule in each chain rather than the last)

another common piece that is absent, that is probably causing your squid redirect to fail:

	$IPT -A INPUT -i lo -j ACCEPT
	$IPT -A OUTPUT -o lo -j ACCEPT

-j

RE: More neqbie questions

[Jason Opperisano]

> Now here's something interesting that I discovered when you mentioned
> it...
>
> <code>
> root@firewall:/var/log# tail syslog -f|grep 10.1.1.100
>
> Aug  2 13:41:38 firewall kernel: IN=eth1 OUT=eth0 SRC=10.1.1.100
> DST=212.19.193.43 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=
> 49518 DF PROTO=TCP SPT=3571 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0

your redirect rule is:

	$IPT -t nat -A PREROUTING -i $INT -p tcp --dport 80 \
	  -j REDIRECT --to-port 8080

where $INT = eth0

the inbound interface of the logged packet above is eth1; therefore, it does not match your REDIRECT rule (or any FORWARD rule either).

are your interface variables ($INT and $EXT) backwards?

-j

RE: More neqbie questions

[Jason Opperisano]

> The "Check the obvious" answer fixed 90% of my problems.  Thanks Jason.  :D

Glad to hear it...

> THe last 10% is still the Squid Proxy.  Here's a dump of my current rule
> set, as requested by Antony

Thanks--I'm leaving this intact for the sake of the list.

My thought on the squid problem is that you are REDIRECT-ing to port 8080, yet you have no INPUT rule to allow traffic to that port; like:

	iptables -A INPUT -p tcp --syn -i $INT -s $INTERNAL_NET --dport 8080 -j ACCEPT

Now, you *do* have an INPUT rule for 8000--is that something else, or was that a typo?

> root@firewall:/etc/iptables# iptables -L -nvx; iptables -L -t nat -nvx
>
> Chain INPUT (policy DROP 102 packets, 19663 bytes)
>
>      pkts      bytes target     prot opt in     out     source
>       destination
>        46     3904 ACCEPT     all  --  *      *       0.0.0.0/0
>     0.0.0.0/0           state RELATED,ESTABLISHED
>
>
>         0        0 ACCEPT     all  --  lo     *       0.0.0.0/0
>     0.0.0.0/0
>         0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:22
>         0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:8000
>         0        0 ACCEPT     udp  --  eth1   *       0.0.0.0/0
>     0.0.0.0/0           udp dpt:53
>         0        0 DROP       udp  --  eth1   *       0.0.0.0/0
>     200.21.1.255        udp dpts:135:139
>       102    19663 LOG        all  --  *      *       0.0.0.0/0
>     0.0.0.0/0           LOG flags 0 level 4
>
>
> Chain FORWARD (policy DROP 7 packets, 392 bytes)
>
>      pkts      bytes target     prot opt in     out     source
>       destination
>       132     9660 ACCEPT     all  --  *      *       0.0.0.0/0
>     0.0.0.0/0           state RELATED,ESTABLISHED
>
>
>         0        0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:80
>         0        0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:22
>         0        0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:21
>         0        0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:25
>         0        0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:110
>         0        0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:143
>         7      392 LOG        all  --  *      *       0.0.0.0/0
>     0.0.0.0/0           LOG flags 0 level 4
>
>
> Chain OUTPUT (policy DROP 0 packets, 0 bytes)
>
>      pkts      bytes target     prot opt in     out     source
>       destination
>        45     3880 ACCEPT     all  --  *      *       0.0.0.0/0
>     0.0.0.0/0           state RELATED,ESTABLISHED
>
>
>         0        0 ACCEPT     all  --  *      lo      0.0.0.0/0
>     0.0.0.0/0
>         0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:80
>         0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:22
>         0        0 ACCEPT     udp  --  *      *       0.0.0.0/0
>     0.0.0.0/0           udp dpt:53
>         0        0 LOG        all  --  *      *       0.0.0.0/0
>     0.0.0.0/0           LOG flags 0 level 4
> Chain PREROUTING (policy ACCEPT 99817 packets, 17098458 bytes)
>
>      pkts      bytes target     prot opt in     out     source
>       destination
>         3      144 REDIRECT   tcp  --  eth1   *       0.0.0.0/0
>     0.0.0.0/0           tcp dpt:80 redir ports 808
> 0
>
>
>
> Chain POSTROUTING (policy ACCEPT 656 packets, 45391 bytes)
>
>      pkts      bytes target     prot opt in     out     source
>       destination
>         0        0 MASQUERADE  tcp  --  *      *       0.0.0.0/0
>      0.0.0.0/0
>
>
> Chain OUTPUT (policy ACCEPT 1459 packets, 105475 bytes)
>
>      pkts      bytes target     prot opt in     out     source
>       destination
>
> I'll be glad when I can move away from windows networks.  I didn't
> realize how much spam was created on ports 135-138 until I started
> trying to parse the syslog.

I'm a big fan of the pkttype match:

  iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP

Keeps me from having to chase down every port that every OS/App is going to decide to broadcast on...

-j