Movatterモバイル変換


[0]ホーム

URL:


coLinux
Don't have an account?
Register
Sign In
Skip to content
235
pages

UsingcoLinux As a Firewall[]


coLinux can be used as a firewall, but it has to be done in a very specific fashion, or else the firewall is going to be able to be circumvented.

Right now, none of this has been tested. I'm explaining this as a matter of theory, which should work. When I do have time, I will update these pages with better, properly tested notes.

With standard internet firewalls, there are two ways of doing it, and both ways can be emualted withcoLinux. The first is having two NICs in a machine, one being "internal" and the other being "external". The external NIC takes care of all exterior communication to the Internet, while the internal deals with the internal network of the LAN. In order to bridge the communications between the LAN and the Internet, usually NAT is used, allowing systems on the inside to communicate out, while keeping any foreign traffic out by blocking ports. This is all well and good, but if an externally routeable network is used on the internal LAN portion, the ability to break into the internal network always exists, no matter how strong the filter or firewall is. For this reason, it is often better to use a non-routeable network on your internal network, to insure that noone can get into it.

In the world ofcoLinux, this type of network can be emulated with two bridged interfaces. One interface communicates with the "real world", while the other takes care of all LAN communications. All machines on the inside, including thecoLinux host, use non-routeable IP addresses while the other bridge interface uses an Internet routeable IP address. This way, the colinux can act as a NAT box.

The other way to do this is to use 1 bridged network, and allow it to communicate on two networks. This is called "one-armed routing", where all traffic comes in and out of the same NIC. With this one bridged interface, two aliases can be used (this part hasn't been tested.. its quite possible that a bridgedcoLinux interface won't communicate well with aliasing) and traffic can be communicated on both networks, bridging by NAT.


Ian Bonnycastle -- ibonny@gmail.com


There is a problem with this from a security point-of-view: BecausecoLinux uses the Windows TAP device to access the network hardware, every packet is STILL going to be processed by the Windows TCP/IP stack, so the system is still going to be vulnerable to weaknesses in the Windows networking code. Its a good way of adding routing / NAT / firewall capabilities to a windows box, but it's not going to be as secure as a native linux install.


Tom Martin -- tjmartin@gmail.com




Instructions (by Ian Bonnycastle, taken fromcoLinux-users List)The steps are as follows:

1. First make sure that you have a TAP driver installed on yourWindows machne thatcoLinux can use. This is going to be the maincommunications point betweencoLinux and Windows.

2. Make sure you have winpcap installed.

3. Make sure thatcoLinux is configured to use both these interfaces.I would suggest using eth0 for the external interface (to theInternet) and eth1 for the internal interface (to Windows), but thisis totally arbitrary.

4. On the TAP device, configure your network to whatever you like (I'mgoing to use 192.168.10.0/24 in this example), so make sure thatcoLinux is .1 and Windows is .5 (for example).

5. In Windows, set your default route and your nameserver to192.168.10.1 (in this example). This will point your Windows boxtowards the Internet.

6. Set up yourcoLinux external interface as either DHCP (if yourwindows box is connected directly to your cable modem) or an IP onyour network (if you have an internal network, or on a corporate LAN).

7. Set your winpcap interface to have the same MAC address as yourexternal interface. (How to do this is in the Wiki). This is not soimportant for wired NIC cards, but EXTREMELY important for wirelessethernet cards (if you don't do this, you're going to have difficultygettingcoLinux to talk to the wireless network).

8. Make sure (and this is extremely important too) you turn OFF TCP/IPon your external interface in Windows. Go into Network Properties, andclick the TCP/IP checkbox. Do this ONLY on the external interface.This will probably also disable the "File and Print Sharing" protocolas well.

Since now your system is set up correctly, you should have the:

Windows <====>coLinux <====> Internet

setup you want.coLinux should have a default route to the Internet,and Windows should have no *direct* connection to the Internetanymore. You can also set upcoLinux to do iptables firewalling (ifyou use kernel 2.6.x). This way, you should be able to properlyprotect your windows machine from the Internet. This way is alsopretty elaborate, so if you already have a corporate firewall, or arouter that does firewalling or NAT, using this method is usually toomuch overhead to make any sense. Its usually a good method for systems

  • directly* connected to the Internet. I've tested it, and it gets good

speed on my network.

  • NOTE: I just realized that you're going to have to set up NAT on yourcoLinux box with iptables to properly NAT all outbound connections from your Windows box. -- Ian

Note, however, that doing this is putting packets through the conetvirtual network driver *twice*, and could have potential speedproblems. I've never personally ran into them, but that doesn't meanthey're not there. YMMV.



Comment by <SzaTam>, Hungary: It works for me, but it's really not that fast. Although it is enough for most homedsl/cable connections. Combined with netfilter, you can do anything a standalone router can. For bridgingand qos you have to compile a custom kernel.

Comment by aderry, Hong Kong: I am usingcoLinux as a router on a 600 Mhz machine with two network interfaces. The setup is similar to what is described in this page except that I use two real interfaces. When both interfaces are bridged to co Linux using WinPCAP, the machine that hostcoLinux still have decent connection speed through the virtual router, but the speed of all other machines on local LAN is unacceptably slow. The problem disappeared when I changed the local LAN interface to native windows network bridging with a TAP interface. My subjective evaluation is that it performs as good as a standalone router.


MassTranslated on Sun Apr 23 17:36:59 UTC 2006

Community content is available underCC-BY-SA unless otherwise noted.

[8]ページ先頭

©2009-2025 Movatter.jp