iptables not prevent access

iptables not prevent access

[Xu, Qiang (FXSGSC)]

Hi, all:

I am running the command "iptables -p tcp -j REJECT -A INPUT -i eth0 -s 13.121.8.119/32 --dport 80", to reject http access from the host "13.121.8.119". The command returns without any error message. However, I still can acess the linux server from "13.121.8.119".

Anything goes wrong here? Any method to debug?

Hope someone helps,
Xu Qiang

RE: iptables not prevent access

[Rob Sterenborg]

netfilter-owner@vger.kernel.org <> wrote on :

> Hi, all:
> 
> I am running the command "iptables -p tcp -j REJECT -A INPUT
> -i eth0 -s 13.121.8.119/32 --dport 80", to reject http access
> from the host "13.121.8.119". The command returns without any
> error message. However, I still can acess the linux server from
> "13.121.8.119". 
> 
> Anything goes wrong here?

Is there a rule that would accept the http packet before it would hit this
rule?

> Any method to debug?

Place a LOG rule identical to the REJECT rule in front of it and look in
your messages log if it hits:

$ipt -A INPUT -i eth0 -s 13.121.8.119 -p tcp --dport 80 -j LOG \
  --log-level info --log-prefix "IPT: TEST: "
$ipt -A INPUT -i eth0 -s 13.121.8.119 -p tcp --dport 80 -j REJECT

If it doesn't hit, either the rule is incorrect (for what you want it to do)
or another rule has already accepted the packet.


Grts,
Rob

RE: iptables not prevent access

[Xu, Qiang (FXSGSC)]

> -----Original Message-----
> From: netfilter-owner@vger.kernel.org
> [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Rob Sterenborg
> Sent: Monday, September 15, 2008 3:34 PM
> To: netfilter@vger.kernel.org
> Subject: RE: iptables not prevent access
>
> Is there a rule that would accept the http packet before it
> would hit this rule?

Actually, this is the only rule that exists in the server.

> Place a LOG rule identical to the REJECT rule in front of it
> and look in your messages log if it hits:
>
> $ipt -A INPUT -i eth0 -s 13.121.8.119 -p tcp --dport 80 -j LOG \
>   --log-level info --log-prefix "IPT: TEST: "
> $ipt -A INPUT -i eth0 -s 13.121.8.119 -p tcp --dport 80 -j REJECT

We don't have "ipt" command, only "iptables" command, and "iptables --help" shows it doesn't support a option of "--log-level"
=====================================
GUMP:/tmp/nvram <45> iptables -A INPUT -i eth0 -s 13.121.8.119 -p tcp --dport 80 -j LOG  --log-level info --log-prefix "IPT: TEST: "
iptables v1.2.8: Unknown arg `--log-level'
Try `iptables -h' or 'iptables --help' for more information.
=====================================

> If it doesn't hit, either the rule is incorrect (for what you
> want it to do) or another rule has already accepted the packet.

What's strange is that, when I run the same command to other machines, say 13.121.8.120, the http access is successfully rejected. Does that mean something wrong with the network configuration of the machine 13.121.8.119? What is the possible cause of that behavior?

Another thing is quite strange, when capturing network trace from and to 13.121.8.119, I can't find any packet associated with the server which runs "iptables" command. However, when I was capturing network trace from and to 13.121.8.120 (which was successfully blocked), I can see some network packets associated with the server.

Got confused...

> Grts,
> Rob

Re: iptables not prevent access

[Vimal]

> What's strange is that, when I run the same command to other machines, say 13.121.8.120, the http access is successfully rejected. Does that mean something wrong with the network configuration of the machine 13.121.8.119? What is the possible cause of that behavior?
>

This could have been possible only if the rule doesn't match it.
Let's look at the rule:

* -i eth0 ... If this doesn't match, it means that there is some other
routing going on that uses another interface to route the packet to
this particular IP address. Try pasting the routing table here, so
that we can see.
* -p tcp ... This has to be matched :)
* --dport=80 ... Unless you're running the webserver on some other
port, this is likely to match as well.

So, it looks like the packet isn't arriving via interface eth0.

> Another thing is quite strange, when capturing network trace from and to 13.121.8.119, I can't find any packet associated with the server which runs "iptables" command. However, when I was capturing network trace from and to 13.121.8.120 (which was successfully blocked), I can see some network packets associated with the server.

You might have done the network trace on one interface. How many
interfaces are there:
* On the server
* On the client (13.121.8.119)

What is the server IP address?

From what you say, it looks like 13.121.8.119 and the server have
established contact via an interface that is other than eth0.

-- 
Vimal

RE: iptables not prevent access

[Xu, Qiang (FXSGSC)]

> -----Original Message-----
> From: Vimal [mailto:j.vimal@gmail.com]
> Sent: Monday, September 15, 2008 6:42 PM
> To: Xu, Qiang (FXSGSC)
> Cc: Rob Sterenborg; netfilter@vger.kernel.org
> Subject: Re: iptables not prevent access
>
> > What's strange is that, when I run the same command to
> other machines, say 13.121.8.120, the http access is
> successfully rejected. Does that mean something wrong with
> the network configuration of the machine 13.121.8.119? What
> is the possible cause of that behavior?
> >
>
> This could have been possible only if the rule doesn't match it.
> Let's look at the rule:
>
> * -i eth0 ... If this doesn't match, it means that there is
> some other routing going on that uses another interface to
> route the packet to this particular IP address. Try pasting
> the routing table here, so that we can see.

How to find the routing table? 13.121.8.119 is a Windows 2003 Server OS.

> * -p tcp ... This has to be matched :)
> * --dport=80 ... Unless you're running the webserver on some
> other port, this is likely to match as well.

These two should have no problem. The web server is run on port 80.

> So, it looks like the packet isn't arriving via interface eth0.

Looks like so. But from what I see, 13.121.8.119 has only one network card. Is it possible that it has interfaces other than eth0?

> You might have done the network trace on one interface. How
> many interfaces are there:
> * On the server
> * On the client (13.121.8.119)

There is definitely only one interface on the server (13.121.8.106), and from the network configuration, I see that 13.121.8.119 (the client) has only one network card. Does this mean it has only one ethernet interface?

> What is the server IP address?

13.121.8.106

> From what you say, it looks like 13.121.8.119 and the server
> have established contact via an interface that is other than eth0.

Yep, looks like so. But I have no clear proof of it. I have got some screen captures of the network settings of 13.121.8.119. Can I send them to you guys as attachments?

Thanks a lot,
Xu Qiang

Re: iptables not prevent access

[Simon Gray]

> How to find the routing table? 13.121.8.119 is a Windows 2003 Server OS.
>   
netstat -nr

^^ Works on both windows and linux

RE: iptables not prevent access

[Xu, Qiang (FXSGSC)]

> -----Original Message-----
> From: Simon Gray [mailto:iptables@tech.nologi.es]
> Sent: Monday, September 15, 2008 7:27 PM
> To: Xu, Qiang (FXSGSC)
> Cc: netfilter@vger.kernel.org
> Subject: Re: iptables not prevent access
>
> netstat -nr
>
> ^^ Works on both windows and linux

The following is the output of the command. Anything wrong here?

-------------------------------------
C:\Documents and Settings\Administrator>netstat -nr

IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 50 8d 7e 51 29 ...... NVIDIA nForce Networking Controller - Virtual
l Machine Network Services Driver
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       13.121.8.1     13.121.8.119     20
       13.121.8.0    255.255.255.0     13.121.8.119     13.121.8.119     20
     13.121.8.119  255.255.255.255        127.0.0.1        127.0.0.1     20
   13.255.255.255  255.255.255.255     13.121.8.119     13.121.8.119     20
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1      1
        224.0.0.0        240.0.0.0     13.121.8.119     13.121.8.119     20
  255.255.255.255  255.255.255.255     13.121.8.119     13.121.8.119      1
Default Gateway:        13.121.8.1
===========================================================================
Persistent Routes:
  None
-------------------------------------

Thanks,
Xu Qiang

Re: iptables not prevent access

[Vimal]

>
> The following is the output of the command. Anything wrong here?

These are the routing tables of the server, right?

Could you also post the routing tables from:
* the client from whom you were able to access
* The client from whom you _were NOT_ able to access


> 0x10003 ...00 50 8d 7e 51 29 ...... NVIDIA nForce Networking Controller - Virtual

Generally, one should comment out the last 3 bytes as they are
supposed to be unique :)

I hope that these routing tables are for the server
> Active Routes:
> Network Destination        Netmask          Gateway       Interface  Metric
>          0.0.0.0          0.0.0.0       13.121.8.1     13.121.8.119     20
>       13.121.8.0    255.255.255.0     13.121.8.119     13.121.8.119     20

I am not able to understand this routing entry. Why is the gateway
address the same as the computer? Is this equivalent to the * entry in
the output of the `route' command in Linux?

-- 
Vimal

Re: iptables not prevent access

[Vimal]

> How to find the routing table? 13.121.8.119 is a Windows 2003 Server OS.

As someone mentioned on this thread, use: netstat -nr and paste the output here.

>
>> So, it looks like the packet isn't arriving via interface eth0.
>
> Looks like so. But from what I see, 13.121.8.119 has only one network card. Is it possible that it has interfaces other than eth0?

Hmmm... Could you paste the output of an ifconfig equivalent program?
I am not sure what it is on Windows (ipconfig, maybe?). But, this will
show all the network interfaces.

You did mention that you ran a network packet capturing program. Could
you run it on _all_ interfaces?

(Just a wild guess) One other possibility is that your server == your
client (13.121.8.119). In this case, all packets are routed via lo,
and not via eth0. :) Can you type: http://127.0.0.1 in your browser to
see if you can access the website?

>
> Yep, looks like so. But I have no clear proof of it. I have got some screen captures of the network settings of 13.121.8.119. Can I send them to you guys as attachments?
>

Could you try this:

* Run the sniffing software on the client, capturing _all_ packets
(without any filter) and on _all_ interfaces.
* From the client (119) access the server webpage.
* See what you get on the client side.

I hope I wasn't too confusing.

-- 
Vimal

RE: iptables not prevent access

[Xu, Qiang (FXSGSC)]

> -----Original Message-----
> From: Vimal [mailto:j.vimal@gmail.com]
> Sent: Monday, September 15, 2008 8:06 PM
> To: Xu, Qiang (FXSGSC)
> Cc: Rob Sterenborg; netfilter@vger.kernel.org
> Subject: Re: iptables not prevent access
>
>
> As someone mentioned on this thread, use: netstat -nr and
> paste the output here.

Done.

> Hmmm... Could you paste the output of an ifconfig equivalent program?
> I am not sure what it is on Windows (ipconfig, maybe?). But,
> this will show all the network interfaces.

The output of the command "ipconfig"
------------------------------------
C:\Documents and Settings\Administrator>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : nutrinity
   Primary Dns Suffix  . . . . . . . : crmttrinity.lab
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : crmttrinity.lab

Ethernet adapter Local Area Connection 2:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : NVIDIA nForce Networking Controller
   Physical Address. . . . . . . . . : 00-50-8D-7E-51-29
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 13.121.8.119
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 13.121.8.1
   DNS Servers . . . . . . . . . . . : 127.0.0.1
                                       13.135.130.15
   Primary WINS Server . . . . . . . : 13.121.11.9
   Secondary WINS Server . . . . . . : 13.135.134.15
                                       13.151.134.15
------------------------------------
Seems only one ethernet interface.

> You did mention that you ran a network packet capturing
> program. Could you run it on _all_ interfaces?

Yes, with WireShark, I tried to capture all the packets with MacAddress (with the filter "ether host 00:50:8d:7e:51:29"), but there are still no packets to and from 13.121.8.106 (the server).

> (Just a wild guess) One other possibility is that your server
> == your client (13.121.8.119). In this case, all packets are
> routed via lo, and not via eth0. :) Can you type:
> http://127.0.0.1 in your browser to see if you can access the website?

The server is definitely not the client. The server is a printer (13.121.8.106). The client is a Windows 2003 Server (13.121.8.119).
:-(

>
> Could you try this:
>
> * Run the sniffing software on the client, capturing _all_
> packets (without any filter) and on _all_ interfaces.
> * From the client (119) access the server webpage.
> * See what you get on the client side.

Just as I said, open WebUI of 13.121.8.106 on 119 while capturing network packets with MacAddress, but that didn't help, either. :-(

> I hope I wasn't too confusing.
>
> --
> Vimal
>

Re: iptables not prevent access

[Vimal]

[Screenshots]
Looks like nothing is wrong.

Another possibility is that your gateway's netmask isn't defined properly.

When you want to contact the server, the client issues an ARP request
to find out the Mac address of the destination, since the destination
is on the same network as the client (source). It is quite possible
that the gateway's netmask (something other than 255.255.255.0) makes
it respond to this ARP, thinking that it should route this packet to
the destination.

In fact, try this one too:

* From the client, access the webpage
* From the server, check the access logs, and see which IP had
accessed the particular webpage you did in the previous step.

The two should be equal.

But, what continues to baffle me is the fact that no requests were
coming from your client's ethernet interface!
-- 
Vimal

RE: iptables not prevent access

[Xu, Qiang (FXSGSC)]

> -----Original Message-----
> From: Vimal [mailto:j.vimal@gmail.com]
> Sent: Monday, September 15, 2008 8:12 PM
> To: Xu, Qiang (FXSGSC)
> Cc: netfilter@vger.kernel.org
> Subject: Re: iptables not prevent access
>
> * From the client, access the webpage
> * From the server, check the access logs, and see which IP
> had accessed the particular webpage you did in the previous step.
>
> The two should be equal.

This is a good idea. I think you are probably right. The request received by the server perhaps does't come from 119 in the server's eyes, although the webpage IS opened from 119. But the server is a linux environment, and tailored quite a bit to run embedded system software. So apache is not in "usr/local". I've got to try to locate the access log in the printer first.
:-)

> But, what continues to baffle me is the fact that no requests
> were coming from your client's ethernet interface!

Me, too.

Thanks,
Xu Qiang

Re: iptables not prevent access

[Vimal]

> This is a good idea. I think you are probably right. The request received by the server perhaps does't come from 119 in the server's eyes, although the webpage IS opened from 119. But the server is a linux environment, and tailored quite a bit to run embedded system software. So apache is not in "usr/local". I've got to try to locate the access log in the printer first.
> :-)

I haven't yet read your previous mails about the routing tables. But,
if you could give this a try, then we can confirm the hypothesis.

Just like you blocked client 119 and it failed, and then you tried 120
and it worked; block the gateway and unblock 120. If it works from
120, but it doesn't work from 119 (now), it means that the request is
coming from the gateway for 119.

-- 
Vimal

RE: iptables not prevent access

[Xu, Qiang (FXSGSC)]

> -----Original Message-----
> From: netfilter-owner@vger.kernel.org
> [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Vimal
> Sent: Tuesday, September 16, 2008 11:53 AM
> To: Xu, Qiang (FXSGSC)
> Cc: netfilter@vger.kernel.org
> Subject: Re: iptables not prevent access
>
> Just like you blocked client 119 and it failed, and then you
> tried 120 and it worked; block the gateway and unblock 120.
> If it works from 120, but it doesn't work from 119 (now), it
> means that the request is coming from the gateway for 119.

I just tried "iptables -p tcp -j REJECT -A INPUT -i eth0 -s 13.121.8.0/24 --dport 80", to block 13.121.8.* from accessing 8.106 via WebUI. But the blocking still fails.
:-(

RE: iptables not prevent access

[Xu, Qiang (FXSGSC)]

> -----Original Message-----
> From: Vimal [mailto:j.vimal@gmail.com]
> Sent: Monday, September 15, 2008 8:12 PM
> To: Xu, Qiang (FXSGSC)
> Cc: netfilter@vger.kernel.org
> Subject: Re: iptables not prevent access
>
> In fact, try this one too:
>
> * From the client, access the webpage
> * From the server, check the access logs, and see which IP
> had accessed the particular webpage you did in the previous step.

This is really a good suggestion.

> But, what continues to baffle me is the fact that no requests
> were coming from your client's ethernet interface!

It turns out to be the web proxy that does evil behind the scene. Yesterday I thought of it, and modified the field "Do not use proxy server for addresses beginning with" for "8.119". On that machine, I appended ";13.*" into the field, the semicolon in the beginning serves as a separator to what already existed there. But some addresses already existed in the field made it ineffective. So it always didn't work, meaning the traffic to the server "8.106" always went through the proxy server.

Today, a colleague tried to block the telnet port 23, and it was blocked successfully. So the problem was narrowed down to http connection. And he tried to play with various scenarios with or without proxy in use. And he came to a conclusion that something is not quite right with the proxy. After this field is tidied up, blocking works.

Thanks to Vimal, and others who have given suggestions.
Xu Qiang

RE: iptables not prevent access

[Rob Sterenborg]

>> Is there a rule that would accept the http packet before it
>> would hit this rule?
> 
> Actually, this is the only rule that exists in the server.

Okay.

>> Place a LOG rule identical to the REJECT rule in front of it
>> and look in your messages log if it hits:
>> 
>> $ipt -A INPUT -i eth0 -s 13.121.8.119 -p tcp --dport 80 -j LOG \
>>   --log-level info --log-prefix "IPT: TEST: "
>> $ipt -A INPUT -i eth0 -s 13.121.8.119 -p tcp --dport 80 -j REJECT
> 
> We don't have "ipt" command, only "iptables" command, and

Yes.. $ipt would be a variable substituted by the actual iptables command.

> "iptables --help" shows it doesn't support a option of "--log-level"
> =====================================
> GUMP:/tmp/nvram <45> iptables -A INPUT -i eth0 -s

I'm looking at /tmp/nvram.. Is this a dedicated wireless router using
something like DD-WRT or OpenWRT?

> 13.121.8.119 -p tcp --dport 80 -j LOG  --log-level info --log-prefix
> "IPT: TEST: "
> iptables v1.2.8: Unknown arg `--log-level'
> Try `iptables -h' or 'iptables --help' for more information.
> =====================================

Well, IIRC the --log-level has been supported since forever (or so?) by the
LOG target.

iptables -j LOG --help
[...]
LOG v1.3.6 options:
 --log-level level    Level of logging (numeric or see syslog.conf)
 --log-prefix prefix  Prefix log messages with this prefix.


man iptables
[...]
  --log-level level
    Level of logging (numeric or see syslog.conf(5)).

  --log-prefix prefix
    Prefix log messages with the specified prefix; up to 29
    letters long, and useful  for  distinguishing messages
    in the logs.

>> If it doesn't hit, either the rule is incorrect (for what you
>> want it to do) or another rule has already accepted the packet.
> 
> What's strange is that, when I run the same command to other
> machines, say 13.121.8.120, the http access is successfully
> rejected. Does that mean something wrong with the network
> configuration of the machine 13.121.8.119? What is the
> possible cause of that behavior?

I can't possibly say unless I could see the configuration of each machine.
If these IP's are the actual IP addresses and should reachable on the
internet so they can be tested, I can tell you that both IP's return
"filtered" for http requests.

> Another thing is quite strange, when capturing network trace
> from and to 13.121.8.119, I can't find any packet associated
> with the server which runs "iptables" command. However, when
> I was capturing network trace from and to 13.121.8.120 (which
> was successfully blocked), I can see some network packets associated
> with the server. 
> 
> Got confused...

Me too: I don't know anything about your setup. The way you describe it the
logical thing would be that the rule works as expected like it does on the
other machine, but right know I couldn't tell you what's happening. Perhaps
someone else here has a clue.


Grts,
Rob