SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
a firewall is a layer 3 device, it won't see any traffic on an internal network unless you are running a layer 2 firewall, i.e. transparently switching through it. you can achieve this with, for example, a linux box with a handful of NIC's in it and ebtables filtering the layer 2 bridged traffic rather than the iptables handling the layer 3 routed traffic.
in order to filter traffic, that filtering device needs to have full control of that traffic. this will only be the case if, rather than connecting these machines with an ethernet switch, you use the server as the switch, one nic per machine, and then use the bridge module to make those collection of NIC's behave as a switch. wihtout that direct involvement in the traffic, it will never see the traffic between two other nodes at all.
To clarify, that means instead of ethernet switch wich i currenly use now i need to use for instance if i use dsl router + 2 linux boxes + 2 winxp, that means that i need on linux server 5 separated nics? and the rest computers 1 nic per machine to connect, then bridge module to use nics as switch?
Wondering if theres similar solution regarding external switch ?
Now, by accomplish this it means that i can combine iptables/ebtables and have only 1 firewall controling the whole subnet.
Thats what i wanted to achieve.
Im looking for an opinion to see if its more secured than using firewalls on each machine ?
that's right, if you want to stop client 1 talking to client 2. I should say that what you're asking for is *very* uncommon. you really don't see anyone do it at all outside of high security enterprise networks. client firewalls are by far the more common approach.
ok, well we've not moved into 802.1q switching as of yet, but if you are already there, then yes you could use vlan's to achieve this. you *could* create one vlan for each switchport on your switch and trunk them all up to the server on an uplink port. this is the sort of physical architecture that many new NAC vendors are taking in the emerging markets, but they would be in a fail-open hardware environment, so the filtering device going down wouldn't be able to cause an outage. but yeah you could try that on a single nic if you already have a capable switch.
well to do it on one nic you'll need to invest in a managed switch which supports 802.1q. if i wanted one of these at a basic level I'd be paying about £400 for a Cisco 2960, but you can go cheaper with other vendors. fail-open would mean that if the filter device itself died the base level tin would still be able to allow systems to communicate as long as there was rudimentary power to the hardware. rebooting the box wouldn't interrupt connectivity etc...