Alpine Linux - Recent changes [en]

How to make a custom ISO image

2012-05-17T16:43:19Z

A rescue CD example:

←Older revision		Revision as of 16:43, 17 May 2012
Line 50:		Line 50:

	Learn apk-tools to find your home-built apk's:		Learn apk-tools to find your home-built apk's:
-	{{Cmd\|echo "~/.cache/~~apks~~" >> /etc/apk/repositories}}	+	{{Cmd\|echo "~/.cache/abuild/" >> /etc/apk/repositories}}
	}}		}}

Cvechecker

2012-05-17T11:39:20Z

←Older revision		Revision as of 11:39, 17 May 2012
Line 92:		Line 92:

	I set % because the DB and the users should allow access from other hosts. You can restrict this to allow only your domain.		I set % because the DB and the users should allow access from other hosts. You can restrict this to allow only your domain.
		+
		+	You have two way to create tables into DB:
		+
		+	=== Via .sql script ===

	Login as cvechecker into mysql:		Login as cvechecker into mysql:
Line 101:		Line 105:
	Now, we should configure cvechecker to use mysql then populate the DB with cve entries.		Now, we should configure cvechecker to use mysql then populate the DB with cve entries.

		+	=== Via cvechecker ===
		+
		+	After you configured the DB, you can create tables with:
		+
		+	cvechecker -i
		+
		+	But in order to make it works, you have to configure DB settings in cvechecker.conf.
	According with our settings, /etc/cvechecker.conf would looks like:		According with our settings, /etc/cvechecker.conf would looks like:

Alpine security

2012-05-16T22:08:07Z

Reconnaissance:

←Older revision		Revision as of 22:08, 16 May 2012
Line 173:		Line 173:
	! URL		! URL
	\|-		\|-
-	\| ~~arpon~~	+	\| arpalert
	\| Monitor ARP changes in ethernet networks		\| Monitor ARP changes in ethernet networks
	\| http://www.arpalert.org		\| http://www.arpalert.org
	\|-		\|-
-	\| ~~arpalert~~	+	\| arpon
	\| ARP handler inspection		\| ARP handler inspection
	\| http://arpon.sourceforge.net/		\| http://arpon.sourceforge.net/

Development using git:Developer repositories

2012-05-16T20:24:38Z

add how to deal with pull rejects

←Older revision		Revision as of 20:24, 16 May 2012
(4 intermediate revisions not shown)
Line 1:		Line 1:
-	Some git repositories of Alpine developer are hosted at [http://git.alpinelinux.org/ git.alpinelinux.org].	+	Some git repositories of Alpine developer are hosted at [http://git.alpinelinux.org/ git.alpinelinux.org]. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access, ''integration managers'', can review and pull from this or can choose to reject if the changes needs more fixing.
		+
		+	The git repos are to be used when there are many changes (more than 3) that need no or very little review. If comments are requested or if there are doubts, then its better to use ''git send-email''. It might also be better to use ''git send-email'' for single commits.

	== Git Push (Distributed Workflows) ==		== Git Push (Distributed Workflows) ==
-	If working with [http://book.git-scm.com/3_distributed_workflows.html Distributed Workflows] you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main ~~developer~~ ''(who ~~has~~ write access to public repository~~)''~~ 'pulls' you changes from your ~~publically~~ accessed repository into the public repository.	+	When working with [http://book.git-scm.com/3_distributed_workflows.html Distributed Workflows] you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main developeres or ''integration managers'' who have write access to public repository, 'pulls' you changes from your public accessed repository into the blessed official public repository.

-	To make it easier for you to work, you can configure 'git push' to push your work to your ~~publically accessible~~ repository ''('git pull' would still pull from ~~same~~ repository as you cloned from)''.	+	To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).
	{{cmd\|cd /your/private/repo/where/you/work/reponame		{{cmd\|cd /your/private/repo/where/you/work/reponame
	git config remote.origin.pushurl "ssh://user@dev.alpinelinux/home/user/cgit/reponame.git"}}		git config remote.origin.pushurl "ssh://user@dev.alpinelinux/home/user/cgit/reponame.git"}}
-	Now 'git pull' pulls the ~~public~~ repository and 'git push' pushes to '''your''' public repository.	+	Now 'git pull' pulls the official, blessed, repository and 'git push' pushes to '''your''' public developer repository.
	{{Note\|The path where you want to push to should first be prepared with {{cmd\|git clone --bare ...}} as described below in section 'Upload the new project'}}		{{Note\|The path where you want to push to should first be prepared with {{cmd\|git clone --bare ...}} as described below in section 'Upload the new project'}}
		+
		+	== Requesting a pull from developer repo to official ==
		+	Before asking for merging the developer repo into the official make sure that:
		+	# All modified packages builds
		+	# The commit history looks nice. You can use the [http://git.alpinelinux.org/cgit cgit interface] for this. It is a goal that it should be easy to revert single commits in case problems should appear in future so avoid changing multiple packages with single commits.
		+
		+	Before asking for a pull, rebase your public repo with the official repo. This is done with:
		+	{{Cmd\|git pull --rebase
		+	git push}}
		+
		+	If there have been changes in official repo that conflicts with your work, then you have to resolve those conflicts. And maybe redo or drop some of your commits.
		+
		+	You can ask directly on IRC #alpine-devel or by sending an email to alpine-devel mailing list. Please include the git url (eg. git://git.alpinelinux.org/user/aports.git) that can easily be copied and pasted and please also mention ''why'' the merge is needed. This explanation is meant to be copied and pasted in the merge commit.
		+
		+	Example request on IRC:
		+	<pre>
		+	please pull git://git.alpinelinux.org/ncopa/aports
		+	It includes a new python application pyfoo with all its dependencies.
		+	</pre>
		+
		+	Example email:
		+	<pre>
		+	Subject: please pull git://git.alpinelinux.org/ncopa/aports
		+
		+	The libfoo was upgraded to 2.0. This upgrade breaks ABI so all packages linking
		+	to libfoo was rebuilt. The rebuilt packages was:
		+	- libbar
		+	- bazapp
		+	- bar-utils
		+
		+	</pre>
		+
		+	== Dealing with pull rejects ==
		+	If the pull was rejected for some reason or you need change things, then you can do an interactive reabase.
		+	{{Cmd\|git rebase --interactive}}
		+	This will let you go thru all you commits inteactively, fix up commits and/or commit messages (aka --ammend), merge commits etc. It might be the ''integration manager'' will see what you are trying to fix and just fix it there and then. In that case you might need drop your own commit. This can also be done with ''git rebase''.
		+
		+	When the needed changes have been done you again push to your public developer repo (and as always you ''git pull --rebase'' before pushing), but since the history have changed due to the rebase git might give you an error message when pushing. As long no-one else have cloned/pulled your repo, it should safe to use --force option.
		+	{{Cmd\|git push --force}}
		+	Note that this will overwrite the changes and history on your public repo so make sure that your local work clone has all the commits that should be there. (use git log to verify).
		+
		+	This also means that only the ''integration managers'' should pull from the developers repo. All other developers should pull from the blessed repository. (In theory multiple developers can work on a bigger subproject but then one of the developers should work as a ''lieutenant'' in the [http://git-scm.com/book/ch5-1.html#Dictator-and-Lieutenants-Workflow dictator and lieutenants workflow].)

	[[Category:Development]]		[[Category:Development]]
	[[Category:Git]]		[[Category:Git]]

Alpine Wall User's Guide

2012-05-16T18:59:15Z

Translating Policy Files to Firewall Configuration Files:

Alpine Wall

2012-05-16T18:41:39Z

Implementation Considerations:

Tutorials and Howtos

2012-05-16T18:09:08Z

Networking: add bonging and vlan links

←Older revision		Revision as of 18:09, 16 May 2012
Line 35:		Line 35:

	* [[Configure Networking]]		* [[Configure Networking]]
		+	* [[Bonding]]
		+	* [[Vlan]]
	* [[Connecting to a wireless access point]]		* [[Connecting to a wireless access point]]
	* [[How to configure static routes]]		* [[How to configure static routes]]

Awk

2012-05-16T16:15:01Z

Built-in filenames and variables: work-in-progress

←Older revision		Revision as of 16:15, 16 May 2012
Line 512:		Line 512:
	</nowiki></div>		</nowiki></div>

-	=== Built-in filenames ~~and~~ variables ===	+	=== Built-in filenames ===
		+
		+	Only gawk handles these filenames internally:
		+
		+	* <code>"/dev/tty"</code>
		+	* <code>"/dev/stdin"</code>
		+	* <code>"/dev/stdout"</code>
		+	* <code>"/dev/stderr"</code>
		+	* <code>"/dev/fd/<var>n</var>"</code>
		+
		+	but in many Unix systems they're available externally anyway. As an alternative to <code>getline < "/dev/stdin"</code>, you can also use <code>getline < "-"</code>. As an alternative to <code>print ... > "/dev/stderr"</code>, you can also use: <code>print ... \| "cat 1>&2"</code>.
		+
		+	=== Built-in variables ===
	{{Draft\|}}		{{Draft\|}}

-	~~<div style="white-space:pre~~; ~~font-family~~:~~monospace;"><nowiki>~~	+	; ENVIRON
		+	: This is an associative array holding the current environment variables. The array is mutable, but POSIX does not specify whether changes to it must be visible to child processes spawned from awk. (In none of the implementations I checked were such changes visible.)

-	~~# only in gawk~~, ~~though all but /dev/fd/n (n>2)~~ will ~~generally still work~~	+	; ARGC and ARGV
-	"~~/dev/tty"~~	+	: The number of command-line arguments to awk, and an array holding them. ARGV[0] will usually be "awk", and ARGV[1]...ARGV[ARGC-1] will be the arguments. Awk handles empty arguments specially, and also arguments of the form <code><var>var</var>=<var>value</var></code>.
-	~~"/dev/stdin~~", ~~can also use: "~~-"	+
-	~~"/dev/stdout"~~	+
-	~~"/dev/stderr"~~, ~~can~~ also ~~use: \| "cat 1~~>~~&2"~~	+
-	"/~~dev~~/fd/n"	+

		+	: If your script only has a BEGIN block, and no main-loop rules or END block, then awk won't attempt to automatically read or process the ARGV arguments, or stdin, in any way.

-	~~ENVIRON associative array~~ of ~~environment variables~~	+	: You can decrement ARGC; awk then won't process any arguments that have been lost. You can also set <code>ARGV[<var>n</var>] = ""</code>, or alternatively, <code>delete ARGV[<var>n</var>]</code>. Similarly, you can add additional ARGV entries, though if you do so, you need to increment ARGC manually.
-	~~array~~ is mutable, but changes ~~don't~~ affect ~~environment~~ of ~~child processes (POSIX leaves implementation~~-~~dependent)~~	+
		+	: Arguments that awk does process should not refer to directories or nonexisting files (unless you are going to to scan the ARGV list manually and remove such). Some versions of some awk implementations will warn if asked to process a directory; others will raise an error.
		+
		+	; ARGIND
		+	: Indicates which ARGV entry was last processed by awk. This is present only in gawk and BusyBox awk. The variable is mutable; but changes to it have no side-effect in gawk. In BusyBox, changes to it affect which ARGV entry will be processed next, after the current one is finished.
		+
		+	; FILENAME
		+	: Indicates the name of the ARGV entry currently being processed. When stdin is being processed, this will be <code>"-"</code>.
		+
		+
		+
		+
		+
		+
		+
		+	<div style="white-space:pre; font-family:monospace;"><nowiki>

-	~~ARGC Number of arguments on command line~~
-	~~ARGIND 0 when processing stdin (and ARGC=1), 1 when processing ARGV[1], ...~~
-	~~only in gawk and BusyBox; in BusyBox, mutating this affects which file is read next~~
-	~~ARGV An array from 0...ARGC-1 containing the command-line arguments~~
-	~~Entries of form "var=value" handled specially, entries of form "" skipped~~
-	~~Entries that are directories: implementations and versions differ in whether they'll warn/error (gawk --traditional will error)~~
-	~~You can: decrement ARGC or set ARGV[...]="" or delete ARGV[...] to suppress argument processing~~
-	~~You can: append to ARGV and increment ARGC, then argument will be processed later~~

	ERRNO In gawk and BusyBox, contains string error message after getline or close fails		ERRNO In gawk and BusyBox, contains string error message after getline or close fails
-	~~FILENAME Current filename~~

	NR Number of current record		NR Number of current record

Cvechecker

2012-05-16T13:49:49Z

New page

{{Draft}}

= How to check Alpine Security with CVEChecker =

== How Does it works ==

From the homepage of cvechecker: http://cvechecker.sourceforge.net/

cvechecker is an useful tool which helps to compare packeges installed in your distribution with the Common Vulnerabilities Exposure.
Is not a bullet-proof method and you will most likely have many false positives (vulnerability is fixed with a revision-release, but the tool isn’t able to detect the revision itself),
yet it is still better than nothing.
The idea is to automatize security check. But, clearly, this is not (and must not be) the only way to check security.
With the proper reporting in place, you are immediately warned when a new CVE has been released that might match your system.
You can then take the appropriate steps (acknowledge report, verify incident, fix package or mark as false positive).
Those are the steps:
- pull in the latest CVE entries as well as software/version detection rules (Adminsitrative task only)
- generate a list of files to scan
- gather installed software/version information
- output which CVE entries might affect your system
- generate a report informing you about the CVE entries

== Installation ==

cvechecker is available in edge main repo. If you are running a stable version of alpine, you can add the package from edge in this way:

apk update -X http://rsync.alpinelinux.org/alpine/edge/main && apk add -X http://rsync.alpinelinux.org/alpine/edge/main cvechecker

== Configuration with sqlite ==

CVEChecker's installation scripts create an user and a group, both called "cvechecker", in order to have a user with minimum privileges to run cvechecker.
In this folder cvechecker will creates the database (according with the cvechecker.conf, we use sqlite3. But also mysql is supported. This could be useful if you want to share only one DB with many routers/servers running Alpine)

Before use cvechecker you should configure cvechecker to use sqlite, then populate the DB with cve entries.
According with our settings, /etc/cvechecker.conf would looks like:

# Generic settings
#
dbtype = "sqlite";
#dbtype="mysql";
cvecache = "/var/cvechecker/cache";
datadir = "/usr/share/cvechecker";
stringcmd = "/usr/bin/strings -n 3 '@file@'";
version_url = "http://cvechecker.svn.sourceforge.net/viewvc/cvechecker/versions.dat";
#userkey = "servertag";
#
# For Sqlite3
#
sqlite3: {
localdb = "/var/cvechecker/local";
globaldb = "/var/cvechecker/global.db";
};
#
# For MySQL
#
mysql: {
dbname = "cvechecker";
dbuser = "cvechecker";
dbpass = "cvecheckpass";
dbhost = "$IPADDRESS_OF_MYSQL_SERVER";
};

Now, you can initialize the DB with:

cvechecker -i

DB is ready.
Now, we should configure cvechecker to use mysql then populate the DB with cve entries.

== Configuration with MySQL ==

MySQL is another backend that cvechecker is able to use. Could be useful if you have several cvechecker installed in your network. In that way, you have only one "repository" of CVEs that needs to be updated.

apk add mysql mysql-client

/etc/init.d/mysql setup

/etc/init.d/mysql start && rc-update add mysql default

/usr/bin/mysqladmin -u root password 'new-password'

create a db user for cvechecker:

mysql -u root -p
mysql>CREATE DATABASE cvechecker;
mysql>CREATE USER 'cvechecker'@'%' IDENTIFIED BY 'cvecheckpass';
mysql>GRANT ALL ON cvechecker.* TO 'cvechecker'@'localhost';
mysql>GRANT ALL ON cvechecker.* TO 'cvechecker'@'%';
mysql>FLUSH PRIVILEGES;

I set % because the DB and the users should allow access from other hosts. You can restrict this to allow only your domain.

Login as cvechecker into mysql:

mysql -D cvechecker -u cvechecker -p
mysql>source /usr/share/cvechecker/mysql_cvechecker.sql;

DB is ready.
Now, we should configure cvechecker to use mysql then populate the DB with cve entries.

According with our settings, /etc/cvechecker.conf would looks like:

# Generic settings
#
#dbtype = "sqlite";
dbtype="mysql";
cvecache = "/var/cvechecker/cache";
datadir = "/usr/share/cvechecker";
stringcmd = "/usr/bin/strings -n 3 '@file@'";
version_url = "http://cvechecker.svn.sourceforge.net/viewvc/cvechecker/versions.dat";
#userkey = "servertag";
#
# For Sqlite3
#
sqlite3: {
localdb = "/var/cvechecker/local";
globaldb = "/var/cvechecker/global.db";
};
#
# For MySQL
#
mysql: {
dbname = "cvechecker";
dbuser = "cvechecker";
dbpass = "cvecheckpass";
dbhost = "$IPADDRESS_OF_MYSQL_SERVER";
};

'''NOTE:'''
Running cvechecker -i (initialize database) it removes ALL entries in the DB.

=== Using CVEChecker ===

After the db is created, you have to pull the necessary data from the Internet:

pullcves pull

According with the manual, "This will take a very long time, so please be patient (loading over half a million CVE entries in a database is a time consuming - but one-time - activity).
Future pulls will not take this much time as they will not redownload the CVE entries from all previous years (unless you ask it to)."

(If you're behind a proxy, you should set it from env variable or with wget.rc)

Could be useful to crontab this task, maybe every day. Become the cvecheker user and run "crontab -e".
Insert the following to run pullcves every day at 5:00 AM

* 5 * * * /usr/bin/pullcves pull

Now, make a list of executables file as well as /proc/version and allows cvechecker to verify if there are kernel-related CVE entries for your Linux kernel and software installed.

find / -type f -perm -o+x > /tmp/cvecheck.tmp
cat /proc/version >> /tmp/cvecheck.tmp

Now, in /tmp/cvecheck.tmp you'll have all the binaries of your system with their version.
Check if there are cve with the following:

cvechecker -b /tmp/cvecheck.tmp

If you want, you can create a report with the entries (if they are found):

cvechecker -r

Simple script that helps to do it automatically. Copy and past it, save it as run_cvecheck.sh and give it exec permissions.

#!/bin/sh
tempfile=/tmp/cvecheck.tmp
EMAILADMIN=<%EMAIL ADDRESS USED FOR THIS TASK%>
find / -type f -perm -o+x > $tempfile
cat /proc/version >> $tempfile
cvechecker -b $tempfile > /dev/null 2>&1 # Run cvechecker against the software list
cvechecker -r > $tempfile > /dev/null 2>&1 # Create a report
if [ -s "$tempfile" ] ; then # If exists and non-zero, send it via email
mail $EMAILADMIN -s "CVE Checker" < $tempfile
fi ;
rm $tempfile

In order to make the last rows sent via email, you should configure an smtp server. Widely used is ssmtp.

Coul be a good idea run this script as cronjob.

So, you can do the same you did with pullcves: become the cvecheker user and run "crontab -e".

* 6 * * * /var/cvechecker/run_cvecheck.sh

That's all. Enjoy Alpine!

[[Category:Security]]

Setting up lm sensors

2012-05-12T15:27:48Z

←Older revision		Revision as of 15:27, 12 May 2012
Line 2:		Line 2:

	Install the neccessary packages. You will need perl to run the sensors-detect script.		Install the neccessary packages. You will need perl to run the sensors-detect script.
-	{{Cmd\|apk_add lm_sensors perl}}	+	{{Cmd\|apk_add lm_sensors lm_sensors-detect perl}}

	Load the i2c-dev module:		Load the i2c-dev module:
Line 13:		Line 13:
	{{Cmd\|sensors-detect}}		{{Cmd\|sensors-detect}}

-	~~On the question to scan ISA bus and Super I/O~~ sensors~~, select~~ "no"~~. Grsec~~ will not allow you to access /proc/port. ~~On all other questions select~~ the default.	+	There are multiple types of sensors that you must skip scanning for (answer "no" to the prompt) because grsec will not allow you to access /proc/port. If you encounter an error that says something like "/dev/port: no such file..", re-run the script and answer "no" to that question on the next attempt. Examples of ones that you must enter "no" for: ISA bus, other Super I/O sensors, and IPMI.
		+
		+	Be sure to enter "yes" (non-default) for the question "Do you want to generate /etc/conf.d/lm_sensors?"

	You will not need perl anymore. Remove it before you forget.		You will not need perl anymore. Remove it before you forget.
-	{{Cmd\|~~apk_delete~~ perl}}	+	{{Cmd\|apk_del lm_sensors-detect perl}}

	Make services start during next reboot.		Make services start during next reboot.
-	{{Cmd\|~~rc_add~~ -k lm_sensors sensord}}	+	{{Cmd\|rc-update add lm_sensors default
		+	rc-update add sensord default}}

	Start services:		Start services:
	{{Cmd\|/etc/init.d/lm_sensors start && /etc/init.d/sensord start}}		{{Cmd\|/etc/init.d/lm_sensors start && /etc/init.d/sensord start}}

-	~~Save config~~ using {{Cmd\|lbu commit}}.	+	Don't forget to save your new server configuration using {{Cmd\|lbu commit}}.

	[[Category:Monitoring]]		[[Category:Monitoring]]

StatusNet

2012-05-11T10:56:17Z

Installing StatusNet:

←Older revision		Revision as of 10:56, 11 May 2012
Line 50:		Line 50:

	{{Cmd\|cd /usr/share/webapps/		{{Cmd\|cd /usr/share/webapps/
-	http://status.net/statusnet-1.0.1.tar.gz}}	+	wget http://status.net/statusnet-1.0.1.tar.gz}}

	Unpack		Unpack

User:Zico

2012-05-11T10:55:39Z

New user account

←Older revision		Revision as of 18:59, 16 May 2012
(7 intermediate revisions not shown)
Line 11:		Line 11:
	located in <tt>/usr/share/awall/optional</tt>. These are optional		located in <tt>/usr/share/awall/optional</tt>. These are optional
	policies, which can be enabled on need basis. Such symbolic links are		policies, which can be enabled on need basis. Such symbolic links are
-	easily created and destroyed using the <tt>awall enable</tt> and	+	easily created and destroyed using the <tt>awall enable</tt> and
	<tt>awall disable</tt> commands. <tt>awall list</tt> shows which		<tt>awall disable</tt> commands. <tt>awall list</tt> shows which
	optional policies are enabled and disabled. The command also prints		optional policies are enabled and disabled. The command also prints
Line 86:		Line 86:
	the scope of the service definition may be constrained by defining an		the scope of the service definition may be constrained by defining an
	attribute named '''port''', which is a list of TCP or UDP port		attribute named '''port''', which is a list of TCP or UDP port
-	numbers. If the protocol is '''icmp''' or '''icmpv6''', an analogous	+	numbers. If the protocol is '''icmp''' or '''icmpv6''', an analogous
	'''icmp-type''' attribute may be used. In addition, the scope of the		'''icmp-type''' attribute may be used. In addition, the scope of the
	rule is also automatically limited to IPv4 or IPv6, respectively.		rule is also automatically limited to IPv4 or IPv6, respectively.
Line 92:		Line 92:
	=== Zones ===		=== Zones ===

-	A ''zone'' represents a set of network hosts. A top-level attribute	+	A ''zone'' represents a set of network hosts. A top-level attribute
	'''zone''' is a dictionary that maps zone names to zone objects. A		'''zone''' is a dictionary that maps zone names to zone objects. A
	zone object has an attribute named '''iface''', '''addr''', or		zone object has an attribute named '''iface''', '''addr''', or
Line 104:		Line 104:
	Rule objects contain two attributes, '''in''' and '''out''', which are		Rule objects contain two attributes, '''in''' and '''out''', which are
	lists of zone names. These attributes control whether a packet matches		lists of zone names. These attributes control whether a packet matches
-	the rule or not. If a particular zone is referenced by the '''in'''	+	the rule or not. If a particular zone is referenced by the '''in'''
	attribute, the rule applies to packets whose ingress interface and		attribute, the rule applies to packets whose ingress interface and
	source address are covered by the zone definition. Correspondingly, if		source address are covered by the zone definition. Correspondingly, if
Line 114:		Line 114:
	=== Rules ===		=== Rules ===

-	There are three types of rule objects: ''policies'', ''filters'', and	+	There are three types of rule objects: ''policies'', ''filters'', and
	''NAT rules''.		''NAT rules''.

Line 177:		Line 177:
	objects. The precedence rules are similar to those of policy objects.		objects. The precedence rules are similar to those of policy objects.

-	In addition to the common rule attributes, filter objects can have a	+	In addition to the common rule attributes, filter objects can have a
	'''service''' attribute constraining the scope to specific services		'''service''' attribute constraining the scope to specific services
	only. This attribute is a list of service names, referring to the		only. This attribute is a list of service names, referring to the
Line 187:		Line 187:
	attributes are limit objects that have two attributes: '''count''' and		attributes are limit objects that have two attributes: '''count''' and
	'''interval'''. '''count''' specifies how many new connections or		'''interval'''. '''count''' specifies how many new connections or
-	packets are allowed within the time frame specified by '''interval'''	+	packets are allowed within the time frame specified by '''interval'''
	(in seconds). The '''logdrop''' action is applied to the packets		(in seconds). The '''logdrop''' action is applied to the packets
	exceeding the limit.		exceeding the limit.
Line 232:		Line 232:
	policy files. The top-level attribute '''ipset''' is a dictionary, the		policy files. The top-level attribute '''ipset''' is a dictionary, the
	keys of which are IP set names. The values are IP set objects, which		keys of which are IP set names. The values are IP set objects, which
-	have two mandatory attributes. The attribute named '''type'''	+	have two mandatory attributes. The attribute named '''type'''
-	corresponds to the type argument of the <tt>ipset create</tt>	+	corresponds to the type argument of the <tt>ipset create</tt>
	command. '''family''' specifies whether the set is for IPv4 or IPv6		command. '''family''' specifies whether the set is for IPv4 or IPv6
	addresses, and the possible values are '''inet''' and '''inet6''',		addresses, and the possible values are '''inet''' and '''inet6''',
Line 250:		Line 250:
	Specifying the output directory allows testing awall policies without		Specifying the output directory allows testing awall policies without
	overwriting the current iptables and ipset configuration files. By		overwriting the current iptables and ipset configuration files. By
-	default, awall generates the configuration to <tt>/etc/iptables</tt>	+	default, awall generates the configuration to <tt>/etc/iptables</tt>
	and <tt>/etc/ipset.d</tt>, which are read by the init scripts.		and <tt>/etc/ipset.d</tt>, which are read by the init scripts.

←Older revision		Revision as of 18:41, 16 May 2012
(One intermediate revision not shown)
Line 73:		Line 73:

	Subnets in zone definitions can be declared using IPv4/IPv6 addresses		Subnets in zone definitions can be declared using IPv4/IPv6 addresses
-	(CIDR notation), domain names, or as references to	+	(CIDR notation), domain names, or as references to
	[http://ipset.netfilter.org/ipset.man.html ipsets]. A domain name can		[http://ipset.netfilter.org/ipset.man.html ipsets]. A domain name can
	resolve to one or more IP addresses. The referred ipsets may be		resolve to one or more IP addresses. The referred ipsets may be
Line 80:		Line 80:
	If a packet with source address ''a'' arrives on interface ''i'', it		If a packet with source address ''a'' arrives on interface ''i'', it
	is considered to originate from zone ''Z = (I, S)'' (where ''I'' is		is considered to originate from zone ''Z = (I, S)'' (where ''I'' is
-	the set of interfaces and ''S'' is the set of subnets) if and only if	+	the set of interfaces and ''S'' is the set of subnets) if and only if
	''I'' includes ''i'', and ''a'' belongs to any subnet of ''S''. In		''I'' includes ''i'', and ''a'' belongs to any subnet of ''S''. In
-	zone definitions, ''I'' would default to the set of all interfaces and	+	zone definitions, ''I'' would default to the set of all interfaces and
	''S'' to {0.0.0.0/0, ::}. The destination zone would be defined in a		''S'' to {0.0.0.0/0, ::}. The destination zone would be defined in a
	similar way based on the packet's destination address and interface.		similar way based on the packet's destination address and interface.
Line 100:		Line 100:
	requirements on the language, e.g. support for complex data types. If		requirements on the language, e.g. support for complex data types. If
	we select this approach and model the data using XML, we could use XML		we select this approach and model the data using XML, we could use XML
-	Schema as the basis. There is also an (expired) Internet Draft on	+	Schema as the basis. There is also an (expired) Internet Draft on
	[http://tools.ietf.org/html/draft-zyp-json-schema-03 JSON Schema], but		[http://tools.ietf.org/html/draft-zyp-json-schema-03 JSON Schema], but
	there seems to be no existing validator implementation in C or Lua.		there seems to be no existing validator implementation in C or Lua.