From 89003ea320fdaec02354ac654d398e0220610877 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rodrigo=20Ram=C3=ADrez=20Norambuena?= Date: Sat, 22 Aug 2015 00:37:23 -0400 Subject: [PATCH] README*: Remove trailing whitespace Change-Id: I18b7d75187548a9ed55b4f258d21aaaf29d08874 --- README | 8 +++---- README-SERIOUSLY.bestpractices.txt | 34 +++++++++++++++--------------- README-addons.txt | 8 +++---- 3 files changed, 25 insertions(+), 25 deletions(-) diff --git a/README b/README index ebd071251d..d5f86c1ac5 100644 --- a/README +++ b/README @@ -105,7 +105,7 @@ libraries are being looked for, see ./configure --help, or run "make menuselect" to view the dependencies for specific modules. On many distributions, these dependencies are installed by packages with names -like 'glibc-devel', 'ncurses-devel', 'openssl-devel' and 'zlib-devel' +like 'glibc-devel', 'ncurses-devel', 'openssl-devel' and 'zlib-devel' or similar. So, let's proceed: @@ -174,7 +174,7 @@ delimited by ';' (since '#' of course, being a DTMF digit, may occur in many places). A configuration file is divided into sections whose names appear in []'s. Each section typically contains two types of statements, those of the form 'variable = value', and those of the form 'object => -parameters'. Internally the use of '=' and '=>' is exactly the same, so +parameters'. Internally the use of '=' and '=>' is exactly the same, so they're used only to help make the configuration file easier to understand, and do not affect how it is actually parsed. @@ -197,7 +197,7 @@ configuration file read: The "national" switchtype would be applied to channels one through four and channels 10 through 12, whereas the "dms100" switchtype would apply to channels 25 through 47. - + The "object => parameters" instantiates an object with the given parameters. For example, the line "channel => 25-47" creates objects for the channels 25 through 47 of the card, obtaining the settings @@ -206,7 +206,7 @@ from the variables specified above. ------------------------------------------------------------------------------- --- SPECIAL NOTE ON TIME ------------------------------------------------------ - + Those using SIP phones should be aware that Asterisk is sensitive to large jumps in time. Manually changing the system time using date(1) (or other similar commands) may cause SIP registrations and other diff --git a/README-SERIOUSLY.bestpractices.txt b/README-SERIOUSLY.bestpractices.txt index 108adce8f5..b6b418d9fa 100644 --- a/README-SERIOUSLY.bestpractices.txt +++ b/README-SERIOUSLY.bestpractices.txt @@ -4,23 +4,23 @@ The purpose of this document is to define best practices when working with Asterisk in order to minimize possible security breaches and to provide tried -examples in field deployments. This is a living document and is subject to +examples in field deployments. This is a living document and is subject to change over time as best practices are defined. -------- Sections -------- -* Filtering Data: +* Filtering Data: How to protect yourself from redial attacks -* Proper Device Naming: +* Proper Device Naming: Why to not use numbered extensions for devices -* Secure Passwords: +* Secure Passwords: Secure passwords limit your risk to brute force attacks -* Reducing Pattern Match Typos: +* Reducing Pattern Match Typos: Using the 'same' prefix, or using Goto() * Manager Class Authorizations: @@ -47,9 +47,9 @@ security are listed below. Filtering Data ============== -In the Asterisk dialplan, several channel variables contain data potentially -supplied by outside sources. This could lead to a potential security concern -where those outside sources may send cleverly crafted strings of data which +In the Asterisk dialplan, several channel variables contain data potentially +supplied by outside sources. This could lead to a potential security concern +where those outside sources may send cleverly crafted strings of data which could be utilized, e.g. to place calls to unexpected locations. An example of this can be found in the use of pattern matching and the ${EXTEN} @@ -57,14 +57,14 @@ channel variable. Note that ${EXTEN} is not the only system created channel variable, so it is important to be aware of where the data you're using is coming from. -For example, this common dialplan takes 2 or more characters of data, starting +For example, this common dialplan takes 2 or more characters of data, starting with a number 0-9, and then accepts any additional information supplied by the request. [NOTE: We use SIP in this example, but is not limited to SIP only; protocols such as Jabber/XMPP or IAX2 are also susceptible to the same sort of injection problem.] - + [incoming] exten => _X.,1,Verbose(2,Incoming call to extension ${EXTEN}) @@ -83,7 +83,7 @@ to dial extension 500 (which in our example above would create the string SIP/500 and is then used by the Dial() application to place a call), someone could potentially send a string like "500&SIP/itsp/14165551212". -The string "500&SIP/itsp/14165551212" would then be contained within the +The string "500&SIP/itsp/14165551212" would then be contained within the ${EXTEN} channel variable, which is then utilized by the Dial() application in our example, thereby giving you the dialplan line of: @@ -98,7 +98,7 @@ Strict Pattern Matching ----------------------- The simple way to mitigate this problem is with a strict pattern match that does -not utilize the period (.) or bang (!) characters to match on one-or-more +not utilize the period (.) or bang (!) characters to match on one-or-more characters or zero-or-more characters (respectively). To fine tune our example to only accept three digit extensions, we could change our pattern match to be: @@ -121,8 +121,8 @@ application which will contain dynamic information passed to Asterisk from an external source. Lets take a look at how we can use FILTER() to control what data we allow. -Using our previous example to accept any string length of 2 or more characters, -starting with a number of zero through nine, we can use FILTER() to limit what +Using our previous example to accept any string length of 2 or more characters, +starting with a number of zero through nine, we can use FILTER() to limit what we will accept to just numbers. Our example would then change to something like: [incoming] @@ -234,21 +234,21 @@ first ones added to the dictionary for brute force attacks. Secure Passwords ================ -Secure passwords are necessary in many (if not all) environments, and Asterisk +Secure passwords are necessary in many (if not all) environments, and Asterisk is certainly no exception, especially when it comes to expensive long distance calls that could potentially cost your company hundreds or thousands of dollars on an expensive monthly phone bill, with little to no recourse to fight the charges. Whenever you are positioned to add a password to your system, whether that is -for a device configuration, a database connection, or any other secure +for a device configuration, a database connection, or any other secure connection, be sure to use a secure password. A good example of a secure password would be something like: aE3%B8*$jk^G Our password also contains 12 characters with a mixture of upper and -lower case characters, numbers, and symbols. Because these passwords are likely +lower case characters, numbers, and symbols. Because these passwords are likely to only be entered once, or loaded via a configuration file, there is no need to create simple passwords, even in testing. Some of the holes found in production systems used for exploitations involve finding the one test extension diff --git a/README-addons.txt b/README-addons.txt index 4d5e1986fd..99541155cf 100644 --- a/README-addons.txt +++ b/README-addons.txt @@ -9,18 +9,18 @@ potential licensing and/or patent implications that has on your usage and distribution of Asterisk. Even though Asterisk is released as open source under the terms of the -GPLv2 (see LICENSE for details), no core functionality in Asterisk has any +GPLv2 (see LICENSE for details), no core functionality in Asterisk has any dependencies on libraries that are licensed under the GPL. One reason a module may be in the add-ons category is that it may have a GPL dependency. Since these dependencies are not compatible with dual licensing of Asterisk, the -dependant modules are set aside to make it clear that they may not be used -with commercial versions of Asterisk, unless other licensing arrangements are +dependant modules are set aside to make it clear that they may not be used +with commercial versions of Asterisk, unless other licensing arrangements are made with the copyright holders of those dependencies. Another reason that modules may be set aside is that there may be additional restrictions on the usage of the code imposed by the license or related patents. The MySQL and MP3 modules are examples of this. - + If you have any questions, contact your lawyer. ===============================================================================