Setting Up A Snort IDS on Debian Linux
NOTE: There is no Snort package in Jessie (8.x) or Acidbase package in 7.x or 8.x. However,
OSDisc.com has agreed to continue offering the Squeeze (6.0) DVD set if you want to set up a Snort IDS.
The material on this page was prepared using Lenny (5.0)
configured using our Installation and Packages pages.
If you did not use our pages to set up your system, what you
encounter on your system may be different than what is given here.
Malicious network traffic (such as worms, hacking attempts, etc.) has certain patterns to it. You could monitor your network traffic with a sniffer and look for this malicious traffic manually but that would be an impossible task. Enter IDS (Intrusion Detection System) software which automates the process of sniffing, examining, and upon finding something suspicious, alerting.
IDS has been called the burglar alarm of computer networks and is an important part of network perimeter security. WIthout an IDS you have no idea if someone is probing or attacking your servers (unless the attack is so overwhelming that it results in a denial of service). Having this information can let you know if you need to make some firewall changes or harden the OS on a particular server a bit more.
You may see the term IPS for Intrusion Prevention Systems which takes things one step further, having the IDS adjust the firewall when it discovers something. Smart people disagree on the use of IPSs as it, in effect, gives an attacker some control of your firewall.
Snort (www.snort.org) is the most widely-used IDS software applicaton and it's open source and included with Debian. There are two flavors of IDSs, host-based and network-based. Snort is a network-based IDS that can monitor all of the traffic on a network link to look for suspicious traffic. Typically, a network-based IDS is set up to monitor a DMZ or the internal network right behind the firewall so it alerts to any possible threats that your firewall didn't catch.
There is a Web interface that works with Snort called BASE (Basic Analysis and Security Engine) which is based on ACID (Analysis Console for Intrusion Databases) which we'll set up. BASE uses what's commonly referred to as a LAMP server (Linux, Apache, MySQL, PHP) so we'll need to install those applications as well.
Because LAMP servers tend to attract hackers we'll want to put the Snort box on an internal network but this requires setting up your Snort box with two NICs. One NIC is connected to your internal network with an appropriate IP address for that network (like 172.24.1.20). This internal address is the one we point our Web browsers at when we want to look at the BASE Web pages. The other NIC does NOT have an IP address. It plugs into whatever network segment you want to monitor, like your DMZ or even your Interent segment outside of your firewall. Snort puts this NIC into promiscuous mode so it can snort up all the traffic it sees (basically it's Snort's snout). By not putting an IP address on Snort's promiscuous NIC you can get away with plugging this NIC into a DMZ link or even outside of your firewall (on your Internet link).
On this page we assigned an address to the eth0 interface and we'll be using eth1 as the promiscuous interface. Adjust these values for your system as necessary.
Connecting the promiscuous NIC into the segment you want to monitor is not as easy as just plugging it into a switch port. Because switches segment each port into it's own little collision domain, if you do plug the promiscuous NIC into a switch port it'll only see broadcast traffic. You need to either tap into the link you want to monitor using a hub, or you have to do port spanning on your switch. If you're interested in monitoring traffic coming in from the Internet, given that most Internet (broadband) connections are less than 10 megabit you can pick up an old 4-port 10-meg hub on eBay to tap into this link. (Just make sure you're getting a hub as many people use the terms hub and switch interchangeably.) If you want to monitor traffic on your internal network, you could configure port spanning on your switch. Port spanning simply takes all of the traffic on one or more switch ports and duplicates it to a span port that has a monitoring device connected. Consult your switch documentation on how to set this up.If you run the Debian installer with two NICs installed in the system, it will let you choose if you want to configure eth0 or eth1 with an IP address. However, this necessitates that you use the netcfg/disable_dhcp=true switch when you start the Debian installation. (We specify using this switch on our Installation page.) If you have more than one brand of NIC to choose from it'll make your life a little easier if you use NICs by two different manufacturers as it will be easier to determine which NIC Debian designates as the eth0 interface and which NIC is designated as the eth1 interface.
The above diagram shows how you'd use a hub to monitor the traffic coming in from a cable or DSL modem. Note that Snort's promiscuous NIC is located before the cable/DSL router. (Most cable/DSL routers have some limited firewall capabilities.) In this case, in order to determine the HOME_NET value (discussed below) you'd have to know the IP address that your router pulled from your ISP's DHCP server. The easiest way to find out what IP address your router pulled is to visit a Web site like whatsmyipaddress.com that displays your "external" IP address when you visit the site.Snort has a "rule base" that contains patterns or "signatures" of malicious traffic much like an antivirus program has a database of virus signatures that it uses to compare to streams of program code. Also like antivirus software, you can download updates to Snort's rule base file. Unlike an antivirus signature database, you can tweak the rules in Snort's rule base to minimize false alerts. You can also choose which rules you want Snort to use and which to ignore to taylor Snort to your network environment. For example, a Snort rule may closely resemble the traffic patterns of a custom-written Web application that your organization uses. In this case you would disable this rule so you don't get false-positive alerts when the application is used.NOTE: There's no law saying that both NICs can't be connected to the same network (even the same switch). If you wanted to monitor your internal network for possible virus or worm traffic, both NICs would be connected to the same network. The promiscuous NIC would be connected to a span port sucking up the traffic and the addressed NIC is used for accessing the BASE Web pages.
Lets start setting up the LAMP server by installing MySQL with the command:
apt-get install mysql-server
You'll be prompted to enter a password for the MySQL root account (equivalent to the sa password in MS SQL). We'll be needing it in a few minutes. If you haven't already done so, install Apache next with the command:
apt-get install apache2
Now finish the LAMP server setup with the command:
apt-get install php5
Now that we have our LAMP server components installed we can install Snort. Because we have MySQL installed we can use the MySQL-specific Snort (version 2.7) package.
What Is HOME_NET ?The HOME_NET variable in Snort's configuration file should contain (in CIDR format) the network that you want to protect, i.e. the network that your servers are on, i.e. the network you are going to plug the promiscuous NIC into. This may not be the same network that the addressed NIC on your Snort box plugs into.
Install the package with the command:
apt-get install snort-mysql
The first thing it asks for is the HOME_NET value. If your servers are on a Class C network (or subnet) with an address like 192.168.1.15 then enter 192.168.1.0/24 for the HOME_NET CIDR block. If your servers are on a Class B network with an address of something like 172.24.3.15 then enter 172.24.0.0/16 for the HOME_NET CIDR block. In our diagram above, lets say your router pulled an IP address of 126.96.36.199. You could just enter that as a Class C CIDR block of 188.8.131.52/24.
The next screen tells you that no database has been set up for Snort. Press Enter and then, with the default Yes selected, press Enter again.
Snort will finish installing and it will end with an error (error code 1). That error was generated because Snort failed to start. Snort failed to start because it's not configured yet. In short, no problem.
Next we'll install the BASE Web interface with the command:
apt-get install acidbase
You'll see an informational screen about the include path (just press Enter) and a manual configuration informational screen (just press Enter.)
Next you'll be prompted to configure the database for acidbase. Select the default 'Yes' by pressing Enter. Then on the next screen 'mysql' will be selected so just press Enter.
Next you'll be prompted to enter the password for the MySQL "administrative user" which is root so enter the MySQL root password that you entered above when you installed MySQL.
You'll then be prompted to create and confirm an application password for the acidbase database. Note that this is not the password for the MySQL root account you just entered. This password should not be the same as your MySQL root password because it's stored in clear text. Once these are entered the acidbase installation will finish. (You'll get the snort-mysql error code 1 again but don't worry about it for now.)
The next thing we have to do is alias the BASE directory to our Apache "Web root" so we can include it in a browser URL. To do that we need to enter some statements into the Apache default configuration file. Luckily the statements we need to enter are in a file that was installed with the acidbase package. Open the Apache default configuration file with the command:
Cursor down to the bottom of the file. The last line in the file is the </VirtualHost> statement. Put your cursor on the blank line just above this statement and press Ctrl-r and in the "File to insert" field enter:
and press Enter. Cursor up a few lines to the line that reads:
allow from 127.0.0.0/255.0.0.0
and change the network address and subnet mask to match the machines on your local network that will be accessing the BASE Web pages. For example, change it to 192.168.1.0/255.255.255.0 for a Class C internal network. You can change both the address and subnet mask to all zeros if you want don't want any address restrictions on who can access the BASE Web pages.
Now do a Ctrl-x and press 'y' at the prompt to save the changes and press Enter to write the file.
During the acidbase installation we were prompted to create a Snort database. However, now we have to use a pre-defined script to build the structure (tables, fields, etc.) of the database. Change directories with the command:
and enter the following command to run a script which creates the database structure. Note that that is a pipe symbol after create_mysql.gz in the command. Also note that you want to enter the application password that you entered during the acidbase install, not the MySQL root password. If you don't remember what you entered, cat the /etc/acidbase/database.php file. Also be sure to NOT put a space between the -p and the password itself.
zcat create_mysql.gz | mysql -u snort -D snort -papplicationpassword
If you don't see anything be glad. The only time executing this command will print out anything is if there was an error. With the database configured Snort can now start. However, there is a 'flag' file that we need to delete to indicate that we have the database configured. Enter the command:
to delete this file. With that flag gone we need to do a little installation housekeeping with the command:
dpkg --configure --pending
Because our promiscuous NIC wasn't "up" when we installed Snort, it just assumed we wanted to use the NIC that was up. We need to tell Snort to use our promiscuous NIC. We do this by reconfiguring Snort with the command:
For the "Snort start method" accept the default boot selection, tab to OK and press Enter.
At the informational screen on interfaces, tab to OK and press Enter.
Assumming your promiscuous NIC is the second NIC in your system, change the interface value to eth1 instead of eth0 and then tab to OK and press Enter.
On the next screen the HOME_NET value you entered during the package installation should still be there (if not, re-enter it) so just tab to OK and press Enter.
Next you are asked if you want to disable promiscuous mode on the interface you entered. Accept the default No by pressing Enter.
Next you are asked if you want to change Snort's testing order. Accept the default No by pressing Enter.
Leave the "Additional custom options" field blank, tab to OK and press Enter.
Next you have the option of receiving daily summaries by e-mail. If you answer 'Yes' to this, and enter a recipient other than the default 'root' entry (be sure to enter a full e-mail address), see the section below on setting up e-mail services.
For now, accept the default value of 1 for minimum occurances by tabbing to OK and pressing Enter.
The next screen lets you know that Snort hasn't been set up to write entries to a database. Press Enter at OK and again at Yes to set this up.
When it asks for a "Database server hostname" enter localhost and tab to OK and press Enter.
Next it will ask you for the name of an existing database. Enter snort, tab to OK and press Enter.
In the "Username" field enter snort, tab to OK and press Enter.
In the "password" field enter the application password you chose earlier, tab to OK and press Enter. Then press Enter again at the information screen.
You'll see messages that Snort failed to start because eth1 was not available. We need to change the way Snort starts so it uses our promiscous NIC. Snort is set to run as a daemon automatically at boot up but with that configuration it won't bring up our promiscuous NIC (eth1). Disable this with the command:
mv /etc/rc2.d/S20snort /etc/rc2.d/_S20snort
We'll create a startup script of our own to bring up our promiscuous NIC and set it not to respond to arp requests (so hackers don't discover we're monitoring the network segment). Fire up a text editor with the command:
and enter the following two commands:
ifconfig eth1 up -arp
Exit the editor saving the file. Now we need to make our script executable with the command:
chmod 750 /etc/init.d/runsnort.sh
All scripts that could be run when the system boots, no matter the runlevel, are put in the /etc/init.d directory but it's the runlevel that determines which of these scripts actually gets run when the system boots up. Debian's default runlevel is 2 so we need to create a symbolic link to our script in the runlevel 2 directory. Do that with the command:
ln -s /etc/init.d/runsnort.sh /etc/rc2.d/S95runsnort
Reboot your system. Everything should now come up automatically. (When Snort starts it will indicate which NIC it's using.) Connect your promiscuous NIC to the network segement you want to montior, either by using a hub or spanning a switch port, and test it out.
You can make sure the promiscuous NIC came up during the bootup process by entering the command:
The promiscuous NIC (eth1) should be listed and NOT have an "inet addr" (IP address) entry while the NIC you've assigned an IP address to should.
Next, make sure Snort is seeing network traffic on the promiscuous NIC by entering the command:
snort -i eth1 -v
This will run a second instance of Snort in verbose mode. The destination IP addresses of the traffic displayed should be within the network address space of the HOME_NET value you specified earlier. Press Ctrl-C to stop the display and exit the second instance of Snort.
We've got Snort up and running but there's still some minor BASE stuff we need to take care of. This next bit of setup is done via a Web browser. Get on another system on the network and fire up a browser (or fire up a browser on your Snort box if you installed the X-Windows and browser packages) and enter the following URL using the IP address you assigned to the addressed NIC of your Snort box:
You should see the BASE banner graphic and, right underneath it, a message saying that the database "appears to be incomplete/invalid." On the next line you'll see a
Setup pagelink. Click on that.
One the right side of the next page you'll see a Create BASE AG button. Click on that.
You should see a series of red Successfully created and Successfully INSERTED messages displayed. Further down on the left side of the page, click on the
Main pagelink. This is the BASE home page and it will update automatically every three mintues.
What If Nothing Is DisplayedHaving all "0%" showing for the traffic graphs on the BASE home page is what we're hoping for (no suspicious traffic) but if nothing is ever displayed you may have a problem. The most common cause of the BASE Web pages never displaying any statistics or alert information when you know there should be is an incorrect HOME_NET value. Check to make sure the value you set for the HOME_NET variable matches the address space of the network segment you're monitoring.
Snort's default configuration file is the /etc/snort/snort.conf file. However, there is also a /etc/snort/snort.debian.conf file. The Debian-specific file is where the settings are stored when you run the dpkg-reconfigure command. This Debian-specific configuration file is used by the /etc/init.d/snort startup script and the settings in it take precedence over the corresponding settings in the /etc/snort/snort.conf file.
Next we have to take care of setting up the summary e-mails that Snort sends out.
Setting Up Snort E-mailing
If you answered 'No' to receiving summary e-mails from Snort or you accepted the default 'root' recipient, you can skip to the "Managing Rules" section.
By default, the Debian installer installs the Exim mail server package and configures it to only handle local (between accounts on the server) delivery. We need to set up our server to act as an e-mail client (like Outlook or Thunderbird) to your SMTP server so it can send the daily summary e-mails Snort generates to an "outside" (non-local) e-mail address.
We reconfigure Exim with the command:
Press Enter at the configuration information screen. On the configuration selection screen, because Snort won't be receiving any mail, select the "mail sent by smarthost; no local mail" option.
Next it asks for a "system mail name". This should have the same domain name as your e-mail address. For example, if your e-mail address is email@example.com then your system mail name should be something like debian.flintstone.com (the first part of the name should be the hostname of your server and the second part would be your, or your ISP's, domain). Again, because no one should be trying to send e-mails to your Snort server, it shouldn't matter that your server's name isn't in your ISP's DNS.
Accept the default 127.0.0.1 address for an incoming SMTP connection.
On the "other destinations" screen, backspace everything out of the field (so it's blank) and tab to OK and hit Enter.
Because you used your ISP's domain name you can just accept the default value for the "visible domain" value.
In the "outgoing smarthost" field, backspace out whatever is there and enter the name or IP address of your ISP's SMTP server (the same SMTP server you have entered in your e-mail client program (Thunderbird, Outlooks, etc.).
Accept the default 'No' to keeping DNS queries minimal and hit Enter.
Accept the default 'No' to splitting the configuration files and hit Enter.
Exim will then restart automatically with your new configuration.
Since day one you needed to use an ID (your e-mail ID) and password to access your received (POP) e-mail messages. These days more and more ISPs are starting to require those same credentials to send (SMTP) e-mail messages. If your ISP requires SMTP authentication you'll need to edit an Exim file to supply those credentials. Enter the command:
and enter an asterisk, your e-mail login ID, and your e-mail password, separated by colons, like so:
Exit the editor saving the changes. Snort can now use Exim as an e-mail client to send the daily summaries. Don't be surprised if you don't get any e-mails. Snort will only send them when it's detected suspicious traffic. If you don't see any stats on the graphs on the BASE home page, you won't get any e-mails.
By design, the /etc/snort/snort.conf configuration file holds all the rules Snort will use for traffic comparisons. While this is logically the case, it is not physically true.
If you open the /etc/snort/snort.conf file in a text editor and page down to section 6 and read the comments. Below the comments you'll see a bunch of include statements where various rule files (located in the /etc/snort/rules directory) are included into the configuration file. The actual rules themselves are not entered directly into the configuration file to simplify management. Note that the include statements that have a pound symbol (#) in front of them are the disabled rules. (Note that you can disable rules by disabling an entire rule file inthe /etc/snort/snort.conf file, or by disabling individual rules within a rule file as you will see below.)
Any rule files that start out with the word community are rules written by Snort users. They do go through a couple checks by the Snort team to make sure they won't break your Snort installation, but they don't get the same scrutiny as those rules written by the Snort team. As you'll see in the configuration file, quite a few of these community rule files are enabled by default. If you're getting a lot of false alerts related to a specific application, you may want to try disabling the community rule file in Snort's configuration file as a first step and then try and narrow it down.
If you want to play around with editing or customizing rules, always make a backup copy of the original rule file before you start making any changes. This will make it easy to restore the default operation should an errant rule change hose things up.
If you want to create your own rules from scratch, add them to the local.rules file. This file is empty but included by default. Make sure to give your own rules a SID (see below) of 1000000 (one million) or higher.
The rule files are text files so you can open them up in any text editor. For example, open one of the rule files with the command:
If you page down you'll see that the individual rules all start with the alert keyword. Quite a few rules have a pound (#) character in front of alert to comment them out to disable them. (You can comment out individual rules in a rule file or you can comment out an entire rule file in Snort's configuration file.)
If you cursor down to a rule and arrow to the right eventually you'll see the SID keyword. Each individual rule has it's own unique SID. As you'll see below, if you ever modify a rule, you'll want to make note of its SID.
Where to learn more - The best of our bookshelves:
Snort IDS and IPS Toolkit covers Snort's operation in depth. You will understand what all the statements in the snort.conf and rule files do and how to modify them to optimize Snort for your environment. They even cover writing your own rules, preprocessors, and plugins. This focus on the "trees" does not exclude a look at the "forest" however. The book starts out discussing IDSs in general, their benefits and limitations, and how they fit into a larger security framework. It also covers 3rd party Snort utilities like Oinkmaster.
Just like updating your virus signatures, you'll want to make sure your Snort signatures are up-to-date. Snort's rule updates are called VRT rules (written by Snort's Vulnerability Research Team). In order to download the updates you need to register at www.snort.org to get your free oinkcode. (When you register you get a Web site login and once you log in there's a "Get Code" button near the bottom of your account page.) This code allows you to download rules after a 30-day hold period. You can also choose the higher-level, pay-for subscription service option if you want to be able to get the rules without the 30-day waiting period.
Luckily, Andreas Ostling helps us out with pulling down rule updates. Andreas wrote Oinkmaster which is a Perl script offering a lot of options. Oinkmaster got installed automatically when we installed Snort so all we need to do is update the configuration file and set up a cron job to run it.
Open the Oinkmaster configuration file with the command:
This configuration file is a little out of date, referring only up to Snort 2.2 being the current version. Snort has also changed their download path. Comment out the url line for 2.2 by putting a pound (#) character in front of it and add the following line beneath it:
url = http://www.snort.org/pub-bin/oinkmaster.cgi/oinkcode/snortrules-snapshot-2.7.tar.gz
If you look further down in the file you'll see skipfile statements, one of which is for the local.rules file (which is why this is where you want to put your own rules). Any rule or configuration file specified in a skipfile statement will not be touched by Oinkmaster.
Even further down in the file you'll see sections for modifysid and disablesid statements which is what you'll need to use to preserve any rule changes through updates. It may be easier just to disable the rule in the rules file, copy it over to local.rules and make your changes there. DON'T FORGET TO CHANGE THE SID!
Exit the editor saving the file and we'll take it out for a spin. Oinkmaster does require that you specify an output directory (where your current rules are located). We can check Oinkmaster's configuration without actually updating our current rule files using the -c option so enter the command:
oinkmaster -o /etc/snort/rules -c
It will download the rules (it may take awhile) and then unpack and process them. A lot of stuff will scroll on your screen but at the end will be a list of new rule files. If you want to use these new rules (once we actually add them) you'll need to add include statements for them in the snort.conf file (not the oinkmaster.conf file). Add the include statements for them and then just comment them out if they seem to generate too many false positives.
This addition of new files is one reason you may not want to automate the updating of the rules using a cron job. You won't see that new rule files were added. If you do add new include statements you'll need to restart Snort so it re-reads the configuration file. (There is no need to restart Snort if you simply update the rules.)
Now lets try updating the rules for real using the above command without the -c option.
oinkmaster -o /etc/snort/rules
If you update the /etc/snort/snort.conf file, restart Snort with the command:
Getting Snort installed and updated is a good start but you'll need to watch for false positives and make any rule changes necessary to minimize them. This is the process of "tuning" Snort for your environment. While there are a ton of rules contained in all those rule files, finding a rule is not all that hard. For example, a rule that's a common cause of false positives is the "L3retriever ping" rule.
(Layer 3Networks offers a utility called Retriever.) We can find which rule file(s) contain this rule with the command:
grep retriever /etc/snort/rules/*
The command output shows that the text string "retriever" is in two rule files, "L3retriever ping" is in the icmp.rules file and "L3retriever HTTP Probe" is in the web-misc.rules file. We open the icmp.rules file with the command:
and we can see that the "L3retriever ping" rule is the second one listed. We can disable this rule simply by placing a pound sign character (#) in front of it (and then restarting Snort).
Naturally, you'll want to make sure that the alerts truly are false positives before you disable the rule.
So you finally get your Snort box up and running and tuned to your environment and now you want to start fresh. How do you clear out all the old alerts? Simple. Just click on the Cache & Status link near the bottom of the BASE home page and then click on the Clear Data Tables button.
There is a man page for Snort but there is much more documentation available on the Snort Web site. If you're going to seriously use Snort I'd recommend getting one of several books available on it.
Again, firewalls, DMZs, and IDS systems are not magic bullets. They can detect certain traffic patterns and pass or block traffic within certain parameters. However, they can't tell a legitimate remote user from a hacker. A firewall compliments good OS and application security practices, it doesn't replace them nor can it make up for weaknesses in them.
Did you find this page helpful ?
If so, please help keep this site operating
by using our DVD or book pages.
Site, content, documents, original images Copyright © 2003-2016 Keith Parkansky All rights reserved
Duplication of any portion of this site or the material contained herein without
the express written consent of Keith Parkansky, USA is strictly prohibited.
This site is in no way affiliated with the Debian Project, the debian.org Web site, or
Software In The Public Interest, Inc. No endorsement of this site by the Debian Project
or Software In the Public Interest is expressed or implied. Debian and the Debian logo
are registered trademarks of Software In The Public Interest, Inc. Linux is a registered
trademark of Linus Torvalds. The Tux penguin graphic is the creation of Larry Ewing.
IN NO EVENT WILL KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES BE LIABLE TO ANY PARTY (i) FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR INFORMATION, AND THE LIKE), OR ANY OTHER DAMAGES ARISING IN ANY WAY OUT OF THE AVAILABILITY, USE, RELIANCE ON, OR INABILITY TO USE THE INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED OR TRANSMITTED FILES OR GENERATED COMMUNICATIONS OR DATA EVEN IF KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES SHALL HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE; OR (ii) FOR ANY CLAIM ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN, OR DESTRUCTIVE PROPERTIES OF ANY INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED, TRANSMITTED, OR GENERATED FILES, COMMUNICATIONS, OR DATA. ALL INFORMATION, METHODS, HTML OR COMPUTER CODE IS PROVIDED STRICTLY "AS IS" WITH NO GUARANTY OF ACCURACY AND/OR COMPLETENESS. USE OF THIS SITE CONSTITUTES ACCEPTANCE OF ALL STATED TERMS AND CONDITIONS.