Squid memiliki Access List atau ACL yang bisa digunakan sebagai sarana untuk memfilter akses terhadap alamat url (situs) tertentu, acl yang digunakan disini adalah “url_regex“.

url_regex ini digunakan untuk memfilter berdasarkan alamat url-nya, misalkan kita ingin blok situs “www.playboy.com“, nah yang kita gunakan sebagai keyword untuk “url_regex” nya adalah “playboy.com“. Efek dari acl ini adalah akses ke seluruh situs yang menggunakan alamat domain “*.playboy.com” akan diblokir.

Namun jika kita hanya ingin blok akses ke subdomain saja dan akses ke domain induknya tetap bisa, maka kita bisa gunakan subdomain-nya sebagai keyword acl nya. Misalnya disini kita mau blok akses ke situs “pornstar.playboy.com” saja dan akses ke “www.playboy.com” dibolehkan, maka disini kita masukkan “pornstar.playboy.com” sebagai keyword acl-nya.

Cukup dengan penjelasan dan teori-teorinya, bosan kali yaa…pengennya langsung praktek..Kita lanjuut..

Kita asumsikan disini anda telah menginstall squid proxy dengan baik dan sudah berfungsi, dan file konfigurasi squid berada pada lokasi “/etc/squid/squid.conf”

Langkah-langkah yang kita lakukan untuk konfigurasi squid nya :

1. Bikin file baru untuk simpan list dari alamat situs yang akan kita blok aksesnya, disini saya menggunakan “vi” karena memang editor favorit saya..

# vi /etc/squid/porn.block.txt

2. Tambahkan list alamat situs yang sudah kita data untuk di blok pada file “/etc/squid/porn.block.txt“, contoh penulisannya adalah sbb :

playboy.com
penthouse.com
duniasex.com
17tahun.com
bangbros.com

Jumlah baris dari alamat tersebut, tergantung dari jumlah situs yang ingin anda blok, untuk database situs porno lainnya bisa anda ambil dari squidguard.org. Kemudian simpanlah file tersebut.

3. Edit file “/etc/squid/squid.conf” dan tambahkan konfigurasi ACL url_regex berikut :

acl porn url_regex “/etc/squid/porn.block.txt”

konfigurasi ini ditambahkan pada bagian acl dari file “squid.conf” nya, contohnya spt dibawah ini :

—–potongan file squid.conf ——

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl Lan src 192.168.10.0/24
acl porn url_regex “/etc/squid/porn.block.txt” <— ACL ditambahkan pada baris ini

—–potongan file squid.conf ——

Penjelasan terhadap acl ini adalah, kita mendefinisikan “porn” sebagai nama access list dengan tipe “url_regex“, dimana list dari url tersebut disimpan pada file dengan nama “/etc/squid/porn.block.txt”

4. Setelah acl porn kita definisikan, kita lanjutkan dengan definisi http_access terhadap list url dari acl porn tadi, dengan cara kita tambahkan lagi pada file “squid.conf” konfigurasi berikut :

http_access deny porn

konfigurasi ini ditambahkan pada bagian http_access dari squid.conf, contohnya spt dibawah ini :

—– potongan file squid.conf —–

http_access deny porn <— ditambahkan pada urutan paling atas dari http_access nya
http_access allow manager localhost
http_access allow lan
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow CONNECT !irc_ports
http_access deny all

—– potongan file squid.conf —–

penjelasan dari http_access ini adalah, akses http terhadap acl dengan nama “porn” akan diblok (deny),
dimana isi dari acl porn ini adalah alamat-alamat situs porno yang memang ingin kita blok.

Contoh file squid.conf setelah dikonfigurasi akan seperti ini :

—–potongan file squid.conf ——

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl Lan src 192.168.10.0/24
acl porn url_regex “/etc/squid/porn.block.txt”

http_access deny porn
http_access allow manager localhost
http_access allow lan
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow CONNECT !irc_ports
http_access deny all

—–potongan file squid.conf ——

5. Selanjutnya kita instruksikan supaya squid untuk membaca ulang file konfigurasi “squid.conf” nya, kita lakukan dengan perintah berikut ini :

# squid -k reconfigure

6. Sekarang kita ujicoba blok akses ke situs pornonya, buka browser favorit kamu misalnya Firefox, kemudian ketikkan salah satu alamat situs yang ada pada file acl porn, misalnya “www.playboy.com“. Jika muncul halaman error “acess denied” maka blokir situs dengan squid nya sukses..

kalo masih bisa diakses..coba di croscheck lagi langkah-langkah diatas…Good Luck..!

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Namun untuk squid dengan versi 2.6.xx cukup dengan menambahkan konfigurasi berikut pada squid.conf nya :

http_port 3128 transparent
always_direct allow all

Sepertinya untuk versi squid 2.6.xx, transparent proxy bisa di set lebih gampang

Denial of Service (DoS)

Varian pertama serangan berupa pengiriman air bah data ke target itu adalah DoS (Denial of Service). Dalam serangan ini penyerang hanya menggunakan satu komputer untuk menyemburkan data ke korbannya.

Penjelasan sederhananya seperti ini: Suatu ketika handphone anda berbunyi. Sebelum anda sempat menggangkatnya handphone anda telah berhenti berbunyi. Tiba-tiba handphone anda berbunyi lagi dan tanpa sempat anda mengangkatnya, bunyi itupun segera berhenti. Beberapa kali anda biarkan tapi masalah ini tak kunjung selesai. Beberapa kolega anda yang hendak menghubungi anda terpaksa tidak bisa melakukannya karena handphone anda sibuk terus. Itulah gambaran sederhana serangan DoS di dunia non-cyber.

Di dunia cyber, kasus anda tersebut merupakan serangan salah satu jenis DOS (Denial of Service). Yang pasti, sebegitu mudahnya DOS ini diterapkan tapi mencegahnya bukanlah suatu hal yang gampang. Target-target serangan DOS biasanya adalah server-server ISP, Internet Banking, E-commerce, Web perusahaan, dan pemerintah.

Serangan DoS dapat dilakukan dengan mengirimkan query sebanyak mungkin hingga target tidak bisa lagi menanganinya sehingga target lumpuh. Cara lain melakukan serangan DoS adalah dengan mengirimkan data rusak atau data yang tidak mampu di tangani oleh server target sehingga server tersebut menjadi hang (tidak bisa berfungsi sebagaimana mestinya dan perlu di restart ulang).

DDOS (Distributed Denial of Service)

Mengirimkan data secara terus menerus dengan menggunakan satu komputer tidak begitu efektif karena biasanya sumber daya server yang diserang lebih besar dari komputer penyerang. Daya bunuh serangan juga akhirnya menjadi lemah.

Hacker penyerangpun memutar otaknya. Serangan dapat lebih mematikan jika tenaga banyak komputer dijadikan satu untuk menciptakan banjir data yang lebih besar.

Komputer-komputer yang diambil alih oleh hacker tersebut disebut zombie. Zombie berfungsi sebagai anak buah atau agent penyerang yang siap beraksi saat mendapat perintah dari “tuannya.”

Semakin banyak zombie yang dkuasai seorang penyerang, semakin berkuasalah sang hacker tersebut karena besarnya tenaga yang ia genggam. Dengan tenaga besar yang dikumpulkan dari komputer-komputer yang dikuasai (secara illegal tentunya) tersebut, serangan DDoS hampir tidak dapat ditangkal. Karena itulah serangan tipe ini sangat populer di kalangan hacker.

Beberapa situs raksasa seperti Amazon.com, eBay, dan Yahoo pada Februari 2000 rontok selama beberapa jam karena serbuan ini. Gedung Putih juga sempat boyongan karena serangan tipe ini. Gedung Putih terpaksa “memindahkan” IP address situsnya karena jengah menerima serangan DDoS yang sudah dirancang untuk muncul pada tanggal dan jam tertentu dengan memanfaatkan virus tertentu tanpa mampu mencegahnya.

DDoS adalah tipe serangan dengan konsep sederhana. Namun efeknya bisa memindahkan “istana negara.”

Menghadapi Serangan DDOS

Serangan DDoS adalah serangan dengan teori sederhana namun dengan dampak yang sangat besar. Sayangnya, sampai saat ini belum ditemukan cara paling tepat untuk menghindari serangan ini secara total.

Meski sampai saat ini belum ada sistem yang kebal terhadap serangan ini, ada sejumlah langkah yang dapat dilakukan untuk memperkecil resiko serangan DDoS ini.

Karena serangan DDoS dapat dilakukan dengan memanfaatkan kelemahan operating system yang anda gunakan, jangan pernah lupa mengupdate patch untuk memerbaiki sistem pengoperasian anda. Ingatlah bahwa tidak ada satupun sistem operasi di dunia ini yang aman dan 100 persen bebas dari kelemahan.

Gunakan hardware/server yang kuat. Server tersebut harus mampu menangani beban yang cukup berat sehingga server anda tidak mudah down. Anda bisa mendesain network yang saling membackup dan akan lebih bagus jika berada pada beberapa daerah sekaligus.

Gunakan firewall untuk mengeblok port-port (pintu masuk) yang tidak di perlukan di server-server anda.

Gunakan IDS (Intrusion Detection System) untuk mendeteksi penyusup dan melakukan pencegahan yang lebih cerdik.

Terminologi dan Tools Pada DDoS (uzi)

Terminologi-terminologi yang umum dalam serangan DDoS antara lain adalah Client – sebuah aplikasi yang digunakan untuk memicu serangan dengan mengirimkan perintah ke komponen-komponen lain, Daemon – sebuah proses dalam menjalankan agent yang bertanggung jawab menerima dan melaksanakan perintah yang dikeluarkan client, Master – host yang menjalankan client, Agent – host yang menjalankan Daemon, dan Target – korban (berupa host atau jaringan) yang dihantam serangan DDoS. Alur serangan DDoS adalah:

Penyerang (Master) -> Client -> Daemon -> Korban (Target)

Tools

Program-program yang dapat digunakan hacker untuk melancarkan serangan DDoS semakin mudah didapatkan dari Internet. Karenanya semakin berbahaya pula ancaman ini dengan semakin banyaknya orang yang dapat melakukannya.

Beberapa tool paling terkenal yang sering digunakan untuk melancarkan serangan DDoS adalah TFN2K, Trinoo dan Stacheldraht

TFN2K

TFN2K (Tribe Flood Network 2000) adalah tool untuk melancarkan serangan DDoS. TFN2K adalah turunan Trojan TFN.

TFN2K memungkinkan master mengeksploitasi sejumlah agent untuk mengkoordinasikan serangan pada satu atau beberapa target yang diincar. Saat ini, Unix, Solaris, dan Windows NT adalah platform-platform yang rentan terhadap serangan ini.

TFN2K adalah sistem dengan dua komponen. Yang pertama adalah client yang dikomando oleh master dan sebuah proses daemon yang beroperasi pada sebuah agent. Master menginstruksikan para agent yang telah ditaklukkannya untuk menyerang target yang telah ditentukan. Para agent tersebut kemudian merespon dengan membanjirkan serbuan paket data. Sejumlah agent, dengan perintah Master, dapat bekerjasama selama serangan ini untuk mematahkan akses target. Komunikasi master-to-agent telah dienkripsi dan bercampur dengan paket-paket yang diluncurkan. Baik komunikasi master-to-agent maupun serangan itu sendiri dapat dikirimkan melalui paket-paket TCP, UDP, dan ICMP yang telah diacak. Master juga dapat melakukan pemalsuan IP address (spoofing). Hal ini membuat penagkalan TFN2K sangat sukar dilakukan.

Trinoo

Trinoo (a.k.a. trin00) adalah program slave/master terkenal yang digunakan dalam serangan DDoS. Daemon Trinoo awalnya ditemukan pada format binary sejumlah sistem Solaris 2.x, yang diidentifikasi dapat dimanfaatkan dengan mengeksploitasi bug buffer overrun.

Jaringan Trinoo dapat berupa ratusan bahkan ribuan sistem di Internet yang diambilalih dengan eksploitasi buffer overrun secara remote. Akses ke sistem-sistem yang dijadikan agent tersebut didapatkan dengan menanamkan program back door sekaligus daemon Trinoo.

Sebuah jaringan Trinoo yang paling tidak terdiri atas 227 sistem – 114 diantaranya merupakan situs-situs Internet – yang pada 17 Agustus 1999 digunakan untuk membanjiri satu sistem yang ada di University of Minnessota. Akibatnya, server malang itu ambruk dan koma selama dua hari. Saat penanganan terhadap serangan 17 Agustus itu dilakukan, banjir besar data juga diketahui sedang menyerang paling tidak 16 sistem lain, yang sebagian terdapat di luar AS.

Stacheldraht

Stacheldraht (Bahasa Jerman yang artinya adalah kawat berduri) adalah tool lain yang populer untuk melancarkan serangan DDoS.

Tool ini sangat unik karena ia menggabungkan fitur-fitur yang dimiliki oleh Trinoo dan TFN generasi pertama. Tool ini juga mempunyai enkripsi komunikasi antara penyerang dan master-master Stacheldraht serta mampu melakukan update agent secara otomatis.

Seperti Trinoo, Stacheldraht terdiri atas program-program master (handler) dan daemon atau bcast (agent). Fitur TFN yang dimiliki Stacheldraht adalah gaya-gaya serangan ICMP flood, SYN flood, UDP flood, dan “Smurf.” (uzi)

Sumber: http://forum.webgaul.com/

Bahan Bacaan:

http://www10.org/cdrom/papers/409/
http://panoptis.sourceforge.net/
http://www.grc.com/dos/drdos.htm
http://www.icir.org/vern/papers/reflectors.CCR.01/reflectors.html
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/dos_attacks.html
http://staff.washington.edu/dittrich/misc/ddos/

from adminpreman.web.id

Here, we will look at monitoring the local system’s swap and memory usage over time. This assumes that MRTG is already configured or you have an understanding of how to configure MRTG .The first step is to create the script, which is very simplistic. Save it as /usr/local/bin/memstat.sh with the following contents:

#!/bin/sh/usr/bin/free -b | /bin/awk 'NR==2 {ramUsed = $3 }NR==4 {swapUsed = $3 }END { print swapUsed "n" ramUsed "n0n0" }'

The output, for a human, is not very interesting:

# /usr/local/bin/memstat.sh0154800947200

For MRTG, however, with the appropriate configuration, it becomes very interesting. Add the following snippet to /etc/mrtg.cfg. Ideally, MRTG should be running every five minutes for a good sampling.

Target[localmem]: `/usr/local/bin/memstat.sh`Title[localmem]: Mem and Swap Usage [surtr]PageTop[localmem]: <h1>Memory and Swap Usage [surtr]</h1>MaxBytes[localmem]: 100000000000ShortLegend[localmem]: BYLegend[localmem]: MemoryLegendI[localmem]: SwapLegendO[localmem]: MemLegend1[localmem]: SwapLegend2[localmem]: MemOptions[localmem]: gauge,growright,nopercentkMG[localmem]: k,M,G,T,P,XColours[localmem]: RED#bb0000,BLUE#1000ff,GREEN#006600,VIOLET#ff00ff

This code tells MRTG to execute the /usr/local/bin/memstat.sh script and take the numbers it provides as output as input for itself, which will then be used to create a typical MRTG graph of the data. This will then give you a sampling of memory and swap usage over time. MRTG will create graphs for yearly, monthly, weekly, and daily statistics.Using the same, you could perform the same data analysis for CPU usage, disk usage, e-mail statistics, Web traffic, and much more.(from www.builderau.com.au)

• Client-side TCP connections
• Server-side TCP connections
• Writing cachable responses to disk
• Reading cache hits from disk
• Log files
• Communication with external helper processes, such as redirectors and authenticators
• Idle (persistent) HTTP connections

Even when Squid is not doing anything, it has some number of file descriptors open for log files and helpers. In most cases, this is between 10 and 25, so it’s probably not a big deal. If you have a lot of external helpers, that number goes up. However, the file descriptor count really goes up once Squid starts serving requests. In the worst case, each concurrent request requires three file descriptors: the client-side connection, a server-side connection for cache misses, and a disk file for reading hits or writing misses.A Squid cache with just a few users might be able to get by with a file descriptor limit of 256. For a moderately busy Squid, 1024 is a better limit. Very busy caches should use 4096 or more. One thing to keep in mind is that file descriptor usage often surges above the normal level for brief amounts of time. This can happen during short, temporary network outages or other interruptions in service.There are a number of ways to determine the file descriptor limit on your system. One is to use the built-in shell commands limit or ulimit.For Bourne shell users:

root# ulimit -n1024

For C shell users:

root# limit descdescriptors     1024

If you already have Squid compiled and installed, you can just look at the cache.log file for a line like this:

2003/12/12 11:10:54| With 1024 file descriptors available

If Squid detects a file descriptor shortage while it is running, you’ll see a warning like this in cache.log:

WARNING! Your cache is running out of file descriptors

If you see the warning, or know in advance that you’ll need more file descriptors, you should increase the limits. The technique for increasing the file descriptor limit varies between operating systems.

For Linux Users

Linux users need to edit one of the system include files and twiddle one of the system parameters via the /proc interface. First, edit /usr/include/bits/types.h and change the value for __FD_SETSIZE. Then, give the kernel a new limit with this command:

root# echo 1024 > /proc/sys/fs/file-max

Finally, before compiling or running Squid, execute this shell command to set the process limit equal to the kernel limit:

root# ulimit -Hn 1024

After you have set the limit in this manner, you’ll need to reconfigure, recompile, and reinstall Squid. Also note that these two commands do not permanently set the limit. They must be executed each time your system boots. You’ll want to add them to your system startup scripts.

For NetBSD/OpenBSD/FreeBSD Users

On BSD-based systems, you’ll need to compile a new kernel. The kernel configuration file lives in a directory such as /usr/src/sys/i386/conf or /usr/src/sys/arch/i386/conf. There you’ll find a file, possibly named GENERIC, to which you should add a line like this:

options       MAXFILES=8192

For OpenBSD, use option instead of options. Reboot your system after you’ve finished configuring, compiling, and installing your new kernel. Then, reconfigure, recompile, and reinstall Squid.

For Solaris Users

Add this line to your /etc/system file:

set rlim_fd_max = 1024

Then, reboot the system, reconfigure, recompile, and reinstall Squid.For further information on file descriptor limits, see Chapter 3, “Compiling and Installing”, of Squid: The Definitive Guide or section 11.4 of the Squid FAQ.  

web experience as Firefox suddenly decides to run painfully slow. About 30 minutes wasted on finding the culprit (like changing your DNS servers, clearing browser cache, etc.) until you decide to check the router and then Squid and then its logs. And then you find something fishy:

WARNING! Your cache is running out of filedescriptors

I won’t be explaining why this happens. Others have done it before. What I’m going to do is present you with a solution that does not require a complete Squid recompilation/reinstallation procedure.

However, I believe it requires a fairly modern setup to work. I was using Squid 2.6 STABLE6 on Fedora Core 6 with 2.6.18 kernel. Your mileage may vary.

Stopping the Squid

This is important:

/etc/init.d/squid stop

/etc/squid/squid.conf

At the very end of this file there is a line which needs adding/changing so it reads:

max_filedesc 8192

/etc/init.d/squid

Just after the comments (before any code) add this line:

ulimit -HSn 8192

/usr/include/bits/typesizes.h

Edit the __FD_SETSIZE line so it reads:

#define __FD_SETSIZE            8192

Starting the squid

/etc/init.d/squid start

And now watch the /var/log/squid/cache.log for a similar line:

2007/01/01 18:32:27| With 8192 file descriptors available

If it still says 1024 file descriptors available (or similarly low value) you are out of luck (or you’ve just messed something up).

An easy way to monitor Squid’s memory usage is with standard system tools such as top and ps. You can also ask Squid itself how much memory it is using, through either the cache manager or SNMP interfaces. If the process size becomes too large, you’ll want to take steps to reduce it. A good rule of thumb is to not let Squid’s process size exceed 60% to 80% of your RAM capacity.

One of the most important uses for memory is the main cache index. This is a hash table that contains a small amount of metadata for each object in the cache. Unfortunately, all of these “small” data structures add up to a lot when Squid contains millions of objects. The only way to control the size of the in-memory index is to change Squid’s disk cache size (with the cache_dir directive). Thus, if you have plenty of disk space, but are short on RAM, you may have to leave the disk space underutilized.

Squid’s in-memory cache can also use significant amounts of RAM. This is where Squid stores incoming and recently retrieved objects. Its size is controlled by setting the cache_mem directive. Note that the cache_mem directive only affects the size of the memory cache, not Squid’s entire memory footprint.

Squid also uses some memory for various I/O buffers. For example, each time a client makes an HTTP request to Squid, a number of memory buffers are allocated and then later freed. Squid uses similar buffers when forwarding requests to origin servers, and when reading and writing disk files. Depending on the amount and type of traffic coming to Squid, these I/O buffers may require a lot of memory. There’s not much you can do to control memory usage for these purposes. However, you can try changing the TCP receive buffer size with the tcp_recv_bufsize directive.

If you have a large number of clients accessing Squid, you may find that the “client DB” consumes more memory than you would like. It keeps a small number of counters for each client IP address that sends requests to Squid. You can reduce Squid’s memory usage a little by disabling this feature. Simply put client_db off in squid.conf.

Another thing that can help is to simply restart Squid periodically, say, once per week. Over time, something may happen (such as a network outage) that causes Squid to temporarily allocate a large amount of memory. Even though Squid may not be using that memory, it may still be attached to the Squid process. Restarting Squid allows your operating system to truly free up the memory for other uses.

You can use Squid’s high_memory_warning directive to warn you when its memory size exceeds a certain limit. For example, add a line like this to squid.conf:

high_memory_warning 400 MB

Then, if the process grows beyond that value, Squid writes warnings to cache.log and syslog if configured.

Use the following access control rules to make sure this never happens to you. First, always deny all requests that don’t come from your local network. Define an ACL element for your subnet:

acl MyNetwork src 10.0.0.0/16

Then, place a deny rule near the top of your http_access rules that matches requests from anywhere else:

http_access deny !MyNetwork
http_access ...
http_access ...

While that may stop outsiders, it may not be good enough. It won’t stop insiders who intentionally, or unintentionally, try to forward spam through Squid. To add even more security, you should make sure that Squid never connects to another server’s SMTP port:

acl SMTP_port port 25
http_access deny SMTP_port

In fact, there are many well-known TCP ports, in addition to SMTP, to which Squid should never connect. The default squid.conf includes some rules to address this. There, you’ll see a Safe_ports ACL element that defines good ports. A deny !Safe_ports rule ensures that Squid does not connect to any of the bad ports, including SMTP.

Squid has about 20 different ACL types. These refer to certain aspects of an HTTP request or response, such as the client’s IP address (the src type), the origin server’s hostname (the dstdomain type), and the HTTP request method (the method type).

An ACL element consists of three components: a type, a name, and one or more type-specific values. Here are some simple examples:

acl Foo src 1.2.3.4
acl Bar dstdomain www.cnn.com
acl Baz method GET

The above ACL element named Foo would match a request that comes from the IP address 1.2.3.4. The ACL named Bar matches a www.cnn.com URL. The Baz ACL matches an HTTP GET request. Note that we are not allowing or denying anything yet.

For most of the ACL types, an element can have multiple values, like this:

acl Argle src 1.1.1.8 1.1.1.28 1.1.1.88
acl Bargle dstdomain www.nbc.com www.abc.com www.cbs.com
acl Fraggle method PUT POST

A multi-valued ACL matches a request when any one of the values is a match. They use OR logic. The Argle ACL matches a request from 1.1.1.8, from 1.1.1.28, or from 1.1.1.88. The Bargle ACL matches requests to NBC, ABC, or CBS web sites. The Fraggle ACL matches a request with the methods PUT or POST.

Now that you’re an expert in ACL elements, its time to graduate to ACL rules. These are where you say that a request is allowed or denied. Access list rules refer to ACL elements by their names and contain either the allow or deny keyword. Here are some simple examples:

http_access allow Foo
http_access deny Bar
http_access allow Baz

It is important to understand that access list rules are checked in order and that the decision is made when a match is found. Given the above list, let’s see what happens when a user from 1.2.3.4 makes a GET request for www.cnn.com. Squid encounters the allow Foo rule first. Our request matches the Foo ACL, because the source address is 1.2.3.4, and the request is allowed to proceed. The remaining rules are not checked.

How about a PUT request for www.cnn.com from 5.5.5.5? The request does not match the first rule. It does match the second rule, however. This access list rule says that the request must be denied, so the user receives an error message from Squid.

How about a GET request for www.oreilly.com from 5.5.5.5? The request does not match the first rule (allow Foo). It does not match the second rule, either, because www.oreilly.com is different than www.cnn.com. However, it does match the third rule, because the request method is GET.

Of course, these simple ACL rules are not very interesting. The real power comes from Squid’s ability to combine multiple elements on a single rule. When a rule contains multiple elements, each element must be a match in order to trigger the rule. In other words, Squid uses AND logic for access list rules. Consider this example:

http_access allow Foo Bar
http_access deny Foo

The first rule says that a request from 1.2.3.4 AND for www.cnn.com will be allowed. However, the second rule says that any other request from 1.2.3.4 will be denied. These two lines restrict the user at 1.2.3.4 to visiting only the www.cnn.com site. Here’s an even more complex example:

http_access deny Argle Bargle Fraggle
http_access allow Argle Bargle
http_access deny Argle

These three lines allow the Argle clients (1.1.1.8, 1.1.1.28, and 1.1.1.88) to access the Bargle servers (www.nbc.com, www.abc.com, and www.cbs.com), but not with PUT or POST methods. Furthermore, the Argle clients are not allowed to access any other servers.

One of the common mistakes often made by new users is to write a rule that can never be true. It is easy to do if you forget that Squid uses AND logic on rules and OR logic on elements. Here is a configuration that can never be true:

acl A 1.1.1.1
acl B 2.2.2.2
http_access allow A B

The reason is that a request cannot be from both 1.1.1.1 AND 2.2.2.2 at the same time. Most likely, it should be written like this:

acl A 1.1.1.1 2.2.2.2
http_access allow A

Then, requests from either 1.1.1.1 or 2.2.2.2 are allowed.

Access control rules can become long and complicated. When adding a new rule, how do you know where it should go? You should put more-specific rules before less-specific ones. Remember that the rules are checked in order. When adding a rule, go through the current rules in your head and see where the new one fits. For example, let’s say that you want to deny requests to a certain site, but allow all others. It should look like this:

acl XXX www.badsite.net
acl All src 0/0
http_access deny XXX
http_access allow All

Now, what if you need to make an exception for one user, so that she can visit that site? The new ACL element is:

acl Admin 3.3.3.3

and the new rule should be:

http_access allow Admin XXX

but where does it go? Since this rule is more specific than the deny XXX rule, it should go first:

http_access allow Admin XXX
http_access deny XXX
http_access allow All

If we place the new rule after deny XXX, it will never even get checked. The first rule will always match the request and she will not be able to visit the site.

When you first install Squid, the access control rules will deny every request. To get things working, you’ll need to add an ACL element and a rule for your local network. The easiest way is to write an source IP address ACL element for your subnet(s). For example:

acl MyNetwork src 192.168.0.0/24

Then, search through squid.conf for this line:

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

After that line, add an http_access line with an allow rule:

http_access allow MyNetwork

Once you get this simple configuration working, feel free to move on to some of the more advanced ACL features, such as username-based proxy authentication.

If you don’t rotate the log files, they may eventually consume all free space on that partition. Some operating systems, such as Linux, cannot support files larger than 2Gb. When this happens, you’ll get a “File too large” error message and Squid will complain and restart.

To avoid such problems, create a cron job that periodically rotates the log files. It can be as simple as this:

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

In most cases, daily log file rotation is the most appropriate. A not-so-busy cache can get by with weekly or monthly rotation.

Squid appends numeric suffixes to rotated log files. Each time you run squid -k rotate, each file’s numeric suffix is incremented by one. Thus, cache.log.0 becomes cache.log.1, cache.log.1 becomes cache.log.2, and so on. The logfile_rotate directive specifies the maximum number of old files to keep around.

Logfile rotation affects more than just the log files in /usr/local/squid/var/logs. It also generates new swap.state files for each cache directory. However, Squid does not keep old copies of the swap.state files. It simply writes a new file from the in-memory index and forgets about the old one.