Militantly FREE software support.
Militantly FREE software support.
NavigationUser loginSpam?See spam posts on this site? If so, please don't reply to the spam! Instead, just report the URL to the webmaster. |
Problem with iptables-----BEGIN PGP SIGNED MESSAGE----- Hi all. May 3 14:19:54 srv-web 'OUT-unknown:' IN= OUT=eth0 MAC= OUT-unknown is the default rule for the OUTPUT chain (DROP). In my firehol setup for that interface i have these rules: policy drop This is a result of many tryings, but all without success. Chain out_public_lan_124 (1 references) out_public_lan_124_icmp_s2 0 -- 0.0.0.0/0 0.0.0.0/0 out_public_lan_124_http_s3 0 -- 0.0.0.0/0 0.0.0.0/0 out_public_lan_124_ftp_s4 0 -- 0.0.0.0/0 0.0.0.0/0 out_public_lan_124_all_c5 0 -- 0.0.0.0/0 0.0.0.0/0 out_public_lan_124_irc_c6 0 -- 0.0.0.0/0 0.0.0.0/0 out_public_lan_124_ftp_c7 0 -- 0.0.0.0/0 0.0.0.0/0 ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 state RELATED Chain out_public_lan_124_all_c5 (1 references) Chain out_public_lan_124_dns_s1 (1 references) For a complete set of rules i have attached the all ruleset. Pier iD8DBQFGOdT40EvuLV/O0yoRAuuvAKCVM8MK4ViDLmB+YlyoQKIl5RJpwACfXB4l Bookmark/Search this post with: 
|
• Debian Weekly News - Essential reading for any Debian fan. • Documentation - Debian's own authoritative documentation, including installation docs. • FAQ - Got questions about Debian GNU/Linux? • From Windows to Debian - Tips for converting from Windows to Debian GNU/Linux • Package of the Day. • Security - Security information and alerts! • Bug System - Bug tracking and instructions on reporting bugs. • CD Images - Where/how to get Debian GNU/Linux CD images. • Mailing List Subscription - Dozens of Debian-specific support mailing lists! • Mailing List Archives - Searchable archives of Debian's mailing lists. • Free Software Guidelines - Learn Debian's idea of what "free" software really is. • Package Listings - A very valuable tool: searchable, integrated with bug reports. • Apt-Get Sources - Sources for *.debs which are not official Debian packages. • Backports - Unofficial new software packages that have been "back-ported" to work with the Debian stable/official release. • Developer's Corner - Info about the people behind Debian, policies, and how to package *.deb files.
Problem with iptables
On Thu, May 03, 2007 at 02:26:32PM +0200, Pierguido wrote:
> I'm using Etch a server and i want to configure bind.
> After i've done everything i set up firehol (iptables parser) and
> noticed that, when firehol is on, i cannot make any request to the
> outside dns server.
>
> I checked the firehol log and i see:
>
> May 3 14:19:54 srv-web 'OUT-unknown:' IN= OUT=eth0 MAC=
> SRC=192.168.100.2 DST=213.140.2.49 LEN=70 TOS=00 PREC=0x00 TTL=64 ID=0
> DF PROTO=UDP SPT=53 DPT=53 LEN=50
Yep - looks like an outgoing DNS query
> OUT-unknown is the default rule for the OUTPUT chain (DROP).
>
> In my firehol setup for that interface i have these rules:
>
> policy drop
> protection strong
> server dns accept custom "--state NEW,ESTABLISHED"
> server icmp accept
> server http accept
> server ftp accept
> client all accept
>
> This is a result of many tryings, but all without success.
> Now, as far as i can understand, it seems as the packet originated from
> my dns server is not intercepted by any rule, going then to the default
> one (DROP).
Looking at the rules, I'd concur...
> These are the rules:
[big snip]
> Chain OUTPUT (policy DROP)
> target prot opt source destination
> ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
Strange: With this rule as the *first* rule in the OUTPUT chain,
*everything* outgoing should be accepted, regardless of source,
destination or protocol!?
> out_lan 0 -- 192.168.30.103 0.0.0.0/0
> out_public_lan_124 0 -- 192.168.100.2 0.0.0.0/0
> out_public_lan_125 0 -- 192.168.100.5 0.0.0.0/0
> ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 state RELATED
> ULOG 0 -- 0.0.0.0/0 0.0.0.0/0 limit: avg 1/sec burst 5 ULOG copy_range 0 nlgroup 1 prefix `'OUT-unknown:'' queue_threshold 1
And yet your log entry appears to be the result of this rule...
> DROP 0 -- 0.0.0.0/0 0.0.0.0/0
Are you 100% sure that these were the rules in effect at the time of the
log entry? It's not making sense ...
--
Karl E. Jorgensen
http://www.jorgensen.org.uk/
http://karl.jorgensen.com
==== Today's fortune:
Things worth having are worth cheating for.
Problem with iptables
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karl E. Jorgensen wrote:
> Strange: With this rule as the *first* rule in the OUTPUT chain,
> *everything* outgoing should be accepted, regardless of source,
> destination or protocol!?
>
>> out_lan 0 -- 192.168.30.103 0.0.0.0/0
>> out_public_lan_124 0 -- 192.168.100.2 0.0.0.0/0
>> out_public_lan_125 0 -- 192.168.100.5 0.0.0.0/0
>> ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 state RELATED
>> ULOG 0 -- 0.0.0.0/0 0.0.0.0/0 limit: avg 1/sec burst 5 ULOG copy_range 0 nlgroup 1 prefix `'OUT-unknown:'' queue_threshold 1
>
> And yet your log entry appears to be the result of this rule...
>
>> DROP 0 -- 0.0.0.0/0 0.0.0.0/0
>
> Are you 100% sure that these were the rules in effect at the time of the
> log entry? It's not making sense ...
Yes...100% sure...i was doing many test and the result was that i had to
disable firehol (and iptables as well).
I could try to set up a different ruleset manually with iptables to see
if the problem is a kind strange combination of rules, but i'd like to
use firehol because i had never problem with it and i'm satisfied.
I checked all the kernel config (it's 2.6.21.1 compiled by myself) and
all modules from netfilter are compiled.
UHm...i just checked an another server with more or less the same
configuration...just that this server has two phisical interfaces and i
don't use in firehol conf the rule "interface ethX:X name dst
xxx.xxx.xxx.xxx".
I changed the firehol conf on the problematic server (deleted the dst
xxx....) and now it works.
The conf before i read about it because of different configuration for
each virtual and phisical interface...now i check how is the conf and if
everything is ok.
Thanks all.
Pier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGOuSC0EvuLV/O0yoRAtq8AKClo97kIRomgIaB+he9nE18F0V67gCgjwMN
op6BXfwsOL7QXtPpBYid2Qs=
=Jn5P
-----END PGP SIGNATURE-----
--
Problem with iptables
On Fri, 04 May 2007 00:45:06 -0700, Pierguido wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Karl E. Jorgensen wrote:
>> Strange: With this rule as the *first* rule in the OUTPUT chain,
>> *everything* outgoing should be accepted, regardless of source,
>> destination or protocol!?
>>
>>> out_lan 0 -- 192.168.30.103 0.0.0.0/0
>>> out_public_lan_124 0 -- 192.168.100.2 0.0.0.0/0
>>> out_public_lan_125 0 -- 192.168.100.5 0.0.0.0/0
>>> ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 state
>>> RELATED
>>> ULOG 0 -- 0.0.0.0/0 0.0.0.0/0 limit:
>>> avg 1/sec burst 5 ULOG copy_range 0 nlgroup 1 prefix `'OUT-unknown:''
>>> queue_threshold 1
>>
>> And yet your log entry appears to be the result of this rule...
>>
>>> DROP 0 -- 0.0.0.0/0 0.0.0.0/0
>>
>> Are you 100% sure that these were the rules in effect at the time of the
>> log entry? It's not making sense ...
> Yes...100% sure...i was doing many test and the result was that i had to
> disable firehol (and iptables as well).
Check an iptables-save output to see if these rules are matched
against a different interface than intented.
--
Octavio.
--
Problem with iptables
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Octavio Alvarez wrote:
> Check an iptables-save output to see if these rules are matched
> against a different interface than intented.
At the end i had to return to the configuration i had that
problem....just i remove dst from the physical interface eth0 and
everything works.
But as i suspect, all the packets going to all addresses (even the
virtual) are intercepted by the eth0 rules (and bypassing eth0:0 end
eth0:1).
If i add the dst 192.168.30.103 to the eth0, than dns is not working.
I'm tryning to see which counter get upgraded but it's a bit
difficult...is there a tool to show in realtime the status of the counter?
Pier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGOwL50EvuLV/O0yoRAg30AKCVP8QzmwUqvO0g7yv54Mg0xOyB+gCcDLX4
5MBX+FgGbJhKdzL/vj2x3zU=
=7nes
-----END PGP SIGNATURE-----
--
Problem with iptables
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pierguido wrote:
[...]
> difficult...is there a tool to show in realtime the status of the counter?
Sorry...here the output of iptables-save
Pier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGOwOG0EvuLV/O0yoRAolVAKCEzhUn7dCeFMwXtan2kaSoQb2KHACg02vM
fnU8cLsYTxw11LPWulHW0B4=
=LLgW
-----END PGP SIGNATURE-----
Problem with iptables
On Fri, May 04, 2007 at 11:57:39AM +0200, Pierguido wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Pierguido wrote:
> [...]
> > difficult...is there a tool to show in realtime the status of the counter?
>
> Sorry...here the output of iptables-save
> # Generated by iptables-save v1.3.6 on Fri May 4 11:56:26 2007
> *filter
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
[big snip]
> -A INPUT -i lo -j ACCEPT
> -A INPUT -d 192.168.30.103 -i eth0 -j in_lan
> -A INPUT -d 192.168.100.2 -i eth0:0 -j in_public_lan_124
> -A INPUT -d 192.168.100.5 -i eth0:1 -j in_public_lan_125
This doesn't look right. As far as I know, you cannot distinguish
between ip-aliased interfaces in iptables. iptables deals with the names
of the physical interfaces (except for bridging, but that doesn't seem
relevant for you).
But it does accept very simple patterns: eth+ will match both eth0 and
eth1...
> -A INPUT -m state --state RELATED -j ACCEPT
> -A INPUT -m limit --limit 1/sec -j ULOG --ulog-prefix "'IN-unknown:'"
> -A INPUT -j DROP
> -A FORWARD -m state --state RELATED -j ACCEPT
> -A FORWARD -m limit --limit 1/sec -j ULOG --ulog-prefix "'PASS-unknown:'"
> -A FORWARD -j DROP
> -A OUTPUT -o lo -j ACCEPT
> -A OUTPUT -s 192.168.30.103 -o eth0 -j out_lan
> -A OUTPUT -s 192.168.100.2 -o eth0:0 -j out_public_lan_124
> -A OUTPUT -s 192.168.100.5 -o eth0:1 -j out_public_lan_125
Ditto here. I suspect that if you change eth0:0 and eth0:1 to eth0 (they
physical interface), things might just work!
> -A OUTPUT -m state --state RELATED -j ACCEPT
> -A OUTPUT -m limit --limit 1/sec -j ULOG --ulog-prefix "'OUT-unknown:'"
> -A OUTPUT -j DROP
--
Karl E. Jorgensen
http://www.jorgensen.org.uk/
http://karl.jorgensen.com
==== Today's fortune:
"To take a significant step forward, you must make a series of finite
improvements."
-- Donald J. Atwood, General Motors