All of lore.kernel.org
 help / color / mirror / Atom feed
* Iptables Drop rule - strange behaviour
       [not found] <CACJKonoWuj1=He00eD7e9YENHXvwEY1Hmg6_Cjq5GeYT6DchoQ@mail.gmail.com>
@ 2012-06-15 19:01 ` sreejith menon
  2012-06-15 21:36   ` Neal Murphy
  2012-06-16  7:50   ` sreejith menon
  0 siblings, 2 replies; 5+ messages in thread
From: sreejith menon @ 2012-06-15 19:01 UTC (permalink / raw)
  To: netfilter; +Cc: sreejith j menon

Hi,

I have the below setup for my firewall and i am using iptables 1.4.9.1 v


Client PC (eth0, 172.31.114.239)--------------(eth0 172.31.114.252)
Firewall Router (eth1, 10.2.2.2)--------------------Network PC
(10.2.2.1)

I have set the default policy as accept for my testing purpose. My aim
is to prevent ssh from Client PC to Network PC. But allow ssh from
Network PC to Client PC.

I have the following iptables rule

iptables -nvL

Chain INPUT (policy ACCEPT 744 packets, 46652 bytes)

 pkts bytes target     prot opt in     out     source               destination

 9989  780K ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0           state RELATED,ESTABLISHED


 Chain FORWARD (policy ACCEPT 3 packets, 180 bytes)

 pkts bytes target     prot opt in     out     source               destination

    82 17854 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0           state RELATED,ESTABLISHED

    11   660 DROP       tcp  --  *      eth1    0.0.0.0/0
0.0.0.0/0           source IP range 172.31.114.1-172.31.114.254 tcp
spts:2:65535 dpt:22 destination IP range 10.2.2.1-10.2.2.254


 Chain OUTPUT (policy ACCEPT 1741 packets, 149K bytes)

 pkts bytes target     prot opt in     out     source               destination
     0     0 DROP       tcp  --  *      eth1    0.0.0.0/0
0.0.0.0/0           source IP range 172.31.114.1-172.31.114.254 tcp
spt:22 dpts:2:65535 destination IP range 10.2.2.1-10.2.2.254

 Observations
 -------------------

1. Ssh from Network PC to client PC  --- ssh successful as expected
2. ssh from client pc to Network PC ---- ssh blocked as expected
3.  Again ssh from Network PC to client PC  --- ssh  blocked which was
not expected.
4. If i randomly insert some rules which has no relevance to ssh, and
do step 1 alone again - ssh sucessful
5.  Again do step 2 followed by step -- ssh blocked ..problem.

 Please help or any idea will be very much appreciated

Also, noted that if i have a ssh rule to deny from client PC to
network PC. If i do ftp, it is fine. But if i do ssh followed by ftp,
ftp doesnt work. please note that default policy is accept all. I did
not add or delete rules in between.


thanks and regards
sreejith

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Iptables Drop rule - strange behaviour
  2012-06-15 19:01 ` Iptables Drop rule - strange behaviour sreejith menon
@ 2012-06-15 21:36   ` Neal Murphy
  2012-06-16  7:50   ` sreejith menon
  1 sibling, 0 replies; 5+ messages in thread
From: Neal Murphy @ 2012-06-15 21:36 UTC (permalink / raw)
  To: netfilter

On Friday 15 June 2012 15:01:15 sreejith menon wrote:
> Hi,
> 
> I have the below setup for my firewall and i am using iptables 1.4.9.1 v
> 
> 
> Client PC (eth0, 172.31.114.239)--------------(eth0 172.31.114.252)
> Firewall Router (eth1, 10.2.2.2)--------------------Network PC
> (10.2.2.1)
> 
> I have set the default policy as accept for my testing purpose. My aim
> is to prevent ssh from Client PC to Network PC. But allow ssh from
> Network PC to Client PC.
> 
> I have the following iptables rule
> 
> iptables -nvL
> 
> Chain INPUT (policy ACCEPT 744 packets, 46652 bytes)
> 
>  pkts bytes target     prot opt in     out     source              
> destination
> 
>  9989  780K ACCEPT     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           state RELATED,ESTABLISHED
> 
> 
>  Chain FORWARD (policy ACCEPT 3 packets, 180 bytes)
> 
>  pkts bytes target     prot opt in     out     source              
> destination
> 
>     82 17854 ACCEPT     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           state RELATED,ESTABLISHED
> 
>     11   660 DROP       tcp  --  *      eth1    0.0.0.0/0
> 0.0.0.0/0           source IP range 172.31.114.1-172.31.114.254 tcp
> spts:2:65535 dpt:22 destination IP range 10.2.2.1-10.2.2.254
> 
> 
>  Chain OUTPUT (policy ACCEPT 1741 packets, 149K bytes)
> 
>  pkts bytes target     prot opt in     out     source              
> destination 0     0 DROP       tcp  --  *      eth1    0.0.0.0/0
> 0.0.0.0/0           source IP range 172.31.114.1-172.31.114.254 tcp
> spt:22 dpts:2:65535 destination IP range 10.2.2.1-10.2.2.254
> 
>  Observations
>  -------------------
> 
> 1. Ssh from Network PC to client PC  --- ssh successful as expected
> 2. ssh from client pc to Network PC ---- ssh blocked as expected
> 3.  Again ssh from Network PC to client PC  --- ssh  blocked which was
> not expected.
> 4. If i randomly insert some rules which has no relevance to ssh, and
> do step 1 alone again - ssh sucessful
> 5.  Again do step 2 followed by step -- ssh blocked ..problem.
> 
>  Please help or any idea will be very much appreciated
> 
> Also, noted that if i have a ssh rule to deny from client PC to
> network PC. If i do ftp, it is fine. But if i do ssh followed by ftp,
> ftp doesnt work. please note that default policy is accept all. I did
> not add or delete rules in between.

If the firewall does not employ NAT (that is, it's a 'simple' router), your 
DROP rule is close. You need a DROP rule that specifically identifies packets
  1. from the 172.X.X.X LAN (or range, or host),
  2. to the 10.X.X.X LAN (or range, or host),
  3. dest port 22,
  4. state NEW
That will drop all connection attempts from the 'outside' host (or LAN or 
range of addresses) to the 'inside' host (or LAN or range of addresses) to 
port 22, thus preventing the outside host(s) from connecting to port 22 on the 
inside. All other packets will be accepted (via your default policy).

This is not correct syntax but should illustrate the pieces needed for the 
single rule you want:
-A FORWARD -i eth0 \
           -source range 172.31.114.1-172.31.114.254 \
           -dest range 10.2.2.1-10.2.2.254 \
           -protocol tcp \
             -destport 22 \
             -m state --state NEW \
           -j DROP

If it's a NATting firewall, the solution may be more complex.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Iptables Drop rule - strange behaviour
  2012-06-15 19:01 ` Iptables Drop rule - strange behaviour sreejith menon
  2012-06-15 21:36   ` Neal Murphy
@ 2012-06-16  7:50   ` sreejith menon
  2012-06-16 12:22     ` sreejith menon
  1 sibling, 1 reply; 5+ messages in thread
From: sreejith menon @ 2012-06-16  7:50 UTC (permalink / raw)
  To: netfilter

Hi,

> This is not correct syntax but should illustrate the pieces needed for the
> single rule you want:
> -A FORWARD -i eth0 \
>          -source range 172.31.114.1-172.31.114.254 \
>           -dest range 10.2.2.1-10.2.2.254 \
>          -protocol tcp \
>             -destport 22 \
>             -m state --state NEW \
>           -j DROP


Thanks Neal. Appreciate your response. I understand and tried your
rule as well but the problem remains the same.

May be i havent given full details. Let me try once more.

I have currently power PC compiled both linux 2.6.35 for PPC along
with iptables v 1.4.9.1. As mentioned in the original mail, problem
persist. What is strange is i could see only the counter increasing
for iptables drop only once. No matter how many ssh packets i try to
sent , the DROP counter for the rule doesnt increase but the packet is
drop.

In order to debug i even tried to add a rule to allow ftp before
dropping the ssh rule. As again if i do send the ssh packet firs
followed by ftp packets, ftp packets are still dropped. I donot see
any counter increasing at all. This continues to happen untill i
insert some random rule in the forward table, followed by sending ftp
packets it is allowed. But send ssh packets and followed by ftp, both
are dropped.

Any information will be much appreciated.

thanks and regards
sreejith

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Iptables Drop rule - strange behaviour
  2012-06-16  7:50   ` sreejith menon
@ 2012-06-16 12:22     ` sreejith menon
  2012-06-16 17:23       ` sreejith menon
  0 siblings, 1 reply; 5+ messages in thread
From: sreejith menon @ 2012-06-16 12:22 UTC (permalink / raw)
  To: netfilter

On Sat, Jun 16, 2012 at 1:20 PM, sreejith menon
<sreejithjmenon@gmail.com> wrote:
> Hi,
>
>> This is not correct syntax but should illustrate the pieces needed for the
>> single rule you want:
>> -A FORWARD -i eth0 \
>>          -source range 172.31.114.1-172.31.114.254 \
>>           -dest range 10.2.2.1-10.2.2.254 \
>>          -protocol tcp \
>>             -destport 22 \
>>             -m state --state NEW \
>>           -j DROP
>
>


I have further narrowed down the problem. I added a single rule in
FORWARD Chain to reject ssh packets from 172.31.114.239 to 10.2.2.5 to
REJECT instead of DROP

 iptables -nvL
Chain INPUT (policy ACCEPT 15 packets, 1260 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       172.31.114.239
10.2.2.5            tcp dpt:22 reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 13 packets, 1316 bytes)
 pkts bytes target     prot opt in     out     source               destination


Observation
-----------------
1) ssh from 172.31.114.239 to 10.2.2.5 -  ssh rejected with icmp port
unreachable once. Counter increased by 1.
2) Again ssh from 172.31.114.239 to 10.2.2.5 - ssh dropped but no icmp
port unreachable received. Counter not increased.
3) ftp  from 172.31.114.239 to 10.2.2.5 - ftp dropped and no  Counter
got increased.


Another test scenario
--------------------------------

Instead of forwarding i decided to apply the same scenario to the INPUT rule

 iptables -nvL
Chain INPUT (policy ACCEPT 23 packets, 1820 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       172.31.114.239
172.31.114.253      tcp dpt:22 reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 17 packets, 2116 bytes)
 pkts bytes target     prot opt in     out     source               destination

Observation
------------------
1. ssh packets from 172.31.114.239 to 172.31.114.253 always rejected.
Counter always increased.
2. No problem with the ftp packets ie always allowed.


Summary of Observation
------------------------------------
There seems to be some drop problem with different ports in Forward
Chain. Input chain works fine.
Since the DROP counter are not increased for tcp packets, i feel like
all tcp packets are getting dropped once the drop rule is hit.

If either source or destination ip changes ie ssh/ftp to a different
machine with the same set of rules in FORWARD chain, it is allowed.

thanks and regards
sreejith

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Iptables Drop rule - strange behaviour
  2012-06-16 12:22     ` sreejith menon
@ 2012-06-16 17:23       ` sreejith menon
  0 siblings, 0 replies; 5+ messages in thread
From: sreejith menon @ 2012-06-16 17:23 UTC (permalink / raw)
  To: netfilter

Hi,

I found out the reason for dropping the packet.

On Debugging Kernel I found that in the forward path (ip_forward.c), a
particular part of code under a configuration flag
(CONFIG_NETFILTER_TABLE_INDEX) is getting executed and was giving the
wrong verdict of DROP for the packets.

I removed the same from .config file. Now the rules are working as
expected. I dont know the meaning of CONFIG_NETFILTER_TABLE_INDEX flag
and hence i cannot say whether it is a bug or not.

Thanks for the support. :-). I hope this mail might help somebody in the future.

thanks and regards
sreejith

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-06-16 17:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CACJKonoWuj1=He00eD7e9YENHXvwEY1Hmg6_Cjq5GeYT6DchoQ@mail.gmail.com>
2012-06-15 19:01 ` Iptables Drop rule - strange behaviour sreejith menon
2012-06-15 21:36   ` Neal Murphy
2012-06-16  7:50   ` sreejith menon
2012-06-16 12:22     ` sreejith menon
2012-06-16 17:23       ` sreejith menon

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.