Is LINUX the answer?

gewitty · April 30, 2004

I have a small home network, consisting of two desktops and a laptop (all running WIN XP Pro). The network runs both Ethernet and wireless. One of the desktops is dedicated to running just ZoneAlarm, AVG, SpyBot and a mailserver (MailTraq). This machine is also the primary connection to my DSL broadband service.

Given the considerable rise in the number of virus and trojan attacks on Windows that are happening lately, I am wondering if the primary machine would be safer running under LINUX. Not having had any experience of this OS, I don't know if this is a good idea or, if so, which version of LINUX would be best. I also don't know if ZoneAlarm, AVG and Mailtraq will run on LINUX.

Anyone got any advice please?

iamroot · April 30, 2004

Linux will definitely be more stable and safe than windows xp. Frankly, I've had horrible experiences with win xp. Personally, I prefer Red Hat Linux but its really up to you. Mandrake and SuSe are not bad as well. But a note of advice. If you intend to have a dual boot system with win xp/2000 and linux, dun try to access ntfs partitions from linux as it is dangerous. As for your applications, i don't think that those work on linux unless u use wine(sort of an emulator) but im sure you can find alternatives on the net.

Dapper Dan · April 30, 2004

I've never used it, but I know someone who has, plus I've seen a lot of positive remarks about Smoothwall on the net. Linux will certainly be a better server choice for you, but hopefully you are a computer enthusiast and will take on the challenge. Be prepared to research and learn because Linux is challenging. If you prevail, you will be greatly rewarded in the end!

Iamroot, I personally have not been aware of problems associated with just accessing NTFS partitions with Linux, and never had any problems reading Windows partitions back in my dual booting days. I do however understand there can be problems associated with writing to NTFS from Linux with some of the apps that are working toward that end, but I've never tried any of these.

blackpage · April 30, 2004

howdy gwitty,

a response to your question is probably twofolded ...

You are thinking about advancing in the right direction, driven by your security concerns. Things will probably only get worse in the future on the Windows-side of the internet. So any decision towards using Linux to harden your gateway/router/mailserver-machine is more than just agreeable.

On the other hand ...

You are about to enter the Linux-domain from the "server-side", and this can give you a lot of headaches if you lack a certain amount of necessary endurance as DapperDan has already mentioned.

As none of the progs you've mentioned is available under Linux you may want to take a brief look at what it would take (software- and effort-wise) to ensure the same functionality on your Desktop-machine as you now have ...

Firewall

Every contemporary Linux comes with a FW-module built into the "kernel" (the system-nucleus, so to say). This FW's called "iptables" and is one spifftastomatic, a**kickin' piece of security-software. There's literally no TCP/IP-issue that you could not catch with a specific IPTABLES-rule.

Many distros access IPTABLES through GUI-frontends that let you define those rules more easily (Smoothwall has been mentioned, and there are many more frontends, like FireStarter or Firewall-Builder).

INet-Connection Sharing (NAT)

This specific thing is also handled by iptables (the NAT-capabilities of this module respectively). Many of the above mentioned GUI-frontends will aid you in defining the needed filter-rules for this.

Many more things from this field can be achieved with iptables or additional apps. If you want to e.g. add a proxie too you may want to check out Squid, to just name a polular one.

Email-Stuff

This will be by far the most trickiest thing to set up. I dunno due to what Linux-tradition this is, but setting up a spam- and virus-filtering, mail-forwarding server can drive you nuts. Most distros come with the "regular" mail-mangling-progs like sendmail/fetchmail. I cannot really recommend the sendmail/fetchmail-couple for two reasons: (a) The sometimes really hideous config-file structure and ( the security issues that sendmail has. Of course, the basic sendmail/fetchmail-couple will not filter anything (but it would forward mails to the right accounts, given that a lot of things are set up properly (like aliases, permissions etc.)).

To make spam- and virus-filtering happen you have to "daisy-chain" multiple apps. You will need an MTA (Mail Transport Agent) like EXIM or QMAIL, a spamfilter (is there anything else but SPAMASSASIN? and a virus-filter (e.g CLAMAV which we use for our mail-servers).

As you can see there are a lot of apps and things involved and most definitely an even basic setup with minimum-functionality will take you up to several days if you haven't laid hands on Linux so far.

But the gain is indeed immense: If you decide to go all the way and maybe even tweak/harden your box you will have a halluva bullet-proof and reliable machine that will let you forget about things like "reboot" and which will be "99% immortal" (unless you pull the plug)

hope this helps

jimf43 · April 30, 2004

You don't just 'jump into' Linux. I think you would be wise to create a dual Boot so that you can begin to 'learn' if Linux is a viable solution for you. I have a similar setup. 1 desktop w/dual boot W2K & Debian, 1 desktop w/w2k and XP on the laptop.

I like Linux a great deal. It's a very interesting and powerful system which is being developed at a breakneck pace and has vast potential. It is also still an 'expert' system. You really have to have more than average experience, understanding and ability to deal with hardware and OS in general.

I'm an Engineer with Administration experience in everything from DOS through OS/2 and XP. I've been using Linux for about 3 years ... seriously for the last year, and, There is no way that I would use Linux for my main system at this point in time.

M$ phobia aside, I certainly 'would not' recommend that you switch from a system that you are familiar with, and, appear to have entirely under control to one that you don't know and that will require 'considerable' effort to learn well. You are taking all of the appropriate security measures and I simply don't see any immediate benefit to you.

Many in this forum may not like this answer, but it's the current reality.

SoulNothing · April 30, 2004

jim43 i agree with you

i use linux for office work and modding but i go back to xp to play games

so before you install or anything first try a live cd like knoppix

also linux is more challenging to use than xp jim43 is right linux is for two type of users either advanced or the ones with free times

im still in high school and i help run the network at my shcool and i notice this with xp there are two sides too it

A. easy to set up easy to run

B low security, ie the viruses mentioned

sure xp is plagued by the virus scene but if you get the right apps then you should be fine

dont install linux before you get a picture of what its like i mean i really enjoy it

and while some distros can be really advanced some like mandrake are meant to help window users get adapted to linux

you have alot of things to think about though its a tough choice but i hate to admit it stay with xp it isnt as stable but none the less its familiar ground and you dont want something your not familiar with to take over now do you id recommend checking out some linux help sites see how easy/complicated u think it is and then base your decision on it

linux is a whole new world but it isnt mainstream like xp yet, faster development and good software

another thing is any software you learn there is a linux

here are some more sites to check out ttp://www.linuxquestions.org/questions/answers.php?action=viewcat&catid=1

http://www.justlinux.com/

and again before you install boot a live one

gewitty · May 1, 2004

Thanks Dan. I downloaded and installed Smoothwall and am so far very impressed. It has many powerful features; the installation was fairly straightforward and the user interface and documentation are excellent. Had a bit of a problem up[censored] the firmware in my ADSL modem, but got that sorted eventually.

iamroot · May 1, 2004

I agree with the going back to XP to play games part. Although i managed to use wine and winex to play games. Its just not worth the trouble and u shld just use a windows OS to do so.

Dapper Dan · May 1, 2004

I understand y'all's points about Windows XP, and it's all about choices and what works for you. For me though there is the freedom issue. I have 9 computers to maintain, and only one of them has a Windows partition. That's so my nephews can play games on my mom's computer, and it's Windows 98. Otherwise, all the others are free of Microsoft, consequently I feel free! Before, with Windows, I felt like a slave in comparison.

jimf43 · May 1, 2004

And, in your case Dan, You are entirely justified. Also, you're more than competent in setting up and running your network. I Know you spent considerable effort and time in arriving at that solution. I only want people to be aware of that 'necessary' commitment, especially if a business' sucess may depend on it.

iamroot · May 2, 2004

I think that if one has to use Windows it would have to be either win 98SE or Win 2k. Win XP really sucks man.

optimus · August 10, 2004

Obviouly Linux is the best option, but there are many other things to consider...are you using a your windows box for internet sharing or are you using a router...Perhaps it is much easier to set up a router and dual boot your sytem with linux so when you are online you can always use Linux and when you play games use windows....Windows 2000 is better if you opt for windows....root is right XP really sucks.

you can also achieve your internet connection sharing by setting up a Proxy server using Linux. something I learned from a very good book: Agustin's Linux Manual -Second Edition which is available at http://www.netcontrol.org

if you opt to use a router, you can secure your stations by using IPtables. if you need information about IP tables there are many books online that can give you ideas of how to configure it...however I recommend you Agustin's Linux Manual -Second Edition if you are running or plan to run Mandrake 10.

There is a series (first edition for Mdk 9.0 9.1) of this book for free download check it out at google.

the lates edition tells you about IPtables and Proxy server

good luck

prakash0106 · February 4, 2010

ip chain

# Red Hat 7.1 Linux firewall using ipchains

# May, 2001

# configured by Dennis G. Allard and Don Cohen, http://oceanpark.com

#

# Permission to copy is granted provided that credit is given

# to the author and whatever HOWTOs are used to understand this

# stuff.

#

# No warrenty is implied. Use at your own risk!!

# This web page documents my old ipchains firewall. I have

# updated my firewall to use iptable and udpated the description

# of my firewall at http://oceanpark.com/notes/firewall_example.html.

# This file is /etc/sysconfig/ipchains, intended for

# consumption by the script /etc/rc.d/init.d/ipchains,

# which makes use of the script /sbin/ipchains-restore.

# In Red Hat 7.1, the man page for ipchains and for

# ipchains-restore does not document the syntax of this

# file. I had to read the script to understand better

# what is going on.

# The firewall that the Red Hat 7.1 installer set up for me

# in response to my request for a high level of security

# was too restrictive. And, I couldn't find any GUI tool

# in either GNOME or KDE to reconfigure the firewall.

# For example, the KDE menu item for editing my firewall

# showed an empty set of rules even though this file and

# the above startup script existed. So I had no confidence

# in the GUI firewall tools, resulting in my decision to edit

# this file manually.

# The network

# -----------

#

# This firewall was running on a gateway machine having two

# ethernet interfaces, an external one, eth0, which is

# my DSL connection to my ISP, and an internal one, eth1

# which is assigned to 198.211.65.1, an IP number on my

# class C network. I run a web server, DNS server, and

# sendmail on the firewall machine itself.

#

# Using this file in a more complex network would require

# some modifications. Particular attention would need to

# be given to using the right the IP numbers and interfaces,

# among other things. :-)

# Running this script

# -------------------

#

# Red Hat 7.1 runs /etc/rc.d/init.d/ipchains at system

# startup, which uses this file as input. You can

# turn ipchains on and off via chkconfig. See:

#

# chkconfig --list | grep ipchains

#

# You can restart the ipchains firewall via:

#

# /etc/rc.d/init.d/ipchains restart

#

# A good way to show your ipchains rules is with:

#

# ipchains -vnL

# Preliminaries

# -------------

#

# To permit machines internal to the network to be able to

# send IP packets to the outside world, enable IP Forwarding:

#

# echo 1 > /proc/sys/net/ipv4/ip_forward

#

# Prevent SYN floods from consuming memory resources:

#

# echo 1 > /proc/sys/net/ipv4/tcp_syncookies

#

# I place the above echo commands into /etc/rc.d/rc.local

# so that they will be executed at boot time.

# The basic idea of this firewall

# -------------------------------

#

# Provide rules that are applied in the following order:

#

# ACCEPT all UDP packets for certain UDP services

#

# DENY all other UDP packets.

#

# ACCEPT SYN packets just for certain TCP services

# SYN packets are specified via the -y flag in the input

# rules defined below. Note that certain services can be

# further filtered by xinetd.

#

# DENY all other TCP SYN packets.

#

# ACCEPT all other TCP packets (the default input chain policy.)

#

# In other words, we allow any TCP packet through that is part of an

# established TCP connection, but we are very selective in just which

# connections we permit to be made to start off with. IMPORTANT:

# ipchains is less powerful than iptables since iptables, introduced

# in linux kernel 2.4 provides for Stateful Packet Inspection. ipchains

# will allow packets in that are not part of an existing TCP connection.

# Although such packets will not normally be processed by an application,

# they can be used as part of a denial of service attack. We recommend

# that you use an iptables firewall, which is able to audit connections

# more completely. See:

#

# IPTABLES Firewall Example

#

# A brief explanation of SYN packets goes as follows. TCP connections

# are initiated via a hand shaking protocol between the client and server

# programs at either end of the connection. The very first TCP packet

# is sent by the client to the server and is called a SYN packet,

# because it has the SYN flag set to 1 in the TCP packet header. We

# only allow SYN packets for the specific servers running on specific

# ports of specific hosts. Subsequently, we only permit further TCP

# packets in that are determined to be part of a connection whose

# initial SYN packet was already accepted and responded to by one of our

# servers. By stopping all other packets in their tracks, we limit

# attempts to attack our internal network.

#

# There are subtle ways that Denial of Service attacks can be performed

# if an attacker is able to somehow gain access to a machine inside our

# network or otherwise hijack a connection. However, even in such

# cases, current research is leading to ways to greatly limit the effect

# of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html.

#

# For detailed background reading about iptables, please refer to:

# http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html

#

# oceanpark.com firewall rules (using ipchains)

# ---------------------------------------------

# Tell ipchains-restore what default policies to use...

:input ACCEPT

:forward ACCEPT

:output ACCEPT

# The above will accept anything not prevented by the following rules.

# Deny any packet coming in on the public internet interface eth0

# which has source address of our local network (attempt to spoof an

# address which should never come from any place but eth1) or which

# claims to be from the reserved local loop network 127.0.0.0.

-A input -i eth0 -s 198.211.65.0/24 -j DENY

-A input -i eth0 -s 127.0.0.0/8 -j DENY

# Accept all tcp SYN packets for protocols SMTP, HTTP, and SSH

# Note, SMTP connections are further audited by my SMTP server

-A input -s 0/0 -d 198.211.65.1/32 25 -p tcp -y -j ACCEPT

-A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT

-A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT

# If you query remote DNS servers, permit UDP responses from it

# -A input -s <remote DNS server IP> 53 -d 0/0 -p udp -j ACCEPT

# I had to add the following line to make my DNS server honor requests

# from the public internet.

-A input -s 0/0 -d 0/0 53 -p udp -j ACCEPT

# Open up IMAP server (see /etc/xinetd.conf for who can use it)

-A input -s 0/0 -d 0/0 143 -p tcp -y -j ACCEPT

# Open up FTP server (see /etc/xinetd.conf for who can use it)

-A input -s 0/0 -d 0/0 20 -p tcp -y -j ACCEPT

-A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT

# Allow all inputs from the internal and local interfaces

-A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT

-A input -s 0/0 -d 0/0 -i lo -j ACCEPT

# If we wanted to use masqueading (can do even for legit internal IPs)

# -A forward -s 198.211.65.78 -j MASQ

# Finally, DENY all connection requests to any UDP port not yet provided

# for and all SYN connection requests to any TCP port not yet provided

# for. Using DENY instead of REJECT means that no 'ICMP port

# unreachable' response is sent back to the client attempting to

# connect. I.e., DENY just ignores connection attempts. Hence, use of

# DENY causes UDP connection requests to time out and TCP connection

# requests to hang. Hence, using DENY instead of REJECT may have

# the effect of frustrating attackers due to increasing the amount of

# time taken to probe ports.

# Note that there is a fundamental difference between UDP and TCP

# protocols. With UDP, there is no 'successful connection' response.

# With TCP, there is. So an attacking client will be left in the dark

# about whether or not the denied UDP packets arrived and will hang

# waiting for a response from denied TCP ports. An attacker will not

# be able to immediately tell if UDP connection requests are simply

# taking a long time, if there is a problem with connectivity between

# the attacking client and the server, or if the packets are being

# ignored. This increases the amount of time it takes for an attacker

# to scan all UDP ports. Similarly, TCP connection requests to denied

# ports will hang for a long time. By using REJECT instead of DENY, you

# would prevent access to a port in a more 'polite' manner, but give out

# more information to wannabe attackers, since the attacker can positively

# detect that a port is not accessible in a small amount of time from

# the 'ICMP pot unreachable' response.

-A input -s 0/0 -d 0/0 -p udp -j DENY

-A input -s 0/0 -d 0/0 -p tcp -y -j DENY

# end of firewall rules

prakash0106 · February 4, 2010

ip tables

# Red Hat Linux firewall using iptables

#

# Created: October 2002

# Last Revised: August 2006

#

# Authors: Dennis G. Allard (allard@oceanpark.com) and Don Cohen (don@isis.cs3-inc.com)

#

# This script works on on servers running Red Hat 7.3, 8.0, 9.0, and

# RHEL ES 3 and 4. Variants of this script are in active use on

# many servers.

#

# No warranty is implied. Use at your own risk!!

# Using this script

# -----------------

#

# I save this file as /etc/sysconfig/iptables-precursor

# and then source it and run iptables-save to create

# /etc/sysconfig/iptables, which is an input file

# consumed by the script /etc/rc.d/init.d/iptables,

# which in turn makes use of the script /sbin/iptables-restore.

#

# Before mucking with setting up iptables, you should

# disconnect the machine from the internet. Examine

# and understand the current set of iptables rules

# before you reconnect to the internet.

#

# To configure the set of iptables rules:

#

# /etc/rc.d/init.d/iptables stop

# source /etc/sysconfig/iptables-precursor

#

# To save the current set of iptables rules for use at next reboot:

#

# iptables-save > /etc/sysconfig/iptables

#

# To dynamically restart iptables after modifying /etc/sysconfig/iptables:

#

# /etc/rc.d/init.d/iptables restart

#

# Note that /etc/rc.d/init.d/iptables is a script. You can read it to

# gain understanding of how iptables uses iptables-restore to restore

# iptables firewall rules at reboot.

#

# To examine the current set of rules in effect:

#

# /etc/rc.d/init.d/iptables status

#

# However, I prefer to show the current set of rules via:

#

# iptables -nvL -t filter

# iptables -nvL -t nat

#

# or

#

# iptables -vL -t filter

# iptables -vL -t nat

#

# To configure iptables to be used at next system reboot:

#

# chkconfig --add iptables

#

# To see if iptables is currently configured to start at boot, do:

#

# chkconfig --list iptables

#

# (You might have to do chkconfig --del ipchains to remove ipchains)

#

# The rest of this file is derived from my old ipchains script.

#

# A word about routing

# --------------------

#

# Note that this web page does not discuss routing decisions. Routing

# (see the 'ifconfig' and 'route' commands) decides which interface an

# incoming packet will be delivered to, i.e. if a given packet will be

# 'input' to this machine or be 'forwarded' to some interface for

# delivery to another machine, say on an internal network. You should

# have your routing configured before you attempt to configure your

# firewall.

#

# Caveat. DNAT and SNAT provide a way for the IPTABLES firewall to modify the

# Destination or Source IP addresses of a packet and, in this way, interact

# with routing decisions. See section below: 'More about NAT and routing'.

#

# The network

# -----------

#

# This firewall is running on a gateway machine having multiple ethernet

# interfaces, a public one, eth0, which is a DSL connection to an ISP,

# and one or more internal ones, including eth1, which is assigned to

# 192.168.0.1, an IP number on my internal private network. My public

# network has static IP numbers depicted below as x.y.z.... Actual

# IP numbers would, of course, be a sequence of four octets. For this

# script, I assume that the firewall is running on the same machine

# having the interfaces configued with my public IPs. For this reason,

# most of the rules below are INPUT rules. Were I to route some of my public

# static IP numbers to interfaces on one or more machines inside the

# firewall on the internal network, I would modify certain rules to be

# FORWARD rules instead of INPUT rules. I show some examples below of

# FORWARD rules. Finally, the script is just for a single server IP,

# hence all of the "/32" network masks below. A more realistic situation

# would involve using IP ranges and their corresponding network masks.

#

# The gateway at my ISP is x.y.z.1. I run a few web servers on

# x.y.z.w, a DNS server on x.y.z.n, and qmail on x.y.z.m.

#

# Using this file in a more complex network would require some

# modifications. Particular attention would need to be given to using

# the right the IP numbers and interfaces, among other things. :-)

#