Bug 256410
| Summary: | pf: Add pf_fallback_rules option | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Thomas Steen Rasmussen / Tykling <thomas> |
| Component: | misc | Assignee: | freebsd-pf (Nobody) <pf> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | 000.fbsd, ceri, kp, pi, portmaster |
| Priority: | --- | ||
| Version: | Unspecified | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
| Attachments: | |||
I can see I made a few copy/paste errors in the examples above, but I think the meaning is still intact. The most significant one is that it shows the wrong filename in the warn() output in the second to last test. The attached patch uses the variable $pf_rules for the message, but the warn() call was hardcoded to /etc/pf.conf at first. Also, I forgot to mention, this work was sponsored by semaphor.dk - if such a thing is suitable to mention in a possible commit message then please do so :) Thanks! Oh! And of course I could build custom kernels with PF_DEFAULT_TO_DROP for the firewalls, but my proposed solution is both more flexible, and more importantly it works in GENERIC :) (In reply to Thomas Steen Rasmussen / Tykling from comment #2) I was going to point that one out, yes. Your point stands though, and also I have vague memories of there being subtle issues with PF_DEFAULT_TO_DROP. As for the sponsorship, it's common practice to add 'Sponsored by' tags to the commit message. Can you propose a full commit message? I'll try to review in depth in the next few days, but at first glance this looks like a sane thing to do. OK I feel bad even saying this, as you've clearly put a great deal of work into this -- probably more into the explanation that the patch. ;-) But I ran into a similar situation to the one you describe, and it occurred to me that I could simply create an /etc/pfsafe.conf with similar contents to the one you describe and simply load it in the event of a /etc/pf.conf failure. Isn't that all that's really happening here? I guess I don't really have strong opposition or opinion against your proposal. I'm only somewhat concerned about the added complexity that an added variable brings and the potential failures that could arise down the line. In any event, thanks for taking the time to create the convenient feature. :-) --Chris Wouldn't it be better to use pf_check() befor loading ruleset in pf_start() and then decide if "default" ruleset should be loaded? Many rc script do check for syntax errors in config files before loading / running the daemon (Apache, Lighttpd, Nginx...) If will be useful to run this check before service pf start / reload / restart commands in general. Ad if there can be any default rule(s) to load if something failed then it will be good to have some option to load rules from file not just the one line from variable too. On some remote boxes it is better to left SSH (or somethng else) open if loading of rules failed than block everything. Something like this comes to my mind: if check of pf.conf failed check if /etc/pf.conf.default is a file & try to load it if pf.conf.default does not exist, use one line rule from pf_default_rules variable Of course pf.conf.default can be named differently, or can by /etc/defaults/pf.conf etc. Hello Kristof :) Proposed commit message: ----------------------------------------------------------------------- pf: Support loading small default pf ruleset in case of invalid pf.conf using pf_default_rules and pf_default_rules_enable When no pf rules are loaded pf will pass/allow all traffic if the kernel is compiled without PF_DEFAULT_TO_DROP, which is the case in GENERIC. This commit introduces a "pf default rules" concept to minimise the impact if a typo in pf.conf makes loading the firewall rules impossible on boot. The change checks the exit code of the $pf_program (pfctl) command when loading pf.conf inside pf_start() in /etc/rc.d/pf. After this commit, if the exit code is 1 and pf_default_rules_enable is set to YES, then the rules defined in $pf_default_rules are loaded instead. $pf_default_rules defaults to a single rule: "block drop log all". This commit also introduces new warn() calls when /etc/rc.d/pf fails to load the pf ruleset in pf_start(). If $pf_default_rules_enable is NO (which is the default) then the following messages are logged: /etc/rc.d/pf: WARNING: Unable to load pf.conf, and pf_default_rules_enable is NO. /etc/rc.d/pf: WARNING: No pf rules are loaded, this means all traffic is permitted. If pf_default_rules_enable is YES then the following messages are logged, and the rules defined in $pf_default_rules are loaded: /etc/rc.d/pf: WARNING: Unable to load pf.conf, and pf_default_rules_enable is set to YES. /etc/rc.d/pf: WARNING: Loading pf_default_rules: block drop log all pf_default_rules can include multiple rules, for example to permit traffic on a management interface. Seperate multiple rules with \n: $ sudo sysrc pf_default_rules pf_default_rules: block drop log all\npass quick on em0 $ The $pf_default_rules and $pf_default_rules_enable variables are defined in /etc/defaults/rc.conf with the following lines, preserving the existing functionality (apart from the new log messages): pf_default_rules_enable="NO" # fallback to $pf_default_rules if loading ruleset fails pf_default_rules="block drop log all" # block and drop everything if loading pf ruleset fails PR: 256410 Reported by: Thomas Steen Rasmussen Reviewed by: kp@ Sponsored by: semaphor.dk ----------------------------------------------------------------------- Feel free to edit as you see fit :) Thank you! (In reply to Chris Hutchinson from comment #4) Don't feel bad :) Your point about having a backup/safe/default pf.conf is certaintly valid. That would not have helped here though, as there is no mechanism (without this patch) to load that alternative ruleset if the primary one fails. It would have to be done manually, which would require that you know when this happens - and if you know about a typo you would probably just fix it :) The code to automatically load an alternate ruleset from a file would look a lot like the code in my proposed patch. I opted for using an rc variable over a file to avoid having an extra file in the tree which will very rarely be used. Ideally the patch could be adapted to support loading from a file if one exists, and otherwise falling back to the rc variable. (In reply to Miroslav Lachman from comment #5) pf_check() is actually defined, just not used, pf_resync() also checks the exit code for some reason, I am not sure why. The patch could be adapted to run pf_check() instead of checking the exit code. Your point about supporting a rule file is also valid, see my other comment. (In reply to Thomas Steen Rasmussen / Tykling from comment #7) > Ideally the patch could be adapted to support loading from > a file if one exists, and otherwise falling back to the rc variable. +1 on this. That would be my _preferred_ course of action in the event of failure. IMHO it should be up to the administrator as to _what_ ruleset should be enacted in the event of failure. Pretty much impossible to know what circumstances pf(4) are implimented for in any given situation. To be clear; I'm _not_ objecting to your proposed feature. :-) I'm simply attempting to _enhance_ it to DTRT. ;-) --Chris Alright, I've attached an updated version of the patch which checks for the existence of $pf_default_rules_file (which defaults to /etc/pf-default.conf in /etc/defaults/rc.conf) and if the file exists it loads it, and if not it loads the rules in $pf_default_rules. Example: [tykling@nuc2 ~]$ sudo service pf restart Enabling pfno IP address found for foo /etc/pf-typo.conf:2: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded /etc/rc.d/pf: WARNING: Unable to load /etc/pf-typo.conf and pf_default_rules_enable is set to YES. /etc/rc.d/pf: WARNING: pf_default_rules_file /etc/pf-default.conf not found, looading pf_default_rules: block drop log all . [tykling@nuc2 ~]$ After setting pf_default_rules_file to an existing file: [tykling@nuc2 ~]$ sudo sysrc pf_default_rules_file="/etc/pf.conf" pf_default_rules_file: /etc/pf-default.conf -> /etc/pf.conf [tykling@nuc2 ~]$ sudo service pf restart Enabling pfno IP address found for foo /etc/pf-typo.conf:2: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded /etc/rc.d/pf: WARNING: Unable to load /etc/pf-typo.conf and pf_default_rules_enable is set to YES. /etc/rc.d/pf: WARNING: Loading pf_default_rules_file: /etc/pf.conf . [tykling@nuc2 ~]$ Created attachment 225716 [details]
Updated patch with support for pf_default_rules_file
Proposed updated commit message: ----------------------------------------------------------------------- pf: Support loading default pf ruleset in case of invalid pf.conf using pf_default_rules_enable, pf_default_rules and pf_default_rules_file. When no pf rules are loaded pf will pass/allow all traffic, if the kernel is compiled without PF_DEFAULT_TO_DROP, which is the case in GENERIC. This commit introduces a "pf default rules" concept to minimise the impact if a typo in pf.conf makes loading the primary firewall ruleset impossible on boot or pf restart. The new code checks the exit code of the $pf_program (pfctl) command when loading pf.conf inside pf_start() in /etc/rc.d/pf. After this commit, if the exit code is 1 and pf_default_rules_enable is YES, then the default rules are loaded. If the file $pf_default_rules_file exists the rules in it are loaded, otherwise the rules defined in $pf_default_rules are loaded instead. $pf_default_rules defaults to a single rule: "block drop log all", $pf_default_rules_file defaults to the path "/etc/pf-default.conf". This commit also introduces new warn() calls when /etc/rc.d/pf fails to load the pf ruleset in pf_start(). pf_default_rules can include multiple rules, for example to permit traffic on a management interface. Seperate multiple rules with \n: $ sudo sysrc pf_default_rules pf_default_rules: block drop log all\npass quick on em0 $ The $pf_default_rules, $pf_default_rules_file and $pf_default_rules_enable variables are defined in /etc/defaults/rc.conf with the following lines, preserving the existing functionality (apart from the new log messages): pf_default_rules_enable="NO" # fallback to $pf_default_rules if loading ruleset fails pf_default_rules="block drop log all" # block and drop everything if loading pf ruleset fails pf_default_rules_file="/etc/pf-default.conf" # use this file if it exists and loading the primary fails PR: 256410 Reported by: Thomas Steen Rasmussen Reviewed by: kp@ Sponsored by: semaphor.dk ----------------------------------------------------------------------- :) The rc.conf(5) manpage should mention this new feature as well. I am not well versed in man-language but the following sections could be added:
pf_default_rules_enable (bool) Set to "NO" by default. Setting this to "YES" enables loading pf_default_rules_file or pf_default_rules in case of a problem when loading the ruleset in pf_rules.
pf_default_rules_file (str) Path to a pf ruleset to load in case of failure when loading the ruleset in pf_rules (default /etc/pf-default.conf).
pf_default_rules (str) A pf ruleset to load in case of failure when loading the ruleset in pf_rules and pf_default_rules_file is not found. Multiple rules can be seperated with \n (default "block drop log all").
If someone can groff it up (or whatever it needs) I would appreciate it. Thank you :)
+1 on your new patch. WFM :-) Thanks for all your time and work on this, Thomas! --Chris (In reply to Thomas Steen Rasmussen / Tykling from comment #11) I like this approach with loading rules from file or variable. The only thing I am no sure is if the word "default" is the best. I am thinking about something like "fallback" or "safety" or "emergency" for the name of variables and filename. THank you for your work on it! Sorry, but non-default rules shouldn't be called "default". Writing the explanation of that for the docs is going to be hard, and people will have been caught out by the time they are reading it. Can we call it pf_backstop* instead please? There is a typo in the patch, "looading". (In reply to Miroslav Lachman from comment #15) I did consider the name for a bit but settled on "default" since that is the original meaning of the word. A "de-faulted" configuration is one you know to be free from errors. I know the word is thrown around a lot nowadays, but I do believe the word is just right for this usecase. Native english speakers feel free to pitch in here :) Created attachment 225724 [details]
Updated patch with support for pf_default_rules_file and no "looading" typo
New patch without typo
> I did consider the name for a bit but settled on "default" since that is the original meaning of the word.
>
> A "de-faulted" configuration is one you know to be free from errors. I know the word is thrown around a lot nowadays, but I do believe the word is just right for this usecase. Native english speakers feel free to pitch in here :)
I am one :)
Having a setting called "default" in "/etc/default" that is not enabled by default is impossible to document sensibly.
I respectfully disagree. I believe the lines in /etc/defaults/rc.conf and the addition to rc.conf(5) document it well enough. I will leave the final decision to someone else. With my doc hat on, I disagree and would prefer to see it changed. Sorry if this is disappointing. Created attachment 225728 [details]
Updated patch with rename to pf_fallback_rules*
New patch with the feature renamed to pf_fallback_rules.
The rc.conf(5) manpage snippet above should also s/_default_/_fallback_/ and it should be fine:
pf_fallback_rules_enable (bool) Set to "NO" by default. Setting this to "YES" enables loading pf_fallback_rules_file or pf_fallback_rules in case of a problem when loading the ruleset in pf_rules.
pf_fallback_rules_file (str) Path to a pf ruleset to load in case of failure when loading the ruleset in pf_rules (default /etc/pf-fallback.conf).
pf_fallback_rules (str) A pf ruleset to load in case of failure when loading the ruleset in pf_rules and pf_fallback_rules_file is not found. Multiple rules can be seperated with \n (default "block drop log all").
/Thomas
Created attachment 225730 [details]
mdoc for rc.conf.5 changes
Patch for rc.conf.5 (passes -Tlint)
Thanks - mdoc attached. (In reply to Thomas Steen Rasmussen / Tykling from comment #22) I wasn't keen on the use of default either. But kept my mouth shut as I couldn't come great alternative I liked. Your choice of "fallback" was perfect. Thanks! IMHO this pf_fallback_rules_enable (bool) Set to "NO" by default. Setting this to "YES" enables loading pf_fallback_rules_file or pf_fallback_rules in case of a problem when loading the ruleset in pf_rules. should read like this pf_fallback_rules_enable (bool) Set to "NO" by default. Setting this to "YES" enables loading pf_fallback_rules_file or pf_fallback_rules should the ruleset in pf_rules fail. (In reply to Ceri Davies from comment #25) IMHO this pf_fallback_rules_enable (bool) Set to "NO" by default. Setting this to "YES" enables loading pf_fallback_rules_file or pf_fallback_rules in case of a problem when loading the ruleset in pf_rules. should read like this pf_fallback_rules_enable (bool) Set to "NO" by default. Setting this to "YES" enables loading pf_fallback_rules_file or pf_fallback_rules should the ruleset in pf_rules fail. Sorry for double posting. I forgot to tag Ceri@. Created attachment 225774 [details]
Proposed tidy-up
I like the idea overall, but the current patch has a few line length issues, and it's also a bit overly verbose. I've attached a proposed tweak.
(In reply to Kristof Provost from comment #29) Looks good! I like the idea of having it in a seperate function. (In reply to Ceri Davies from comment #25) Thank you! (In reply to Kristof Provost from comment #29) Are there any shell code style guidelines about using non-POSIX "echo -e" vs "printf"? https://github.com/koalaman/shellcheck/wiki/SC3037 (In reply to Miroslav Lachman from comment #32) I'm not aware of any shell script style guide (we should probably have one, but we don't). My view is that these are FreeBSD startup scripts, so it's fine to rely on FreeBSD-specific features of the shell and tools. I've created a review for this change at https://reviews.freebsd.org/D30791 It includes some minor wordsmithing on the commit message, and I've removed what looks like a stray change from the man page update. Thanks Kristof! This might not matter much, but the description in review D30791 uses "pf_default_rules*" rather than "pf_fallback_rules*". The patch itself looks good. /Thomas A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=28f47a199cfd8749ab30a0327b0a3f8977ec2b43 commit 28f47a199cfd8749ab30a0327b0a3f8977ec2b43 Author: Thomas Steen Rasmussen <thomas@gibfest.dk> AuthorDate: 2021-06-16 18:29:06 +0000 Commit: Kristof Provost <kp@FreeBSD.org> CommitDate: 2021-07-08 12:22:04 +0000 pf: fallback if $pf_rules fails to load Support loading a default pf ruleset in case of invalid pf.conf. If no pf rules are loaded pf will pass/allow all traffic, assuming the kernel is compiled without PF_DEFAULT_TO_DROP, as is the case in GENERIC. In other words: if there's a typo in the main pf_rules we would allow all traffic. The new default rules minimise the impact of this. If $pf_program (i.e. pfctl) fails to set $pf_fules and $pf_fallback_rules_enable is YES we will load $pf_fallback_rules_file if set, or $pf_fallback_rules. $pf_fallback_rules can include multiple rules, for example to permit traffic on a management interface. $pf_fallback_rules_enable defaults to "NO", preserving historic behaviour. man page changes by ceri@. PR: 256410 Reviewed by: donner, kp Sponsored by: semaphor.dk Differential Revision: https://reviews.freebsd.org/D30791 libexec/rc/rc.conf | 5 +++++ libexec/rc/rc.d/pf | 19 ++++++++++++++++++- share/man/man5/rc.conf.5 | 38 +++++++++++++++++++++++++++++++++++++- 3 files changed, 60 insertions(+), 2 deletions(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=fae2a8cad398518c473f67fc210206c6dac02610 commit fae2a8cad398518c473f67fc210206c6dac02610 Author: Thomas Steen Rasmussen <thomas@gibfest.dk> AuthorDate: 2021-06-16 18:29:06 +0000 Commit: Kristof Provost <kp@FreeBSD.org> CommitDate: 2022-01-24 20:11:02 +0000 pf: fallback if $pf_rules fails to load Support loading a default pf ruleset in case of invalid pf.conf. If no pf rules are loaded pf will pass/allow all traffic, assuming the kernel is compiled without PF_DEFAULT_TO_DROP, as is the case in GENERIC. In other words: if there's a typo in the main pf_rules we would allow all traffic. The new default rules minimise the impact of this. If $pf_program (i.e. pfctl) fails to set $pf_fules and $pf_fallback_rules_enable is YES we will load $pf_fallback_rules_file if set, or $pf_fallback_rules. $pf_fallback_rules can include multiple rules, for example to permit traffic on a management interface. $pf_fallback_rules_enable defaults to "NO", preserving historic behaviour. man page changes by ceri@. PR: 256410 Reviewed by: donner, kp Sponsored by: semaphor.dk Differential Revision: https://reviews.freebsd.org/D30791 (cherry picked from commit 28f47a199cfd8749ab30a0327b0a3f8977ec2b43) libexec/rc/rc.conf | 5 +++++ libexec/rc/rc.d/pf | 19 ++++++++++++++++++- share/man/man5/rc.conf.5 | 36 ++++++++++++++++++++++++++++++++++++ 3 files changed, 59 insertions(+), 1 deletion(-) This has been MFCed, closing, thanks! |
Created attachment 225540 [details] The patch for /etc/rc.d/pf and /etc/defaults/rc.conf Out of the three firewalls in FreeBSD pf is the only one without a way to make it default to deny everything: - IPFW has "65535 deny ip from any to any" unless IPFIREWALL_DEFAULT_TO_ACCEPT is set. - ipfilter has something called IPFILTER_DEFAULT_BLOCK, I think. I don't really know anything about ipfilter. With pf, if no rules are loaded all traffic is permitted. This can be considered a feature or a problem, recently it was a very big problem in my end. I propose the attached patch for /etc/rc.d/pf and a couple of new rc.conf variables pf_default_rules_enable and pf_default_rules to improve this situation. The patch simply checks the exit code of the pfctl command which loads the pf.conf ruleset, and if the exit code is 1 and pf_default_rules_enable is set to YES, then it loads the rules in pf_default_rules, which defaults to a single rule: "block drop log all". BACKGROUND: A little backstory might help clear up why I think this is a valuable and neccesary change. We (our company) had ended up with a pf.conf with a typo in it. The typo was that the leading "$" sign of a macro was missing. This makes pf treat it as a hostname instead of a macro, so it does a DNS lookup to process the firewall rule. The typo could have been a missing quote or something else too, the central point is the pf.conf was invalid, and it had been missed (humans being human and all that). The server in question was then rebooted, and suddently no firewall rules were loaded, permitting all traffic to the networks behind it, leading to some bad times at the office before it was discovered. In the postmortem clean-up it was determined that since /etc/rc.d/pf had failed to load the ruleset during bootup, and there being no "default block functionality", there was 0 rules loaded so it of course permitted everything. On these particular firewall machines it would have been MUCH better to have a non-functional firewall than a fully open one. YMMV, and the default in my patch is to keep the status quo, of course. With this patch and pf_default_rules_enable set to YES I would have discovered the issue much sooner and with no security incidents, which is vastly preferable in this situation. THE PATCH: Mostly it is just a new "if" block around the pfctl -f call inside pf_start(). I included some warnings (for both cases) while here. The only files touched are /etc/rc.d/pf and /etc/defaults/rc.conf. EXAMPLE: Note: All of these examples are with the attached patch applied. I made two simple pf.conf files where one has small but significant typo: [tykling@nuc2 ~]$ cat /etc/pf.conf foo="192.0.2.42" pass in quick on em0 from any to $foo [tykling@nuc2 ~]$ cat /etc/pf-typo.conf foo="192.0.2.42" pass in quick on em0 from any to foo [tykling@nuc2 ~]$ Note how "foo" is missing the leading $ sign meaning pf interprets it as a hostname, which can't be resolved in this case. First the default behaviour with no changes in rc.conf and a valid ruleset: [tykling@nuc2 ~]$ sudo sysrc pf_default_rules_enable pf_default_rules_enable: NO [tykling@nuc2 ~]$ sudo sysrc pf_default_rules pf_default_rules: block drop log all [tykling@nuc2 ~]$ sysrc pf_rules pf_rules: /etc/pf.conf [tykling@nuc2 ~]$ sudo service pf restart Password: Enabling pf. [tykling@nuc2 ~]$ sudo pfctl -s rules | wc -l 1 [tykling@nuc2 ~]$ sudo pfctl -s rules pass in quick on em0 inet from any to 192.0.2.42 flags S/SA keep state [tykling@nuc2 ~]$ All is well, it loaded the one rule in the ruleset. Now an example with an invalid ruleset, still with the above defaults in place: [tykling@nuc2 ~]$ sudo service pf restart Disabling pf. Enabling pfno IP address found for foo /etc/pf-typo.conf:2: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded /etc/rc.d/pf: WARNING: Unable to load pf.conf, and pf_default_rules_enable is NO. /etc/rc.d/pf: WARNING: No pf rules are loaded, this means all traffic is permitted. . [tykling@nuc2 ~]$ sudo pfctl -s rules [tykling@nuc2 ~]$ The behaviour is the same as always, but a couple of new warn() calls informs the admin about what happened so they might spot it in /var/log/messages. Now the same setup but with the new feature enabled: [tykling@nuc2 ~]$ sudo sysrc pf_default_rules_enable="YES" pf_default_rules_enable: NO -> YES [tykling@nuc2 ~]$ The valid ruleset behaves as always: [tykling@nuc2 ~]$ sudo sysrc pf_rules="/etc/pf.conf" pf_rules: /etc/pf.conf -> /etc/pf.conf [tykling@nuc2 ~]$ sudo service pf restart Disabling pf. Enabling pf. [tykling@nuc2 ~]$ sudo pfctl -s rules | wc -l 1 [tykling@nuc2 ~]$ With the invalid ruleset the pf_default_rules are loaded: [tykling@nuc2 ~]$ sudo sysrc pf_default_rules_enable="YES" pf_default_rules_enable: NO -> YES [tykling@nuc2 ~]$ sudo service pf restart Disabling pf. Enabling pfno IP address found for foo /etc/pf-typo.conf:2: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded /etc/rc.d/pf: WARNING: Unable to load pf.conf, and pf_default_rules_enable is set to YES. /etc/rc.d/pf: WARNING: Loading pf_default_rules: block drop log all . [tykling@nuc2 ~]$ sudo pfctl -s rules block drop log all [tykling@nuc2 ~]$ Say I wanted a way in, a management backdoor in case this happens, I could for example choose to pass traffic on a management interface only: [tykling@nuc2 ~]$ sudo sysrc pf_default_rules pf_default_rules: block drop log all\npass quick on em0 [tykling@nuc2 ~]$ sudo service pf restart Enabling pfno IP address found for foo /etc/pf-typo.conf:2: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded /etc/rc.d/pf: WARNING: Unable to load pf.conf, and pf_default_rules_enable is set to YES. /etc/rc.d/pf: WARNING: Loading pf_default_rules: block drop log all\npass quick on em0 . [tykling@nuc2 ~]$ sudo pfctl -s rules block drop log all pass quick on em0 all flags S/SA keep state [tykling@nuc2 ~]$ I guess that is all. I hope it made sense and that the feature will find its way into FreeBSD. I know I will be running with it locally until such a time. Apologies in advance if I messed up the patch, I don't do this often, and I don't have a phabricator account (yet). Have a lovely weekend :) ps. I know about it being FreeBSDs job to ensure a reliable delivery of bullet from gun to foot. But I feel like an exception is warranted here, especially given that the two other firewalls have similar functionality.