Re: Transparent bridge firewall with bridge-nf
On Thu, 2003-10-30 at 08:53, Norbert Preining wrote: > Our bridged/fw was running 160 day with code from there. Now I have > installed a new kernel (2.4.22) with the current ebtables code > (ebtables.sf.net) which can do even more, although I don't need it. But > ebtables is the code in 2.6 and actively maintained, while the > bridge.sf.net code is not maintained anymore. > Go for it. It is easy, one patch. And then you can do ALL (contrary to > the opinion of another reply) you can do with iptables on the forward > table. That's what I thought. In fact I've got a test setup going where I use iptables exclusively. The ebtables code for filtering on the link layer sounds nice but I don't see any need for that. What makes the bridge setup appealing to me is that I can simplify the routing tables. The network looks something like this (excuse my pittyful ascii arts skills): | Internet | | -- -.-.-.-.-.-.-.-.-.-.| Campus | | | abc.def.0.0/16 | . -- | | . ... | . | Bridge | . . . . __|__ |. / \ tr0| |eth0 |. | || F| LAN (abc.def.131.0/24) . | || W| . \_/ . abc.def.130.0/24 . . ... Everything inside the dotted rectangle is our network. The people on the left (abc.def.130.0/24) are an associated institute and we share some servers. Both us and them have gateways to the campus network which obviously creates a loop (along the dash-dotted line). Could this call for trouble? > The one obvious advantage is that the bridge doesn't have an IP address > Well, not necessary. Ours have a IP adress, but is completely closed > from the outside, while I can log in from the inside. Well, obviously you will need an IP to do remote administration of the machine but we have a physically separate private net for that. So the bridge will get a third nic with a 192... IP address and an ssh server listening on that interface. But the bridge interface itself won't have an IP. And for something actually debian related: Do you know of a woody backport of the ebtables package? Although I don't need it right away some of the things descibed on ebtables.sf.net sound like they could come in handy sometime. Cheers, Ben
Re: Transparent bridge firewall with bridge-nf
On Thu, 2003-10-30 at 08:53, Norbert Preining wrote: > Our bridged/fw was running 160 day with code from there. Now I have > installed a new kernel (2.4.22) with the current ebtables code > (ebtables.sf.net) which can do even more, although I don't need it. But > ebtables is the code in 2.6 and actively maintained, while the > bridge.sf.net code is not maintained anymore. > Go for it. It is easy, one patch. And then you can do ALL (contrary to > the opinion of another reply) you can do with iptables on the forward > table. That's what I thought. In fact I've got a test setup going where I use iptables exclusively. The ebtables code for filtering on the link layer sounds nice but I don't see any need for that. What makes the bridge setup appealing to me is that I can simplify the routing tables. The network looks something like this (excuse my pittyful ascii arts skills): | Internet | | -- -.-.-.-.-.-.-.-.-.-.| Campus | | | abc.def.0.0/16 | . -- | | . ... | . | Bridge | . . . . __|__ |. / \ tr0| |eth0 |. | || F| LAN (abc.def.131.0/24) . | || W| . \_/ . abc.def.130.0/24 . . ... Everything inside the dotted rectangle is our network. The people on the left (abc.def.130.0/24) are an associated institute and we share some servers. Both us and them have gateways to the campus network which obviously creates a loop (along the dash-dotted line). Could this call for trouble? > The one obvious advantage is that the bridge doesn't have an IP address > Well, not necessary. Ours have a IP adress, but is completely closed > from the outside, while I can log in from the inside. Well, obviously you will need an IP to do remote administration of the machine but we have a physically separate private net for that. So the bridge will get a third nic with a 192... IP address and an ssh server listening on that interface. But the bridge interface itself won't have an IP. And for something actually debian related: Do you know of a woody backport of the ebtables package? Although I don't need it right away some of the things descibed on ebtables.sf.net sound like they could come in handy sometime. Cheers, Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transparent bridge firewall with bridge-nf
On Mit, 29 Okt 2003, Benjamin Goedeke wrote: > http://bridge.sf.net to replace the firewall once the transition to Our bridged/fw was running 160 day with code from there. Now I have installed a new kernel (2.4.22) with the current ebtables code (ebtables.sf.net) which can do even more, although I don't need it. But ebtables is the code in 2.6 and actively maintained, while the bridge.sf.net code is not maintained anymore. Go for it. It is easy, one patch. And then you can do ALL (contrary to the opinion of another reply) you can do with iptables on the forward table. Very nice and easy. (There were restrictions in the code for linux 2.2, but in 2.4 they are lifted). On the ebtables page there are also lots of interesting articles on the general setup, interaction etc. It is in 2.6, it is stable (160 days up, reboot only for new kernel). > The one obvious advantage is that the bridge doesn't have an IP address Well, not necessary. Ours have a IP adress, but is completely closed from the outside, while I can log in from the inside. Another advantage: If you have a broken bridge you just plug in a crossed out cable and everything is running still fine (although without a firewall), while you reboot or fix the bridge. With NAT this is impossible. Best wishes Norbert --- Norbert Preining Technische Universität Wien gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `If there's anything more important than my ego around, I want it caught and shot now.' --- Zaphod. --- Douglas Adams, The Hitchhikers Guide to the Galaxy
Re: Transparent bridge firewall with bridge-nf
On Mit, 29 Okt 2003, Benjamin Goedeke wrote: > http://bridge.sf.net to replace the firewall once the transition to Our bridged/fw was running 160 day with code from there. Now I have installed a new kernel (2.4.22) with the current ebtables code (ebtables.sf.net) which can do even more, although I don't need it. But ebtables is the code in 2.6 and actively maintained, while the bridge.sf.net code is not maintained anymore. Go for it. It is easy, one patch. And then you can do ALL (contrary to the opinion of another reply) you can do with iptables on the forward table. Very nice and easy. (There were restrictions in the code for linux 2.2, but in 2.4 they are lifted). On the ebtables page there are also lots of interesting articles on the general setup, interaction etc. It is in 2.6, it is stable (160 days up, reboot only for new kernel). > The one obvious advantage is that the bridge doesn't have an IP address Well, not necessary. Ours have a IP adress, but is completely closed from the outside, while I can log in from the inside. Another advantage: If you have a broken bridge you just plug in a crossed out cable and everything is running still fine (although without a firewall), while you reboot or fix the bridge. With NAT this is impossible. Best wishes Norbert --- Norbert Preining Technische Universität Wien gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `If there's anything more important than my ego around, I want it caught and shot now.' --- Zaphod. --- Douglas Adams, The Hitchhikers Guide to the Galaxy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transparent bridge firewall with bridge-nf
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >I administer a LAN that will soon be moved from private to public IP >space. The LAN is inside a university network and as such in a rather >hostile environment. Another alternative is a proxy-arp firewall. See http://www.blars.org/sapaf.html for some information on how to do this without needing multiple subnets. The bridging code was too experimental for me at the time I implemented a firewall with over 200 computers on 5 segments. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transparent bridge firewall with bridge-nf
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >I administer a LAN that will soon be moved from private to public IP >space. The LAN is inside a university network and as such in a rather >hostile environment. Another alternative is a proxy-arp firewall. See http://www.blars.org/sapaf.html for some information on how to do this without needing multiple subnets. The bridging code was too experimental for me at the time I implemented a firewall with over 200 computers on 5 segments. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature.
Re: Transparent bridge firewall with bridge-nf
> as opposed to a setup with a firewall+router.
With Linux there are few problems with transparent firewalling setup - ie,
normal iptables don't work with such setup to well, you need to use special
bridge-iptables, ebtables IIRC. One drawback to that is that you can't do
everything your'e used to do with iptables, you need to limit yourself to
relatively simpler rules ( if all you need is filter out some ports then
there's not limitation here ).
{ Similiar setup using OpenBSD is very clean and works flawlessly out of the
box ( and using standard pf ) }
> and remains invisible at the cost of giving away the real IP addresses
I don't think being invisible is that much of security measure, it sure is
nice, but the real kick in being invisible is that you can firewall your
users without changing infrastructure, you can put your firewall about anywhere.
Being invisible doesen't make you invulnerable (as all comic readers know;),
if you've got snort on your firewall and there's a bug in it's parsing code,
you're still going to be sorry...
> keep hiding the real IP addresses of the servers or to hide the firewall
I don't get it, what do you accomplish by hiding real IP address of
something? Incoming-blocking firewalling is just a byproduct of NAT,
wouldn't you prefer the real thing?
--
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9
Re: Transparent bridge firewall with bridge-nf
> as opposed to a setup with a firewall+router.
With Linux there are few problems with transparent firewalling setup - ie,
normal iptables don't work with such setup to well, you need to use special
bridge-iptables, ebtables IIRC. One drawback to that is that you can't do
everything your'e used to do with iptables, you need to limit yourself to
relatively simpler rules ( if all you need is filter out some ports then
there's not limitation here ).
{ Similiar setup using OpenBSD is very clean and works flawlessly out of the
box ( and using standard pf ) }
> and remains invisible at the cost of giving away the real IP addresses
I don't think being invisible is that much of security measure, it sure is
nice, but the real kick in being invisible is that you can firewall your
users without changing infrastructure, you can put your firewall about anywhere.
Being invisible doesen't make you invulnerable (as all comic readers know;),
if you've got snort on your firewall and there's a bug in it's parsing code,
you're still going to be sorry...
> keep hiding the real IP addresses of the servers or to hide the firewall
I don't get it, what do you accomplish by hiding real IP address of
something? Incoming-blocking firewalling is just a byproduct of NAT,
wouldn't you prefer the real thing?
--
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
