On 20-Jun-01 Martin Peikert wrote:

...

Hi all, I have a problem with ipchains and the Suse-firewall script. I have more than one IP bound (Through IP Aliasing) to my external interface. However if I run the Script, All traffic passes through for say eth0, but for any of the other "Virtual interfaces", it doesn't allow any traffic through. What would the rule look like for Passing SMTP from the net

Wilhelm Tesnaar wrote: through

...

to the firewall using an interface called eth0:1 ipaddress 10.0.0.63 and internal net int of 192.168.0.254

Bad news: AFAIK ipchains does not support virtual interfaces.

That's only half the truth. You can not use a notation like "eth0:0...255" with ipchains (option -i) I think, but you don't have to. Say if you had hooked 192.168.1.2 on eth0:0 you could use the following rules for smtp: ipchains -A input -i eth0 -p tcp -s any/0 1024:65535 -d 192.168.1.2 25 -j ACCEPT ipchains -A output -i eth0 -p tcp ! -y -s 192.168.1.2 25 -d any/0 1024:65535 -j ACCEPT ipchains -A output -i eth0 -p tcp -s 192.168.1.2 1024:65535 -d any/0 25 -j ACCEPT ipchains -A input -i eth0 -p tcp ! -y -s any/0 25 -d 192.168.1.2 1024:65535 -j ACCEPT The trick is that you tell ipchains the physical network interface (eth0) but another IP which is assigned to it by IP aliasing. This neatly works with manually configured ipchains packet filters in some of my firewall installations.

-- martin.peikert@innominate.com project manager innominate AG security appliances http://www.innominate.com tel: +49.30.308806-0 fax: -77 gpg: http://innominate.org/gpg/mpe.gpg

--- Boris Lorenz System Security Admin *nix - *nux ---

On 20-Jun-01 Andreas Rittershofer wrote:

...

That's only half the truth. You can not use a notation like "eth0:0...255" with ipchains (option -i) I think, but you don't have to. Say if you had hooked 192.168.1.2 on eth0:0 you could use the following rules for smtp:

ipchains -A input -i eth0 -p tcp -s any/0 1024:65535 -d 192.168.1.2 25 -j ACCEPT ipchains -A output -i eth0 -p tcp ! -y -s 192.168.1.2 25 -d any/0 1024:65535 -j ACCEPT ipchains -A output -i eth0 -p tcp -s 192.168.1.2 1024:65535 -d any/0 25 -j ACCEPT ipchains -A input -i eth0 -p tcp ! -y -s any/0 25 -d 192.168.1.2 1024:65535 -j ACCEPT

The trick is that you tell ipchains the physical network interface (eth0) but another IP which is assigned to it by IP aliasing. This neatly works with manually configured ipchains packet filters in some of my firewall installations.

In this example the different addresses of the interface eth0 are assigned to different chains (input, output); is it also possible to use different ip-addresses for one interface in the same chain?

Yes, it's possible. Look at my smtp example: There are four lines, two inputs and two outputs for one IP. If you want to use this for another IP, simply copy'n'paste them and replace the IP address with the next one and keep the option "-i eth0". Do so for every virtual IP you have and service you want to offer. However, this gives you lots of work if something changes. A more elegant way would be to create a chain for every (virtual) IP you have and use ipchains-save/ipchains-restore to partly enable or disable firewalling. This is particularly usefull if you have a standard packet filter config for every customer/domain which could be reproduced easily for a new entry.

mfg ar

-- mailto:andreas@rittershofer.de http://www.rittershofer.de PGP-Public-Key http://www.rittershofer.de/ari.htm

--- Boris Lorenz System Security Admin *nix - *nux ---

...

Bad news: AFAIK ipchains does not support virtual interfaces.

Ohoh, thats really bad news! Does iptables support aliased interfaces?

I don't think so. It's just that the kernel matches yet another IP address to the interface. There is no way for the kernel to determine on which "virtual" interface a packet came in. And you have to ask yourself the question: Why should it? It arrived on eth0, it's just not the primary ip address of the NIC. This is also the case when a packet is subject to ip-forwarding (commonly named "routing"). Match the packets with the IP address - or use an additional NIC.

I would prefer ipchains, because iptables are still buggy and insecure, see ftp.

I'd be careful with such a statement. It's too general...

mfg ar

Thanks, Roman. -- - - | Roman Drahtmüller // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -

...

...

I would prefer ipchains, because iptables are still buggy and insecure, see ftp.

I'd be careful with such a statement. It's too general...

See http://cert.uni-stuttgart.de/ticker/article.php?mid=330

Basically the same problem affected half a dozen firewall products, the v2.2 kernel as well as the v2.0 kernel a while ago as well. The general statement that the filters are less secure is not valid with this bug. Roman.

...

...

http://cert.uni-stuttgart.de/ticker/article.php?mid=330

Basically the same problem affected half a dozen firewall products, the v2.2 kernel as well as the v2.0 kernel a while ago as well.

The general statement that the filters are less secure is not valid with this bug.

So I wonder why the article tells to prefer ipchains?

Because more errors are to be expected in the future. There will be announcements about this sooner or later, maybe next week already. The recommendation is partially wrong: Using ipchains does not equal using a 2.2 kernel. The personal-firewall on SuSE-7.2 uses ipchains as well, just with the ipchains compat kernel module. If you don't use connection tracking, you're not vulnerable to this specific bug in the 2.4 filter subsystem.

mfg ar

Roman. -- - - | Roman Drahtmüller "Caution: Cape does not | SuSE GmbH - Security enable user to fly." | Nürnberg, Germany (Batman Costume warning label) | - -