INTRODUCTION

In this tutorial, I'm going to discuss how to setup almost everything someone needs for a home network server including:

1) a caching web proxy for the family combined with squidguard to block access to objectionable sites for the kids -- setting up squid and squidguard

2) a windows-compatible file server or "share drive" that a windows machine can access via the network including sharing printers -- setting up samba

3) protecting your networked computer a little with fail2ban

4) allowing remote access with ssh

5) a PS3-compatible media server -- setting up mediatomb

6) a DNS server that can even more limit access to the internet

7) modifying ufw, the mint firewall to make sure this all works.

If anything hasn't been covered as you read this, it's because this is a work-in-progress, but I expect to 'finish' it within a month.  Comments are welcome, and I'll incorporate them should they work on my machine when tested.

I'm actually likely going to install two Virtual Machine servers like this:

1) mediatomb and SAMBA and ssh (ssh with access only allowed via internal network)

2) ssh, fail2ban, proxy server, and DNS server.

I am including instructions as if only 1 server is being setup.  I'm sure you can pick and choose what you want on your server on your own.  It should be noted that if you use DD-WRT you can setup a DNS server on that.  I have no intention of making this a tutorial on DD-WRT.

Caveats

Throughout this tutorial, I'm not going to promise the most secure way of setting things up, nor the most efficient way, just the way I got it working and document some pitfalls along the way.

I'm going to assume linux mint 12 being installed as a virtual machine using VMWare for this, but, generally, everything should work for a 'bare metal' install as well.

NOTE: The squid section has been updated for Linux Mint 17 and Squid 3.

I assume you know how to sudo to get root access, and at some points, I'll be saying type

~$ sudo bash

to minimize the number of sudo's typed before each command.  This may not be the best way to do things, but it works for me and seems to be more "accepted" than just using 'su.'

I also assume you know how to edit a file using your favorite editor.

Most changes are small so using:

~$ sudo vi /etc/somefile.txt

will do.
 

You also probabaly want to set up a static IP address since you don't want this machine's ip address moving around by choosing "Applications:Other:Network Connections."  Choose the "Wired" tab and select the first entry.  Then choose "edit..." 

Go to the IPv4 Settings tab and do the following: Pull down the dropdown and select "Manual" for the method.  Then type in three addresses across, the first being the static IP address you'd like to assign to the machine, like 192.168.1.3.  The second is the Netmask. Generally acceptable for this is 255.255.255.0;  and finally, the gateway, which is usually your router address.  This is something like 192.168.1.1.

DNS servers are a little more difficult.  Eventually, I'll be setting up our machine as a DNS server, so we could start with 192.168.1.3, and then put in whatever DNS servers your ISP provides or use openDNS: 208.67.220.220 (assuming you have an account), or you could use google's if you like being spied on: 8.8.8.8.  And that is it.  Click "Save.." and you're good to go.

Getting Started

FIREWALL

First, let's get started with ufw, the mint 12 firewall.  The reason why I chose this first is because we'll be coming back to it a lot to open up some ports to get things working.

Let's start by clicking "Applications:Accessories:Terminal."

After typing

~$ sudo ufw status

the likely response will be:

Status: inactive

We want to turn on the firewall, so

~$ sudo ufw enable

In theory, it's enabled and will start in the future.

Let's open port 22 to accept connections from ssh:

~$ sudo ufw allow 22

Rule added

~$ sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
22                         ALLOW       Anywhere (v6)

Now that ufw is taken care of and we're ready to accept connections for "remote access" lets go ahead and set up ssh.

---

 

Remote Access Via SSH

SSH for some reason is not installed by default, so we must install it:

~$ sudo apt-get install ssh

Well, this puts the default SSH stuff in place, but in your home directory, you have no real 'abilities' yet.  Someone can just log into your account from an external computer by typing (assuming they do a brute force password attack and know your username):

~$ ssh yourusername@youripaddress

Scary? Give it a try:

~$ ssh localhost

type "yes," and then enter your password.  You're remotely logged into your own machine.  You didn't need your username that time because your machine knew who you were (that is, the username was common between the "host" and "server."). Type:

~$ exit

to logout.  This is LARGELY considered unsafe, so one can do a bunch of things to make this more secure, so let's start.

 The first thing we need to do is create a directory called .ssh.  The 'dot' at the beginning makes it a 'hidden' directory (BTW '~' is the secret linux shorthand for /home/yourusername and is a fast way to get to your home directory):

~$ cd ~

~$ mkdir .ssh

The main files that will be in here are your private key and your public key (both generatable by ssh-keygen): id_dsa or id_rsa and id_dsa.pub or id_rsa.pub respectively.  Eventually, we'll create a file that stores PUBLIC keys of people authorized to access this machine.  The name of that file will be "authorized_keys2" surprisingly enough.

Why do these matter?  If you want to access this machine from another machine, we're going to make it so you MUST have a private key on the remote machine and its corresponding public key on this machine to access this machine.

So, you'll go to your other linux machine [or using putty in windows] and will generate a private/public key pair.  If that other machine has linux, you'll type:

~$ ssh-keygen

Then you'll see those two files in that machine's .ssh directory. You'll copy the id_rsa.pub to a thumb drive (or use some other method) and give it to yourself to place that on the machine we're working on.  At which point, you're going to put it in a file called "authorized_keys2" in this machine's .ssh directory:

You can do something like this from that other linux machine:

~$ scp ~/.ssh/id_rsa.pub yourusername@yourIPAddress:./.ssh

if you don't want to use a thumb drive to copy the public key over.

Then on the machine we're working on, you can:

~$ cd ~/.ssh

~/.ssh$ cp id_rsa.pub authorized_keys2

or you can

~/.ssh$ cat id_rsa.pub >> authorized_keys2

The first example will wipe out all other keys that someone might have put in place to access your machine and the last one will append the public key from the other machine to your current machines authorized keys.
In general, you want that authorized_keys2 file to only be readable, and not writeable except by you so, make sure the permissions show as:

-rw-r--r--

(chmod 644) when you do an

~/.ssh$ ls -la

 Now, we want to make sure of a few things:

1) the ONLY way to get in using ssh is if you have a key -- sorry, no more username and password login

2) no root access

3) optional -- if you want to graphically see the desktop when you login with ssh from a linux machine (or X-server) you can do that

To do all this, we need to modify the file in /etc/ssh called sshd_config.  Make sure you see the "d" after the ssh.  It stands for daemon, which is the thing that will be receiving ssh incoming connections.

You can use your favorite editor on this file and change the following:

PermitRootLogin no

PasswordAuthentication no

That should do it, but you can make sure X11Forwarding is yes, but that should be the default.

It's also recommended you do some other things:

1) Limit parallel brute force attacks by modifying:

MaxStartups 2:50:10

It should be noted that this limits the number of simultaneous logins, but, let's face it, if this is your home network, you're likely the only one to be even thinking about logging in with ssh-- am I right? ... so that limit shouldn't matter.

2) Don't self-identify.  This means, keeping the hacker guessing which version of ssh you have running.  Maybe there's a vulnerability he/she knows about with respect to your particular version, so why help him out?

Add the following:

DebianBanner no

This will be a little less revealing to someone doing an nmap probe:
~$ sudo nmap -A -T4 -p 22 192.168.1.3

Also, you can modify /etc/motd, to remove detailed info (should they make it in):

~$ sudo cp /etc/update-motd.d/00-header ~/00-header.backup

~$ sudo chown yourusername.yourusername ~/00-header.backup

~$ sudo vi /etc/update-motd.d/00-header

Comment out most of the automatic stuff and put something after the printf that is not so noxious like:

"Welcome to 192.168.1.3."

Do the same thing for:

~$ sudo vi /etc/update-motd.d/10-help-text

Also you can change the banner to add a disclaimer making the hacker think he's being watched:

banner /etc/ssh/banner.txt

to point to something else like this web site points out:

http://www.review-ninja.com/2009/05/login-banner-ssh-banner-howto.html

Note: toward the top of this file is the listen port for the daemon.  Some say it's safer to change this port to something uncommon (and correspondingly changing the ufw port above).  You can do that if you want.  Personally, I think anyone good at using nmap will find your open ssh port anyways.

OK, now for the big test.  Restart your ssh daemon:

~$ sudo service ssh restart

You should be able to connect from that other linux machine using the

~$ ssh -Y yourusername@yourhostip

The "-Y" allows for X11 forwarding.  This means that if you run gedit or something graphical/windowed program, it'll start up in a nice graphical window as if you're there.  You can use "-X" as well from what I understand, but "-Y" seems to work for me.  The man page for ssh makes a distinction between trusted and not trusted forwarding.  I really haven't bothered researching the difference between the two, and if someone wants to point out the nuances and why one should use one over the other, then please do.

If theory, you should be reasonably safer now, but let's make yourself a little more safe by installing fail2ban.

Making Remote Access a Tiny Bit Safer

Install fail2ban:

~$ sudo apt-get install fail2ban

 The only thing to do here is to modify:

/etc/fail2ban/jail.conf

I removed the /8 from the end of the "ignoreip = 127.0.0.1" entry because I didn't know what the point of that was.

Notice that "ssh" is enabled by default, so you're good to go!
I seem to be a magnet of people scanning or something, so I periodically check my fail2ban status just for the fun of it.  You do that by typing:

~$ sudo fail2ban-client status

Diversion

Now for a quick diversion.  Assuming you may want to compile something some time or that you're installing this on vmware and you eventually want to benefits of vmware tools, you will need to install some development stuff.  I don't know why it isn't included in the default config:

~$ sudo apt-get install fakeroot build-essential
~$ sudo apt-get install linux-kernel-headers
 

Another note on vmware: You likely should install using 'bridged networking' mode so you don't have to go through your host-computer's NAT translation.  This could cause problems and kind of defeats the purpose of using a static IP address on your server.

---

Sharing Files with Windows/Apple

So, let's install samba:

~$ sudo apt-get install samba

Then we have to do the hard work of setting up what we want to share.  Of course, we first need to decide what to share.

Personally, I have a 1 TB HD that I mounted to "/mnt/bigdrive."   You can easily mount your favorite big drive using the command:

~$ sudo mount [some /dev/] [some mount directory]

and set up fstab to make sure it mounts each time you boot.  If using vmware, you can supposedly use the disk mount utility to mount a virtual disk as well:

http://www.vmware.com/support/developer/vddk/vddk12_diskmount.pdf. 

I will be giving this a try shortly, but haven't tried it yet.  I will post here with nuances of that as I make mistakes and do work-arounds.

The long and the short of it is that you need to have created an empty directory in your "bigdrive" directory:

~$ sudo mkdir /mnt/bigdrive/multimedia

Then you have to mount the "large disk" to that directory (assuming the large disk is /dev/sdb1):

~$ sudo mount /dev/sdb1 /mnt/bigdrive/multimedia

Once that is confirmed to work, you can add an entry into your /etc/fstab:

UUID=somelongUUID /mnt/bigdrive/multimedia   ext4    defaults,errors=remount-ro,relatime 0   1
 

to make the 'mount' stick after a reboot.

It seems to be the 'recommended' procedure to use the UUID instead of the '/dev/sdzy' drive name.  I think this is because the /dev/ drive name can sometimes be changed or may be inconsistently applied should some other drive be added during power off or during hot-swapping.  Either way, it's pretty easy to find the UUID of your drive by typing:

~$ ls -l /dev/disk/by-uuid

or

~$ blkid

Do any search on fstab to figure out what those other settings are, but they seem to work for me.

Another option is for another linux or windows machine to be sharing this multimedia directory, which you can mount on your machine using cifs (which also isn't installed for some reason. There used to be a smbfs, but I guess that's deprecated.):

~$ sudo apt-get install cifs-utils

First, you should check you can "see" that share drive by trying:

~$ smbclient -L ipAddressOfMachineWithShare

Assuming it showed you what you were expecting, you can mount it:

~$ sudo mount.cifs -o username=yourusername,password=yourpassword //hostNameOrIpAddress/multimedia /mnt/bigdrive/multimedia/

Now that I have a 'local' location that I want to share with my network, we can configure samba to share it.  Note: I'll also be using that directory to share videos with my PS3 using UPnP mediaserving with mediatomb shortly.

Next, we'll be using a program called samba, which easily allows sharing of the user's "home" directory.  I want to allow everyone access to "multimedia," so I'm going to have to make sure we have a group assignment and everyone is part of that group.

One easy way to do this is to add your users to a group called "users" which already exists in your /etc/group file.

You can edit this file changing the line:

users:x:100:

to

users:x:100:yourname,yourkidsname,whatever

This usually doesn't "take," and requires a reboot if you use the 'normal' editor.  If you're familiar with vi you can use:

~$ sudo vigr -s

and it should lock the file and make your changes active.  An alternative is that I use the:

 ~$ sudo adduser yourname users

command for each user I want to add to the group 'users.'  I like that group for most of my "group assignments."  Other people like other groups.  To be honest, eventually we'll be adding the same people to group "mediatomb," so it doesn't matter right now.  Just get the point of group ownership.

You then need to make sure "multimedia" has a group assigned to its permissions:

~$ sudo chown -R yourusername.users /mnt/bigdrive/multimedia

You probably also want the group sticky bit set on this directory so all stuff in that directory (that someone may add later on) keeps the group "users:"

~$ chmod g+s /mnt/bigdrive/multimedia

You might want to make sure your group also has rwx permissions on that directory.  Remember the ls -la command?  It's your friend.

 We're now ready to modify the Samba /etc/samba/smb.conf file to make it share printers and our 'multimedia' directory.  But first we have to create some samba users.  I think Mint is set up to do sync'ing with samba via PAM once things are in place, but it must be set up first:

~$ sudo smbpasswd -a yourusername

repeat this for all users on your linux machine that you just added to the 'users' group above.

Like 'ls -la' ??
Well, you can redefine how 'ls' works so you don't have to type that every time.  You modify the file .bashrc in your '~' directory with the following:
# enable color support of ls and also add handy aliases if [ -x /usr/bin/dircolors ]; then     eval "`dircolors -b`"     alias ls='ls --color=auto -la --block-size=M'     #alias dir='dir --color=auto'     #alias vdir='vdir --color=auto'     #alias grep='grep --color=auto'     #alias fgrep='fgrep --color=auto'     #alias egrep='egrep --color=auto' fi

SMB.CONF Edits

Let's now edit /etc/samba/smb.conf.  I reviewed the "default" smb.conf to compare with mine to see the changes, so I'll only cover the additions/changes below:

The main things to change are below.  In most cases, you can just remove the semicolon in front of a line to make it active.  So let's begin:

workgroup = something

WIndows usuallly assumes some idiotic name for the workgroup on your network.  It's probably smart to make sure every windows computer is set to the same workgroup.  At the very least, when you're browsing your network, all your computers will neatly appear under a single name.  Additionally, change the setting above to that workgroup name in linux to make it appear nicely as well.

In Win7, if you can go to "Control Panel:System," then under 'Computer name, domain, and workgroup,' you can change the workgroup.

The following makes your samba shares a little more secure:

security=user
wins support = yes

You can also enable name resolve order.  You can create a list of host id's and ip addresses in your local /etc/hosts file and this will interpret for you.  An entry in that file goes something like this:

192.168.1.3 myservername
192.168.1.5 someothercompname

But I digress...

I also have

 local master = yes

in my smb.conf file.  I think I added this because I was getting an annoying repeating error in my smb.log file and I wanted it to stop.  I read somewhere that that entry would stop it.

Enable printer sharing through cups:

load printer = yes

printing = cups
printcap name = cups

 Now, let's share our home directories for valid users:

 [homes]
   comment = Home Directories
   browseable = no
   read only = no
   valid users = %S

NOTE: For the valid users entry, I make sure my username in windows and password in windows matches those in linux (both passwd and smbpasswd settings).  This seems to work well.  Alternatively, both OS/X and windows allow you to log into a share drive with an alternate username and password.  You can choose that option and use your samba username and password.

More printing:

[printers]
   comment = All Printers
   browseable = yes
   path = /var/spool/samba
   printable = yes
   guest ok = yes
   read only = yes
   create mask = 0700
   use client driver = yes
   public = yes
 

I think this might make my printers unsafe, but I really am not sure of the implications.  In other words, should I be thinking "so what if someone can print something on my printer, how are they going to pick it up?"

Finally, let's actually share the multimedia drive.  I'm also throwing in a "share" for pictures with some "odd settings" just to show how some options could be used.  The word in the brackets will be what the network sees as the share name.  A hidden share has a dollar, '$'.

[pictures]
   comment = /home/pictures
   path = /home/pictures/
   case sensitive = no
   guest ok = yes
   follow symlinks = no
   read only = no
   force user = www-data

[multimedia]
   comment = mostly multimedia
   path = /mnt/bigdrive/multimedia
   guest ok = yes
   read only = no
   case sensitive = no

Once you're done, you can run

~$ sudo testparm

to see if there are any errors, and then restart samba:

~$ sudo service smbd restart

You're not done yet!  You now need to open up some ports in your firewall.  In theory, there's a file in your /etc/ufw/applications.d directory named "samba."   This has the list of ports that ufw should open to make samba work.

If you type:

~$ sudo ufw allow samba

that will open up the necessary ports.

Give it a test by typing:

~$ smbclient -L 192.168.1.3

and you should see a list of your shares.  The ports that get opened are: ports=137,138/udp|139,445/tcp.

---

You can now go to your apple or windows machine and try to connect:

Windows

Type

\\192.168.1.3

into the windows explorer.

OS/X or Apple

In 'finder" choose the menu item "Go:Connect to a server":

In the window type smb://192.168.1.3/multimedia

or whatever share you want to connect to.

---

 

PROXY SERVER - SAVING BANDWIDTH and YOUR CHILDREN'S MORAL(s)

 We're now going to use a caching proxy server called squid to cache incoming web data on a local hard disk.  Additionally, when combined with squidguard, it can block certain web sites (like ones containing malware, porn, phishing, etc.) and even replace content.  A few words of caution are necessary here.  You could think your cache is working and it's not.  One of the main problems I initially had was that the cache was running out of disk space.  It would then go into failsafe mode and cache nor block anything.  Additionally, the squidguard setup is also unforgiving and it takes log searching to know you have a problem.  You are warned:

1) Make sure you have a LOT of free disk space for your cache and

2) Make sure you test out squidguard and make sure it's running in the logfile before you walk away thinking everything is fine.

So, let's get to it.  We're going to install them both, modify their config files, set up permissions on their directories, and, of course, open up a port in the firewall (3128).

~$  sudo apt-get install squid squidguard squidclient squidguard-doc

To help with this "disk space" problem, the first thing we're going to do is set up a cron job.  Cron is a daemon that periodically runs a program of your choosing.  Items are stored in the 'crontab' which run at a specified time.  We're going to run a program as recommended by the wiki:

http://wiki.squid-cache.org/SquidFaq/SquidLogs

type:

~$ sudo crontab -e

It will ask which editor you want to use.  I chose nano, although vim is just as easy.  Then paste this in there:

0 0 * * * /usr/local/squid/bin/squid -k rotate

LM 17 and Squid 3:

0 0 * * * /usr/sbin/squid3 -k rotate

That will rotate the squid log files every day at midnight. NOTE: it looks like mint 12 might have solved this with some kind of rotation directory.  I suppose having the crontab won't hurt even if it does.

If you chose nano use:

CTRL-O             and

CTRL-X will exit.

That should help.
 We will now modify /etc/squid/squid.conf.  Here I'm going to use a "sudo bash" because we're going to be doing a lot of stuff with super user power.

~$ sudo bash

~# cd /etc/squid

LM 17 and Squid 3:

~# cd /etc/squid3

/etc/squid[3]# cp squid.conf squid.bak

/etc/squid[3]# service squid[3] stop

 Edit squid.conf now using your favorite editor.

The first thing you'll come across are a bunch of acl lines with uncommented networks:

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

Humerously, not a single line of these is likely the '192.168.1.0/24' network everyone knows and loves!

So...  Comment the first two out and change the last one to:

acl localnet src 192.168.1.0/24  # RFC1918 possible internal network

The key place to start adding things is in the acl section.

I added one extra port because the skedi website wasn't working without it:

acl SSL_ports port 8443         # https for skedi

Also, right after the 'acl purge method PURGE' and 'acl CONNECT method CONNECT' lines I added:

acl hotmail dstdomain .live.com
always_direct allow hotmail

This, in theory, will not cache my hotmail account. You could do something similar for gmail or juno or whatever web sites that you don't want to hold a local cache for. I think mail is probably a good idea since you'd want to know when you get incoming mail.

You'll then see a section that looks like this:

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

uncomment the line "http_access allow localnet" to allow access from the local net you defined earlier.

So change this line:

# http_access allow localnet

Way down in the file, you'll notice a line saying:

http_port 3128

You can change this to anything you want.  This is the port to which you'll be pointing your kid's browser, so remember it.

Further on, you'll find a setting called cache_mem.  The line is commented out in the default file and set to 8MB.  I uncommented it and changed it to:

cache_mem 64 MB

LM 17 and Squid 3:

The default cache_mem is MUCH larger in squid3, so you can just leave the default.

 

A little further you'll change:

maximum_object_size_in_memory 64 KB

LM 17 and Squid 3:

The default maximum_object_size_in_memory is MUCH larger in squid3, so you can just leave the default.

 

The MAJOR change to make is for the "cache_dir" parameter.  I did not like if using /var/spool/squid for a number of reasons.  The first was that the root '/' happened to be on a smaller, slower disk drive.  The second was that the sizes were too small.  Assuming you WANT to keep it where it's default location is (if your drive is big enough), I used these parameters.

cache_dir ufs /var/spool/squid 4000 16 256

This means your disk cache will go from the default 100 MB to 4 GB.  With today's large disk sizes, I don't see a reason why you wouldn't go pretty large on this.  Don't overdo it though... I will say again, disk filling up syndrome (DFUS) is the biggest error I've gotten on squid and it's hard to tell when it happens!

maximum_object_size 32768 KB

In my quest to get rid of disk space hogging and possible failures:

cache_store_log none

Now, for the all-important squidGuard program, which actually will filter urls that your kids try to visit:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf.

LM 17 and Squid 3:

There is NOW an /etc/squidguard directory with a squidGuard.conf in there.  You can therefore just use:

url_rewrite_program /usr/bin/squidGuard

All modifications below would be to that file instead.

---

SquidGuard

Now we need to configure squidguard.  You'll notice that Mint nicely has a squidGuard.conf file in this folder as well and it has some default directories specified at the top.  The first is the location of the database of all the URLs and IP addresses you want to block.  Guess what?  There's NOTHING in the /var/lib/squidguard/db directory! 

What can you do about that?  The url http://squidguard.org/blacklists.html gives you a list of blacklists.

Then copy any one of those to the right location and unzip (tar xvf file usually works well).  I don't know which blacklist service is the best so if you know or have seen any evals, please post a comment.

Then modify your squidGuard.conf to allow or disallow sites.  In mine I have some "admin" machines that I want to allow access to everything.  I probably should deny malware and those kinds of sites, but oh well....  That being said, make sure you're careful how you modify this file because there's little feedback when you make a mistake and must get into the log file to find out what you did wrong.

Modify your squidGuard.conf.  NOTE: Don't just use the domain and url lists from my file assuming your database will have them!  Check the database subdirectories once you've unpacked the compressed file and make sure they exist.  Some may have one or the other or both.  Any error will cause squidGuard not to compile.

example squidGuard.conf with database above

# # CONFIG FILE FOR SQUIDGUARD # dbhome /var/lib/squidguard/db logdir /var/log/squid  # for LM 17 and Versionn 3 change this to /var/log/squidguard  <---- # # TIME RULES: # abbrev for weekdays: # s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat time workhours {         weekly mtwhf 08:00 - 16:30         date *-*-01  08:00 - 16:30 } # # REWRITE RULES: # #rew dmz { #       s@://admin/@://admin.foo.bar.de/@i #       s@://foo.bar.de/@://www.foo.bar.de/@i #} # # SOURCE ADDRESSES: # src admin {         ip              192.168.1.88-192.168.1.90 192.168.1.46 192.168.1.67 192.168.1.68 #       user            root foo bar #       within          workhours } #src foo-clients { #       ip              172.16.2.32-172.16.2.100 172.16.2.100 172.16.2.200 #} #src bar-clients { #       ip              172.16.4.0/26 #} # # DESTINATION CLASSES: # dest good {         domainlist      whitelist/domains         urllist         whitelist/urls } dest local { } dest ads {         domainlist      ads/domains         urllist         ads/urls } dest adult {         domainlist      adult/domains         urllist         adult/urls #       expressionlist  adult/expressions #       redirect        http://admin.foo.bar.de/cgi-bin/squidGuard.cgi?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u } dest manga {         domainlist      manga/domains         urllist         manga/urls } dest malware {         domainlist      malware/domains         urllist         malware/urls } dest porn {         domainlist      porn/domains         urllist         porn/urls } dest aggressive {         domainlist aggressive/domains         urllist aggressive/urls } dest drugs {         domainlist drugs/domains         urllist drugs/urls } dest gambling {         domainlist gambling/domains         urllist gambling/urls } dest spyware {         domainlist spyware/domains } dest violence {         domainlist violence/domains         urllist violence/urls } acl {         admin {                 pass     all         } #       foo-clients within workhours { #               pass     good !in-addr !adult any #       } else { #               pass any #       } #       bar-clients { #               pass    local none #       }         default {                 pass     !ads !porn !aggressive !drugs !gambling !spyware !violence all #               rewrite  dmz                  redirect http://www.google.com         } }

 

Run squidGuard to compile them.  Note: It's going to only compile those areas in your squidGuard.conf file, not ALL of the db entries.  So you need to make sure your config file is right before you do this:

~# cd /var/lib/squidguard/db

/var/lib/squidguard/db# squidGuard -C all -b

The key thing here is the use of the "-b" switch so you know when it fails to compile! This command will likely never return to a command prompt, but likely it worked when you check in the /var/log/squid/squidguard.log file and it says you're succesful.  Unfortunately, I have not figured out a way to shut that baby down, so do a reboot. (seriously)

Make sure you chown to the group 'proxy' when you're done on almost everything, including the 'db' directory items:

/var/lib/squidguard# chown proxy.proxy -R db

(NOTE: You shouldn't have to do the above because the group sticky bit should be set on that directory, but I wanted to add this step in case you used your own db directory.  Make sure you set chmod g+s on any directory you used!)  and...

/etc/squid# chown root.proxy squidGuard.*

Crontab script to update squidGuard database using Shalla.  I set it up to run once a week.

#!/bin/sh #i NCF Feb 23, 2009 - Process the Shallalist.de squidGuard updates. # by evilghost # modified for my machine with reload #Check the directory if [ ! -e /var/lib/squidguard/tmp ]; then     mkdir /var/lib/squidguard/tmp fi cd /var/lib/squidguard/tmp #Do we download?  Check the md5sum NEW=0 if [ -e /var/lib/squidguard/tmp/shallalist.tar.gz ]; then     /usr/bin/curl -o /var/lib/squidguard/tmp/shallalist.tar.gz.md5 http://www.shallalist.de/Downloads/shallalist.tar.gz.md5     #Check the status     /usr/bin/md5sum --status -c *.md5     #Do we download a new version?     if [ $? -ne 0 ]; then         echo "Found a new version from the md5"         /usr/bin/unlink shallalist.tar.gz         /usr/bin/wget http://www.shallalist.de/Downloads/shallalist.tar.gz         NEW=1     fi else     /usr/bin/curl -o /var/lib/squidguard/tmp/shallalist.tar.gz.md5 http://www.shallalist.de/Downloads/shallalist.tar.gz.md5     /usr/bin/wget http://www.shallalist.de/Downloads/shallalist.tar.gz     NEW=1 fi #Did we download a new tar-gzip? if [ $NEW -eq 1 ]; then     #Check the status         /usr/bin/md5sum --status -c *.md5         #MD5 match?  The commit.         if [ $? -eq 0 ]; then         /bin/tar -zxvf shallalist.tar.gz         /bin/cp -av BL/* ../db         /bin/rm -rf BL         /usr/bin/squidGuard -C all         /bin/chown -R proxy:proxy /var/lib/squidguard/db         /usr/bin/service squid3 restart         #/etc/init.d/squid reload         #/sbin/reload squid3     fi fi

---

You should check the status of squid with:

~# service squid status

If you're up, open up your firewall and check a browser (below).

~# ufw allow squid

This should open up port 80 as well as 3128.  It did in mine.  If it didn't open up port 80, you should open it.

~# ufw status

If it says you're down, check your logs to find out why.

Also, make sure you have enough disk space with the command

~# df -h

 

This is a good way to see if squidGuard is set up correctly:

echo "http://porn.com / - - GET" | squidGuard -d

 

---

On internet explorer:

Tools:Internet Options:Connections

Then click on the LAN Settings button.

Select the radio button under proxy server, type in your IP Address of your squid machine (in our example case: 192.168.1.3)

and use port 3128.  Browse away.

On firefox:

Edit:Preferences:Advanced

Network Tab, Settings Button

Then set up the IP address and port under manual proxy.

---

 Now, you have a few choices:

1) set up each of your kids' browsers with the settings for a proxy server (BTW, on an Apple you also have to go to network settings to make it work with Safari).  This has obvious implications; mainly that when your kids figure that out, they'll be able to change that setting to bypass your proxy,

2) set up a transparent proxy through your server machine (which will likely require setting your machine up as a router and messing with IPTABLES rules), or

3) installing DD-WRT or OPENWRT [Tomato or some other thing like that] on your home router and set that up for transparent proxying pointing it to your server.

I did number 3 last night with my WNR384B from Netgear.  Flashing it with DD-WRT was 1000 times easier than doing my Linksys WRT300N.

I took the path of the "alternate solution" on this page: http://www.dd-wrt.com/wiki/index.php/Squid_Transparent_Proxy :

The router instructions were simple and easy to follow, but there's one "gotcha:"  I had a problem with my OS/X machine and had to exclude it at the dd-wrt router.  It says, "add the following to bypass the proxy at the router:

iptables -t mangle -A PREROUTING -j ACCEPT -p tcp --dport 80 -s [IPADDRESS] "

Well, you can't "ADD" it to the end.  You need to put it at the beginning of the set of commands.

Mint's version is 2.7 as of this writing so we can use the newer than 2.6 instructions of changing this one line in the /etc/squid/squid.conf file:

http_port 3128 transparent

It's that easy.  Do a

~# service squid restart

and that's setup.

The change to your machine must be:

~# iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

 Incredibly easy.  How do you confirm that it's working?

I did a:

 ~# tail -f /var/log/squid/access.log

and then change my browser to turn off the proxy and browsed somewhere.  Lo' and behold!  The log file increased, so I assume it's working.  You can also try to browse to a known-blocked site and see if it reroutes (to google in my case).

Now we have to make that IPTABLES change always occur on our server in case we ever reboot. (Don't you hate when instructional sites like the one above say: "note, extra steps will be needed on your proxy box to make this change persistent, but they are not covered here."  I understand why because every distro might have a different "approved solution" to setting that up, but still...)  Regardless, lets see what the MINT/ubuntu way is using this:http://manpages.ubuntu.com/manpages/oneiric/en/man8/ufw-framework.8.html

 Get into the /etc/ufw/sysctl.conf file and uncomment the line:

net /ipv4/ip_forward=1

line.  We don't have to do the stuff in that post to open up port 80 since I think ufw has already opened that port when we allowed squid (but you can check that by doing a ufw status -- mine's open anyways). Sooo...

At the very end of the file /etc/ufw/before.rules, just BEFORE the COMMIT, add the following lines:

COMMIT
*nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -i eth0 --dport 80 -j REDIRECT --to-port 3128  
 

Make sure there's another COMMIT at the end, then save and reboot.  Everything should work on bootup now.

Then, let's restart the server and see what happens when browsing!

Now, if you REALLY want to get complicated, I wrote a little script that periodically polls your squid installation and records your hit rates.  You can test your cronjob skills by making it occur hourly (it doesn't help to do it more often, I think, because the stats are only updated that often).  It will create a file in your /var/log/squid called ratelog.log with your caching ability.

Python script

#!/usr/bin/env python import os, shlex, subprocess #cmd=['type',r'C:\temp\pythonreader.txt'] cmd=['squidclient','mgr:info'] p=subprocess.Popen("squidclient mgr:info", shell=True, stdout=subprocess.PIPE).communicate()[0] spllines=p.splitlines() lo=[] for line in spllines:     if "60min" in line:         hi=line.split("60min:")         bd=hi[1]         lo.append(bd[0:-1]) print lo outnums="{0}, {1}, {2}, {3}\r\n".format(*lo) print outnums #make sure the file exist -- which is might not if log files are archived if os.path.isfile("/var/log/squid/ratelog.log"):     logfile= open("/var/log/squid/ratelog.log","r")     data=logfile.readlines()     if "Request" in data[0]:         print("found it")         foundHeader=True     else:         print("didn't find it")         foundHeader=False     logfile.close() else:     foundHeader=False     data=[] #logfile=open("ratelog.log","a") if foundHeader==False:     logfile=open("/var/log/squid/ratelog.log","w")     logfile.write("Request  Byte  Memory  Disk\n")     for line in data:         logfile.write(line) else:     logfile=open("/var/log/squid/ratelog.log","a")  # REMEMBER to change these to squid3 for LM17 <----- logfile.write(outnums) logfile.close()

Crontab Hints for the script above:

Assuming you name the file savesquidlog.py and saved it to your /usr/sbin directory:

~# chown root.root /usr/sbin/savesquidlog.py

~# chmod 755 /usr/sbin/savesquidlog.py

~# crontab -e

0 * * * * /usr/sbin/savesquidlog.py >> /dev/null 2>&1

CTRL-X

---

DNS Server

No one REALLY needs  a DNS server, and I'm now debating having one with all those DNSSec problems out there, but I thought it'd be fun to experiment with BIND9.  I think I'm going to do a new tutorial with Bind9 given the possible issues, so let's move on to Mediatomb

MediaTomb

Mediatomb lets you share your media which is stored on a local drive via universal plug'n play (Upnp).  installing is easy.  Setting up is a little more challenging.  To install, we resort to our tried and true:

~$ sudo apt-get install mediatomb

~$  sudo apt-get install mencoder
~$  sudo apt-get install ffmpeg

If you want to know how the mediatomb with Linux Mint was compiled you can see it with:

~$  sudo mediatomb --compile-info

Well, that's easy.  Now we have to look at what groups and users it set up in Mint:

~$ cat /etc/groups

You'll notice a new group there: 'mediatomb.'

From the documentation:

"You should also make sure that your firewall is not blocking port UDP port 1900 (required for SSDP) and UDP/TCP port of MediaTomb. By default MediaTomb will select a free port starting with 49152, however you can specify a port of your choice in the configuration file."

So... let's open 1900 for both UDP/TCP and 49152 assuming you've never run anything else on that one:

~$ sudo ufw allow 1900

~$ sudo ufw allow 49152

You should find the config.xml in the /etc/mediatomb directory.

This will allow you to use the web interface to set things up:

---    ui enabled="yes" show-tooltips="yes"

in the file.

For PS3 support, carefully search through the file for all mention of PS3.

I also want to play divx's so I uncomented all the "if you want to use PS3 notes" in the file.

Note two things from the file:

    /var/lib/mediatomb
    /usr/share/mediatomb/web

then restart the server:

   

~$ sudo service mediatomb restart
 

Humerously, web sites will say: it will tell you what web site to go to when it starts up.  I've never seen that.  Regardless, we have some manipulation to do first anyways. 

~$ sudo cat /var/log/mediatomb/mediatomb.html

will show you the web site to browse to to open the User interface.

Let us change the permissions of our directory first.

~$ sudo adduser yourname mediatomb

Do this for everyone that you samba shared the directory for because we're going to make the group on our media directory "mediatomb."

~$ sudo chown root.mediatomb -R /mnt/bigdrive/multimedia/

~$ sudo chmod g+s /mnt/bigdrive/multimedia

Launch the UI now by browsing to the web site (which is actually pointing to the server you just created):

http://192.168.1.3/49152

Click on "filesystem," and then browse to the /mnt/bigdrive/multimedia directory that you just changed permissions on.

I then clicked on the "add as autoscan" icon to the far top right.

It brings up a little i-frame with some options:

I did "Inotify:full:recursive."

Then "Set."

If you then click on the "database" link back on the left, you can then see your media directory ready for sharing in all its glory.

That's it.  Go to your PS3 and see if it shows up.  Mine shows up in multiple places as "mediatomb" with the white mediatomb icon.

Epilogue

 

I hope you enjoyed this tutorial and, if you find it useful, make sure you 'vote for it" so others will be able to find it easier and avoid the pain and suffering should they want to do the same thing.