text:
This chapter focuses on the steps you'll use to help secure your OracleDatabases. You'll see how applying the best practice principles (explored in Chapter 1) to an Oracle database will help to further secure it.
This chapter looks at securing database schemas by limiting their privileges, providing good password support, restricting access using multiple defenses, and securing the network channels to and from the database. These steps represent many of the best practices used by organizations today. These are the actions you should also be taking to configure and operate a secure Oracle Database.
The remaining chapters of this book discuss how to effectively apply technology features and capabilities to the task of building secure database applications. For this to happen successfully, youll first have to apply the lessons taught in this chapter. Youll need to take certain actions and practice certain behaviors to ensure a good security foundation.Securing (Default) User Accounts
A new Oracle database typically comes installed with over 20 default database schemas (the actual number will vary because some of these schemas are optionally installed during the database creation).
As a Google search on "Default Oracle Users" illustrates, the names, passwords, and privileges of these accounts are anything but secret. These accounts are often used to store metadata and procedures for specific database options, such as the Text Option and the Spatial Option. Consequently, many of these accounts have very significant privileges. They may also have well-known passwords listed both in the Oracle product documentation and on the Internet. This combination creates a risk that an unauthorized person will connect to one of these privileged accounts and access, or manipulate, your sensitive data.
During database creation, you can use the Database Configuration Assistant (DBCA) to choose which default accounts (directly associated with database options) to install. It's important to be selective in your decision about the options you need for your database. Installing options that you'll not be using creates an unnecessary risk.
Keep in mind that commercial applications, as well as Oracle applications, will also have associated and well-known schemas. They all represent targets of opportunity for a hacker. These accounts should also be closely guarded.
While the number of accounts and the associated privileges vary from release to release, it's important to ensure these accounts are secured to limit the risk stated above. This section offers suggestions on how to ensure these accounts are secure. Whether you are securing an Oracle created account, or one that you have created, the process for securing these accounts is the same.Securing Access and Logon
The following suggestions offer ways of controlling access to database accounts. The actions range from restricting logins to the account to removing the account entirely. Combining several of these suggestions together is good practice as it supports a defense in depth approach.
- Change the default passwords and create a strong password. The DBCA provides a shortcut for creating the initial passwords during the database creation. It allows you to use the same password for all the accounts. Do not choose this option. Create a strong and different password for each schema!
- Create an impossible password. After installation, this little trick, which is covered in the upcoming "Oracle Passwords" section, maintains the account objects and privileges but prevents anyone from directly logging in because the password can't be supplied.
- Create a database log-on trigger to check for specific users that you don't want to log in, and fail the trigger if one tries. A failed log-on trigger prevents a user from logging in. This technique doesn't work for certain privileged users, such as SYS (SYSDBA) and users with the ADMINISTER DATABASE TRIGGER system privilege. Nevertheless, it may be advantageous to only allow these privileged users into the database. As such, this is an excellent little trick for locking out all other users.
- Revoke CREATE SESSION and/or the CONNECT role. Removing the privilege to log in to the database is an obvious way to prevent someone from logging in to an account. Note this will prevent both hackers and legitimate users and applications from logging in to the account. It doesnt matter if they know the password; the privilege to log on has been removed.
- Lock the account. This is a preferred option because it keeps all the data objects and associated procedures while preventing people from logging in. The effect to this is similar to revoking the privilege to log on to the database but no privileges have to be revoked. This capability was introduced with the Oracle9i Database.
- Revoke all privileges and roles. Revoking the schema's privileges allows you to maintain all the existing data while helping to ensure that if the account is compromised, the hacker will not be able to use privileges to access or manipulate data in other schemas. This suggestion is applicable to the schemas that you believe are no longer being used but are reluctant to remove completely. It's particularly useful for the very privileged default schemas installed with the database. Note that revoking privileges could break procedures that are defined within the schema. It's a good idea to capture all the privileges and role grants before revoking them in case you later need to undo this action.
- Drop the schema. You can drop the schemas that you dont need. However, there is significant risk to doing this. Dropping schemas is very destructive. Not only can the user no longer connect, but all of the tables, data, and procedures are gone, too.
For certain database options, such as the Oracle Label Security, theres an officially supported process for removing the option and schema. The Oracle Universal Installer is the best tool for removing already installed database options. Before dropping any Oracle installed schemas, consult the Oracle product documentation to ensure that your removal of the schema is done correctly. Although dropping schemas is the most certain measure you can take to guarantee the account will not be compromised (because it no longer exists), it should be used with caution.Lock Down Example
This example illustrates how you might accomplish the task of securing a default account. The following code snippet shows this process as done for the MDSYS schema. MDSYS is the schema that supports the Oracle Spatial technology and as such has been granted access (by way of role privileges) to many powerful procedures and data.Securing Access to Default Accounts
In the default installation, the MDSYS account is locked and the password is expired. This means that the account is made accessible by unlocking the schema and providing the initial password that just happens to be "mdsys." A user with the ALTER USER system privilege only has to unlock the MDSYS account to gain access. Since you may never actually need to log in to this account, there are a couple things you can do to further secure it.
First, revoke the CREATE SESSION privilege and the CONNECT role from MDSYS. You do this because the CONNECT role has been granted the CREATE SESSION privilege, too, so the MDSYS has the privilege twiceonce as a direct grant, and once as an indirect grant received via the CONNECT role. Revoking only the role or only the privilege will not prevent someone from logging in as this user.
After you revoke the privileges, modify the password. The default password is mdsys, which could be easily guessed. In the following example, the privileges are revoked from MDSYS and the password is altered.
sec_mgr@KNOX10g> REVOKE CONNECT, CREATE SESSION FROM MDSYS;
Revoke succeeded.
sec_mgr@KNOX10g> ALTER USER MDSYS IDENTIFIED BY ti1hp2r4m;
User altered.
This process helps to secure the account while still making it usable. That is, the spatial data features can still be used.{mospagebreak title=Securing Access to Application Schemas}
For an example of a schema that represents one you have created, lets look at securing the SCOTT schema. Prior to Oracle Database 10g, the SCOTT schema was often created and available through the well-known password tiger, and the account was not locked.For an example of a schema that represents one you have created, lets look at securing the SCOTT schema. Prior to Oracle Database 10g, the SCOTT schema was often created and available through the well-known password, and the account was not locked.
Assume your requirement is to maintain the schema's data while preventing someone from logging into the account. In Oracle9i Database and beyond, you can lock the account. Our approach is to augment this with a few additional measures. First, build a database log-on trigger to prevent someone from logging into the SCOTT schema.
sec_mgr@KNOX10g> CREATE OR REPLACE TRIGGER logon_check
6 raise_application_error (-20001,
7 'Unauthorized Login');
10 /
Trigger created.
An attempt to connect as SCOTT results in the following:
sec_mgr@KNOX10g> conn scott/tiger
ORA-00604: error occurred at recursive SQL level 1
ORA-20001: Unauthorized Login
ORA-06512: at line 4
Warning: You are no longer connected to ORACLE.
Two words of caution with the log-on trigger approach. First, while log-on triggers can be a security ally, they will fire for every user log on and can subsequently degrade the database connection time. In the previous example, the time would be unperceivable. However, if your trigger code queries tables or makes an external call, the degradation could become very noticeable and make this an unviable alternative.
When database log-on triggers were initially released with Oracle8i Database, an exception thrown in the trigger would prevent the user from logging in. Often the exceptions were neither intentional nor handled gracefully. The result was that all users were unable to log on to the database. The only way to get back in to the database was to connect as SYSDBA (internal) and drop or disable the log-on trigger.
To prevent this inadvertent lock out, the Oracle9i Database was altered to not expel users with the ADMINISTER DATABASE TRIGGER system privilege if the log-on trigger throws an exception. This privilege has been granted to the DBA role, so any user with the DBA role will also bypass the previous log-on trigger technique. You can determine who will be exempt from the log-on trigger exceptions with the following query, which lists users and roles that have been granted the privilege.
SELECT grantee
FROM dba_sys_privs
Another technique for securing an account is to revoke all privileges and roles that have been granted to the schema. To do this efficiently, use the following procedure, which accepts the username as a parameter and removes system privileges, object privileges, and roles. The procedure also prints the undo statements that can be used to recreate the privileges on the schema.
CREATE OR REPLACE PROCEDURE deactivate_user (
p_username IN VARCHAR2)
TYPE l_role_list_type IS TABLE OF VARCHAR2 (30)
l_role_list l_role_list_type;
l_role_index BINARY_INTEGER := 1;
l_role_string VARCHAR2 (32767);
l_username VARCHAR2 (30) := upper(p_username);
— revoke System priviliges granted directly to the user
FOR rec IN (SELECT PRIVILEGE, admin_option
FROM dba_sys_privs
WHERE grantee = l_username)
IF (rec.admin_option = 'NO')
DBMS_OUTPUT.put_line ( 'grant '
|| rec.PRIVILEGE
|| ' to '
|| l_username
|| ';');
DBMS_OUTPUT.put_line ( 'grant '
|| rec.PRIVILEGE
|| ' to '
|| l_username
|| rec.PRIVILEGE
|| l_username;
— revoke Object priviliges granted directly to the user
FOR rec IN (SELECT owner,
FROM dba_tab_privs
WHERE grantee = l_username)
IF (rec.grantable = 'NO')
DBMS_OUTPUT.put_line ( 'grant '
|| rec.PRIVILEGE
|| rec.owner
|| '.'
|| rec.table_name
|| ' to '
|| l_username
|| ';');
DBMS_OUTPUT.put_line ( 'grant '
|| rec.PRIVILEGE
|| rec.owner
|| '.'
|| rec.table_name
|| ' to '
|| l_username
|| rec.PRIVILEGE
|| rec.owner
|| '.'
|| rec.table_name
|| l_username;
— revoke roles granted directly to the user FOR rec IN (SELECT *
FROM dba_role_privs
WHERE grantee = l_username)
IF (rec.admin_option = 'NO')
DBMS_OUTPUT.put_line ( 'grant '
|| rec.granted_role
|| ' to '
|| l_username
|| ';');
DBMS_OUTPUT.put_line ( 'grant '
|| rec.granted_role
|| ' to '
|| l_username
IF (rec.default_role = 'YES')
l_role_list (l_role_index) := rec.granted_role;
l_role_index := l_role_index + 1;
|| rec.granted_role
|| l_username;
IF l_role_index > 1
l_role_string :=
'alter user ' || l_username ||' default roles '
|| l_role_list (1);
FOR i IN 2 .. l_role_index – 1
l_role_string :=
l_role_string || ', ' || l_role_list (i);
DBMS_OUTPUT.put_line (l_role_string || ';');
Executing the procedure for SCOTT results in the following output:
sec_mgr@KNOX10g> SET serveroutput on sec_mgr@KNOX10g> SPOOL scottPrivs.sql sec_mgr@KNOX10g> EXEC deactivate_user('scott')
grant UNLIMITED TABLESPACE to SCOTT;
grant CONNECT to scott;
grant RESOURCE to scott;
alter user SCOTT default roles CONNECT, RESOURCE;
PL/SQL procedure successfully completed.
sec_mgr@KNOX10g> spool off
Locking the account will add another layer of defense:
system@KNOX10g> ALTER USER scott ACCOUNT LOCK;
User altered.
system@KNOX10g> conn scott/tiger
ORA-28000: the account is locked
Warning: You are no longer connected to ORACLE.
Combining several different techniques as shown here is a good idea. This approach is consistent with defense in depth. A hacker now has several hurdles to overcome before an account can be accessed. First, the account has to be unlocked. Next, the privilege to create a session has to be restored. Then the trigger has to be disabled, dropped, or altered. Finally, the password has to be altered or guessed.
You can vary the actual steps used in securing your accounts as relevant to your particular use of the schema. However, you should consider some action(s) for every schema in your database. Even a single schema, left unsecured, could create a foothold for an unauthorized user. Using a combination of techniques will help to harden the database and prevent unauthorized access to it.{mospagebreak title=Throw Out Anything Stale}
Over time, it often happens that users and applications no longer require access to the database. Perhaps the user got a new job and will no longer be logging in to your database–at least, not through legitimate means!
A security best practice for operating systems, networks, and databases is to remove unused or unneeded accounts. This is a simple concept that can be simply accomplished, yet it represents one of the most common and serious security risks and bad practices. Stale accounts should be locked at the very least, and preferably dropped. Ive seen many instances when former employees still had active accounts on production systems years after their termination. Whether this is due to laziness or simply a lack of a good process, it's a huge security risk!
To remove unused and unneeded accounts successfully, it's important to know who is and who should be accessing the database. The schemas may not belong to just end users. A previously installed application, used and then abandoned on your database, also creates a security risk.
Be careful dropping schemas even if no one has logged in to them in months. These schemas may hold data and procedures needed by an application. This again emphasizes the importance of knowing which schemas are doing what. If you're not sure whether an account still has relevant information, at the very least, export the data and procedures first!
This again emphasizes the importance of knowing which schemas are doing what. If you're not sure whether an account still has relevant information, at the very least, export the data and procedures first!
How do you know if the account is being accessed? Auditing. You can audit connections to user schemas and access to objects within the schemas. You can even run a batch job to query the audit trail to look for unauthorized accesses and notify an administrator immediately upon detection. For more ideas and auditing examples, see Chapter 8.Oracle Passwords
The Oracle Database stores user passwords in the data dictionary. For database authenticated users, the values stored aren't actually the plaintext passwords themselves but the password verifiers. Password verifiers are hashed (see Chapter 13 for more details on hashing) representations of plaintext passwords. The value is stored in a hexadecimal representation (numbers 0–9 and letters A–F).
The authentication process is performed by computing a password verifier for the plaintext password a user has submitted for authentication and comparing the resulting value with the one stored in the data dictionary. If they match, the user has supplied the same password and is authenticated.Application Password Authentication Using Oracle's Native Password Store
Application user authentication is an important step to ensuring security for database applications. There are times when the application requires authentication but a default mechanism isn't provided. There are three possible methods for implementing your own user authentication for your application. First, you could build, maintain, and/or synchronize your own password repository and authentication scheme. You'll see an example of how to implement a password authentication solution in Chapter 13, which discusses the use of the new DBMS_CRYPTO package.
Second, assuming the application users are also database users, the application could authenticate users by trying to connect to the database as the respective user(s) . This is a bad alternative because it can be costly–from a time and performance perspective–to create and destroy database connections just to authenticate.
The final method, which also assumes the application users are database users, utilizes the database's internal password store. Unfortunately, Oracle supplies no password verifier program for developers to use, so you must build your own interface.
You can do this with a simple trick, commonly referred to as identified by values, that uses a syntactical variation of the ALTER USER DDL. The algorithm is similar to the one the database uses to authenticate its users. You simply need to compute a password verifier for the plaintext password a user submits and compare that value to the one stored in the database.
The following function is based on a program originally written by Tom Kyte. To start the function, obtain the user's current password verifier from the data dictionary:
sec_mgr@KNOX10g> CREATE OR REPLACE FUNCTION is_auth_password
2 p_username IN VARCHAR2,
3 p_password IN VARCHAR2)
6 l_orig_password_verifier dba_users.PASSWORD%TYPE;
7 l_new_password_verifier dba_users.PASSWORD%TYPE;
10 INTO l_orig_password_verifier
11 FROM dba_users
12 WHERE username = UPPER (p_username);
Next, alter the user's password and set it to the password you want to verify. When you do this, the database recomputes the password verifier based on this password. The result is stored in the database dictionary:
13 EXECUTE IMMEDIATE 'alter user '
14 || p_username
15 || ' identified by ' 16 || p_password;
Select this second verifier out and compare it to the original that you've stored. If they match, the passwords must have been the same.
18 INTO l_new_password_verifier
19 FROM dba_users
20 WHERE username = UPPER (p_username);
This works well when the passwords are identical. However, the problem is that if the passwords don't match, you've changed the users password (perhaps to one that they don't know). To resolve this, set the password back to its original value. Since you don't have the original plaintext password, you can't use the traditional ALTER USER syntax. Instead, reset the password by issuing an ALTER USER <username> IDENTIFIED BY VALUES '<original password verifier'>. Passing the original password verifier in single quotes after the values clause resets the password back to the user's original password. The database sees the word "values" and doesn't recompute the password verifier, but it stores the value specified in the quotes directly in the password column for the user.
21 EXECUTE IMMEDIATE 'alter user '
22 || p_username
23 || ' identified by values "'
24 || l_orig_password_verifier
25 || "";
26 RETURN l_orig_password_verifier =
27 l_new_password_verifier; 28 END;
29 /
Function created.
To test the program, check the Boolean return value of the function:
sec_mgr@KNOX10g> BEGIN
2 IF (is_auth_password ('scott', 'tiger') = TRUE)
4 DBMS_OUTPUT.put_line ('scott/tiger is valid');
6 DBMS_OUTPUT.put_line
7 ('scott/tiger is NOT valid');
10 IF (is_auth_password ('scott', 'lion') = TRUE)
12 DBMS_OUTPUT.put_line ('scott/lion is valid');
14 DBMS_OUTPUT.put_line
15 ('scott/lion is NOT valid');
18 /
scott/tiger is valid
scott/lion is NOT valid
This function allows you to authenticate users against the database password store without having to know or manage the user's actual password.{mospagebreak title=Checking for Weak or Default Passwords}
Passwords are often the weak link in the security chain. A poorly chosen password, or well-known default password that has not been changed, is one of the greatest security risks to a database. To help manage this risk use the following program, which compares a list of known usernames and password verifiers to the users and verifiers actually being used in the database. The list is created by a helper program.
To start, a table is created that stores usernames, their plaintext passwords, and the respective computed password verifiers:
sec_mgr@KNOX10g> CREATE TABLE passwords
2 (
3 username VARCHAR2(30),
4 passwd VARCHAR2(30),
5 verifier VARCHAR2(30)
6 )
7 /
Table created.
sec_mgr@KNOX10g> ALTER TABLE PASSWORDS ADD (
Table altered.
sec_mgr@KNOX10g> CREATE INDEX VERIFIER ON PASSWORDS
Index created.
To populate the table, a procedure is created that utilizes the identified by values clause introduced in the IS_AUTH_PASSWORD function shown earlier. The procedure takes a password parameter. The program iterates through the DBA_USERS view and sets the passwords for all the users to the value passed as the parameter. The program then inserts the resulting password verifier into the PASSWORDS table. When the parameter is null, the password is set to the username. This has the benefit of allowing you to check for passwords that are the same as the username.
sec_mgr@KNOX10g> CREATE OR REPLACE PROCEDURE populate_passwords_tab (
2 p_password IN VARCHAR2 DEFAULT NULL)
4 l_new_password_verifier dba_users.PASSWORD%TYPE;
5 l_password dba_users.PASSWORD%TYPE
6 := UPPER (p_password);
8 FOR rec IN (SELECT username, password
9 FROM dba_users)
11 IF (p_password IS NULL)
13 — password is either passed as parameter
14 — or set to user's name
15 l_password := rec.username;
18 — create new password verifier
19 EXECUTE IMMEDIATE 'alter user '
20 || rec.username
21 || ' identified by '
22 || l_password;
23 — retrieve new verifier
24 SELECT password
25 INTO l_new_password_verifier
26 FROM dba_users
27 WHERE username = rec.username;
28 — insert value into passwords table
29 INSERT INTO passwords
30 VALUES (rec.username,
31 l_password,
32 l_new_password_verifier);
33 — set password back to its original value
34 EXECUTE IMMEDIATE 'alter user '
35 || rec.username
36 || ' identified by values "'
37 || rec.password
38 || "";
41 /
Procedure created.
Next, execute the above procedure to seed the table first with usernames equal to passwords. Since the procedure modifies user passowords, you should consider running this on a non-production database so this process doesn't interfere with your production applications. Then try some common passwords associated with the default Oracle accounts (there may be additional common and default usernames within your organization). Any standard applications you've installed on Oracle may also carry default schemas and well-known default passwords, so you should consider all default schemas and their passwords, too. Oracle Metalink (http://metalink.oracle.com) lists some of the default usernames and passwords in Note:160861.1.
sec_mgr@KNOX10g> — sets all passwords to that of user's name
sec_mgr@KNOX10g> EXEC populate_passwords_tab
PL/SQL procedure successfully completed.
sec_mgr@KNOX10g> — check for manager, a common password for DBA accounts sec_mgr@KNOX10g> EXEC populate_passwords_tab ('manager')
PL/SQL procedure successfully completed.
sec_mgr@KNOX10g> — check for your company's name here
sec_mgr@KNOX10g> EXEC populate_passwords_tab ('oracle')
PL/SQL procedure successfully completed.
sec_mgr@KNOX10g> — SCOTT's default password sec_mgr@KNOX10g> EXEC populate_passwords_tab ('tiger')
PL/SQL procedure successfully completed.
sec_mgr@KNOX10g> — SYS' default password sec_mgr@KNOX10g> EXEC populate_passwords_tab ('change_on_install')
PL/SQL procedure successfully completed.
sec_mgr@KNOX10g> — common password people use
sec_mgr@KNOX10g> EXEC populate_passwords_tab ('password')
PL/SQL procedure successfully completed.
sec_mgr@KNOX10g> COMMIT ;
Commit complete.
Now that you have a data set of precomputed password verifiers, you're ready to run checks against your production database.
Once the password table has been created, the same data can be used against any Oracle Database because the password verifiers for the usernames are always the same in every Oracle Database. For the procedure that actually performs the checking, simply iterate through the database users comparing the password verifier computed there with the one actually stored in the PASSWORDS table. When you find a match, print the matched value and the accounts status:
For the procedure that actually performs the checking, simply iterate through the database users comparing the password verifier computed there with the one actually stored in the PASSWORDS table. When you find a match, print the matched value and the accounts status:
sec_msr@KNOX10g>> CREATE OR REPLACE PROCEDURE check_passwords
4 FOR rec IN (SELECT username,
6 account_status
7 FROM dba_users)
9 FOR irec IN (SELECT *
10 FROM passwords
11 WHERE username = rec.username
12 AND verifier = rec.PASSWORD)
14 DBMS_OUTPUT.put_line
15 ('——————————');
16 DBMS_OUTPUT.put_line ( 'Password for '
17 || rec.username
18 || ' is '
19 || irec.passwd);
20 DBMS_OUTPUT.put_line
21 ( 'Account Status is '
22 || rec.account_status);
26 /
Procedure created.
sec_mgr@KNOX10g> set timing on sec_mgr@KNOX10g> SET serveroutput on sec_mgr@KNOX10g> EXEC check_passwords
Password for CTXSYS is CHANGE_ON_INSTALL Account Status is LOCKED
Password for DIP is DIP
Account Status is LOCKED
Password for OLAPSYS is MANAGER Account Status is LOCKED
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.03
The output from the procedure's execution was truncated in the previous output. It simply shows that the procedure was successful in finding passwords (not all successful findings are printed). Because changing default passwords is a best practice, this program can assist you in ensuring your Oracle Databases are compliant with best practices and are thus better secured.{mospagebreak title=Impossible Passwords}
The Oracle database user's password verifier is stored as a 16-character hexadecimal string. If you query the DBA_USERS view, you'll see some passwords that aren't hexadecimals. For example, there's a database user named ANONYMOUS with a password of anonymous. How can that be? If you created a user by the name of ANONYMOUS with a password of anonymous, the password verifier wouldn't say anonymous; it would be a hexadecimal representation of a hash of the password, not a plaintext string. You can check the passwords table previously created to verify this:
sec_mgr@KNOX10g> select * from passwords
2 where username = 'ANONYMOUS'
3 and pwd = 'ANONYMOUS';
The reason the string anonymous is present, as opposed to the verifier you see above, is that the user wasn't created with the standard CREATE USER syntax but with the identified by values clause, as shown here:
SQL> CREATE USER anonymous IDENTIFIED BY VALUES 'anonymous';
User created.
SQL> select username, password
2 from dba_users
3 where username = 'ANONYMOUS'
4 /
——————- ————————
ANONYMOUS anonymous
This is a simple trick you can use to ensure users don't log in to an account. Its similar to creating a very strong password, but it's better because you can't log in to the account with anonymous or any other string in the universe!
The reason that no password is possible is because Oracle, on authentication, will compute the password verifier, which will be some 16-character hexadecimal string. This is compared with the one stored for the user. Because you know the password verifiers are stored in hexadecimal format, any values outside of the hexadecimal set (0–9, A–F) will not match the one computed. The result: there is no password the user can provide that will allow them to log in.
Anytime you are creating a database schema to which no one should connect, you should use an impossible password. The account also should be locked and privileges to connect to the database should not be given.Managing and Ensuring Good Passwords
Passwords are the most prevalent form of authentication to Oracle Databases. Oracle provides the ability to enforce the choice of good, strong passwords through the use of password complexity routines. Oracle also provides a way to ensure good password management practices are also being followed through password profile enforcement.Password Complexity
Oracle supports user-defined password complexity routines that allow you to validate the strength of passwords when they are set. Password complexity routines are critical to ensuring that password best practices are obeyed. The complexity routine technically implements the official password policy in your organization (assuming you have such a policy, and you should). You can check for many things within the routine. The biggest exception is case-sensitivity. Database authenticated user passwords are case insensitive. Here are a few common best practice checks you can administer within the complexity routine:
- Password isn't the same as the username
- Password contains at least one digit
- Password is greater than some specified length
- Password isnt the same as the old password
- Password isn't an easy to guess word, such as manager, oracle, or your company's name
The function that administers the password check has to be implemented in the SYS schema. The password complexity function returns a Boolean value. The value TRUE means the password is okay. However, a good trick is to raise an exception in the function to notify the user of exactly what condition failed during their password change. Otherwise, they will get a generic error. A sample function that implements some of the above checks would look as follows:
sys@KNOX10g> CREATE OR REPLACE FUNCTION is_password_strong (
2 p_username VARCHAR2,
3 p_new_password VARCHAR2,
4 p_old_password VARCHAR2)
5 — return TRUE if password is strong enough
8 l_return_val BOOLEAN := TRUE;
10 — Check to be sure password is not the same as username
11 IF UPPER (p_new_password) = UPPER (p_username)
13 l_return_val := FALSE;
14 raise_application_error
15 (-20001,
16 'Password same as user name');
19 — force user to change password to something new
20 IF UPPER (p_new_password) =
21 UPPER (p_old_password)
23 l_return_val := FALSE;
24 raise_application_error
25 (-20004,
26 'Password has to be different than old password');
29 — Check for list of predictable passwords
30 IF LOWER (p_new_password) IN
31 ('manager',
32 'change_on_install',
33 'oracle',
34 'password')
36 l_return_val := FALSE;
37 raise_application_error
38 (-20002,
39 'Password is too predictable');
42 — make sure password contains at least one digit
43 IF (regexp_like (p_new_password, '[0123456789]') =
46 l_return_val := FALSE;
47 raise_application_error
48 (-20003,
49 'Password needs at least one digit');
52 — make sure password is at least six characters
53 IF LENGTH (p_new_password) <= 6
55 l_return_val := FALSE;
56 raise_application_error
57 (-20005,
58 'Password is too short');
61 RETURN l_return_val;
63 /
Function created.
To enforce the password complexity routine, assign it to a Password Profile and then assign the profile to the user(s). Examples are shown in the following section.{mospagebreak title=Password Profiles}
Oracle allows you to create Password Profiles that govern the behavior of the database with respect to passwords and authentication. To do this, create a profile with values set for the attributes you wish to use. The profile then can be enforced on your users. Oracle supports the following attributes for password profiles:
- Password lifetime Allows a password to exist for a specific period of time
- Grace period Time at which Database begins to warn users to change their password
- Reuse time/max Supports password history and forces users to use new passwords
- Failed login attempts Locks the account if the incorrect password is given after specified number of times
- Account lockout Disables the account (combined with failed attempts to help prevent brute force attempts into user accounts)
- Password Verify Function Defines the password complexity function that will be called when the user changes the password
Chapter 7 of the Oracle Database Security Guide gives more detailed explanations of these attributes. A sample profile that sets values for these attributes and assigns the complexity function defined previously would look as follows:
sec_mgr@KNOX10g> CREATE PROFILE strong_pwd LIMIT
8 PASSWORD_VERIFY_FUNCTION is_password_strong;
Profile created.
Now assign this profile to your users. Testing this on the user SCOTT yields the following results:
sec_mgr@KNOX10g> — assign profile sec_mgr@KNOX10g> ALTER USER scott PROFILE strong_pwd;
User altered.
sec_mgr@KNOX10g> — test profile sec_mgr@KNOX10g> — reset scott's password sec_mgr@KNOX10g> ALTER USER scott IDENTIFIED BY scott;
ALTER USER scott IDENTIFIED BY scott
ERROR at line 1:
ORA-28003: password verification for the specified password failed
ORA-20001: Password same as user name
sec_mgr@KNOX10g> ALTER USER scott IDENTIFIED BY manager;
ALTER USER scott IDENTIFIED BY manager
ERROR at line 1:
ORA-28003: password verification for the specified password failed
ORA-20002: Password is too predictable
sec_mgr@KNOX10g> ALTER USER scott IDENTIFIED BY nodigit;
ALTER USER scott IDENTIFIED BY nodigit
ERROR at line 1:
ORA-28003: password verification for the specified password failed
ORA-20003: Password needs at least one digit
sec_mgr@KNOX10g> — since this is not SCOTT, old password is null
sec_mgr@KNOX10g> ALTER USER scott IDENTIFIED BY tiger;
ALTER USER scott IDENTIFIED BY tiger
ERROR at line 1:
ORA-28003: password verification for the specified password failed
ORA-20003: Password needs at least one digit
sec_mgr@KNOX10g> ALTER USER scott IDENTIFIED BY short1;
ALTER USER scott IDENTIFIED BY short1
ERROR at line 1:
ORA-28003: password verification for the specified password failed
ORA-20005: Password is too short
Normally, after creating a password profile, you'll force your users to change their passwords to ensure all passwords being used comply with the profile. To do this, you expire their existing password. Upon their next login, the database prompts them to reset their password. The new password is checked against the complexity routine and the other password profile values will also be enforced.
When administering this for SCOTT, set the new password to tiger, which you can't see when looking at the output below. You may have noticed in the previous example that the complexity function didn't indicate that the new tiger password matched the old password. The following output shows a different behavior when SCOTT changes his password. The complexity routine now informs him that the new password is the same as the old password. Note that this is done for security. If a user other than SCOTT received this message, then the database would have divulged the user's password.
sec_mgr@KNOX10g> ALTER USER scott PASSWORD EXPIRE;
User altered.
sec_mgr@KNOX10g> conn scott/tiger
ORA-28001: the password has expired
Changing password for scott
New password:
Retype new password:
ORA-28003: password verification for the specified password failed
ORA-20004: Password has to be different than old password
Password unchanged
Warning: You are no longer connected to ORACLE.
A password profile is a great way to ensure that good password management practices are being used. Once again, however, you have to balance security with usability. While using password profiles is generally a good idea, it can backfire. For example, forcing users to choose a new password each week (that is, expiring passwords too frequently) may in fact force the user to use easy passwords or worse, write down their passwords.
As another example, you may decide after three failed logins, youll lock the user account for a day. There are unintended consequences to this. The failed login and account locking can aid someone launching a denial of service (DoS) attack. The attack is made easy because a malicious person can intentionally lock all the database accounts by simply providing an incorrect password for each database user.Limiting Database Resources
Whether intentional or malicious, a computer's resources can be monopolized without much effort. Generally, when this is done maliciously, it is known as a denial of service (DoS) attack.
DoS attacks are easy to implement and hard to defend against. The defense challenge arises from the fact that there are numerous ways to trigger such attacks. The result is simple: exhaust computing resources to the point that the database can no longer provide adequate service. Fortunately, there are some actions you can take in the database to mitigate the risk of DoS attacks.Resource Limits
In addition to the password profile capabilities, Oracle supports the use of resource profiles to limit the use of precious database resources. Resource limits help ensure that the application or user doesn't intentionally, or inadvertently, take over the database and system's resources. You can view the various resources that can be managed as well as their values by querying the DBA_PROFILES view:
sec_mgr@KNOX10g> SELECT resource_name, LIMIT
2 FROM dba_profiles
4 AND resource_type = 'KERNEL';
—————————— ————
9 rows selected.
Notice that the default values are all set to unlimited. A best practice is to actually define as many of these values as possible. Some general guidelines on the parameters are as follows:
- Set the SESSIONS_PER_USER to the size of your application server connection pool. If you aren't using a connection pool (or have no idea what that means), then set the value to something reasonable. You should consider that an application may lock or a computer may freeze with the connection open, so a value of one may be too restrictive.
It's possible to create a denial-of-service attack by utilizing the CREATE SESSION privilege and connecting to the database over and over until the database server exhausts all memory. Setting this parameter helps to ensure this will not happen.
- IDLE_TIME can be set to help ensure that users don't leave a connected terminal in the database while they step out for a lunch break. If their machine is left unlocked, then someone can simply walk up and start accessing the user's data without having to worry about breaking passwords or subverting privileges. This value is more applicable to client-server applications than to web applications; if the latter is using a connection pool, the server shouldn't disconnect the pooled connections.
- CPU_PER_CALL is a hard parameter to guess, but it helps to ensure the availability of the database. Often CPU monopolization occurs not by a malicious user, but by a bad programmer who inadvertently sends the database into a recursive loop (I'm speaking from experience here)!
Refer to the "Create Profile" section in the Oracle Database SQL Reference 10g document for specific definitions on all the settings. Setting the profile parameters to the logical and correct values may take a few tries before the best values are selected. Start with a least privilege mentality by setting the values very conservatively. If you find that you need to relax a few privileges for legitimate reasons, do so only after you have determined the values need to be relaxed.
A best practice is to create a profile for each application or class of users in the database. This includes administrators at all levels.{mospagebreak title=Default Roles}
Just as the Oracle Database comes with default schemas, it also comes with several default roles. These roles exist mostly for legacy reasons and according to the Oracle documentation will one day be removed. This section discusses these roles and how to securely interact with them.CONNECT
The first default role you should understand is the CONNECT role. This is one of the most misused roles probably because its name implies that it's a necessary privilege. Many DBAs grant users CONNECT thinking that it's only the simple privilege to log on to the database. It's not! The actual privilege required to log on to the database is the CREATE SESSION privilege. As you can see from the following code, the CONNECT role has more than this single privilege:
sec_mgr@KNOX10g> SELECT PRIVILEGE
2 FROM dba_sys_privs
3 WHERE grantee = 'CONNECT';
8 rows selected.
Some of these privileges, such as CREATE VIEW, CREATE TABLE, and CREATE DATABASE LINK, are probably more powerful privileges than you want your users to have. Therefore, in the spirit of least privileges, you shouldn't be granting the CONNECT role to your users as the means by which they are privileged to log on to the database.RESOURCE
The next default role is RESOURCE. This role has also been in existence for many years and its use should be limited for the same reasons cited above. You can see this role, like the CONNECT role, also has many privileges granted to it:
sec_mgr@KNOX10g> SELECT PRIVILEGE
2 FROM dba_sys_privs
3 WHERE grantee = 'RESOURCE';
8 rows selected.
There is also a hidden system privilege that is granted to users with the RESOURCE role: UNLIMITED TABLESPACE. This can be dangerous because users with this privilege have no effective quota and can use up all available disk space (see how to curtail such use in the previous section, "Limiting Database Resources").
In the following example, a user is created and granted the RESOURCE role, and by checking the user's privileges, you'll notice that the user has an unrestricted quota.
sec_mgr@KNOX10g> CREATE USER unlim IDENTIFIED BY VALUES 'noPassword';
User created.
sec_mgr@KNOX10g> — user has no privileges
sec_mgr@KNOX10g> SELECT *
2 FROM dba_sys_privs
3 WHERE grantee = 'UNLIM';
no rows selected
sec_mgr@KNOX10g> — grant resource role to user
sec_mgr@KNOX10g> GRANT RESOURCE TO unlim;
Grant succeeded.
sec_mgr@KNOX10g> — note the user now has unlimited quota
sec_mgr@KNOX10g> SELECT PRIVILEGE
2 FROM dba_sys_privs
3 WHERE grantee = 'UNLIM';
It's common to see grants to both the CONNECT and the RESOURCE roles within Oracle example code as well as actual deployed commercial applications. Don't assume that this is a best practice.
Complying with the least privilege principle is a best practice and relying on the CONNECT and RESOURCE roles as an easy way to grant privileges to your users is a bad practice. DBA
Another important role that is commonly granted is the DBA role, which has every system privilege known to the database either directly granted or inherited through another role. It's not unusual for this role to be granted to the data or procedural schemas used for an application. This is a gross misuse of privileges.
Granting the DBA role abides by the most privilege principle, rather than the preferred least privilege principle. Chapter 7 shows how to effectively manage privileges and roles. When it comes to ensuring the default roles aren't abused, there are three actions you can take. However, I suggest you only do the last:
- Revoke all privileges assigned to default roles. This can be useful in an application where you are checking to see if a user is a member of a role, but you don't want there to be associated privileges with that role, such as with the DBA role.
- Drop the default roles. Check with support first, because this may have negative effects on your default applications. Be sure to make a sound backup of the database and test it on your development system first!
- Don't grant the DBA, CONNECT, or RESOURCE roles to users.
PUBLIC Privileges
One of the principle techniques for securing an Oracle Database involves the careful analysis of the use of the user group PUBLIC. The user group PUBLIC, as the name implies, represents every user in the database; therefore, a grant to PUBLIC is a grant to everyone in the database. This shorthand way of granting and revoking privileges can be a very useful feature. It also can create huge security risks especially when trying to ensure the database is operating in a least privileges manner.When to Grant Privileges to PUBLIC
There are many occasions when grants to PUBLIC are sensible and don't create security risks. For example, most Oracle database application developers recognize that the DUAL table is both very useful and contains absolutely no sensitive information. This is true of other procedures and functions as well–the SYSDATE function is a good example of a useful function that doesn't have security risks associated with it. Therefore, PUBLIC access to the DUAL table and the SYSDATE function don't represent a security risk.
Unfortunately, it's difficult to know whether a grant to PUBLIC is really a security risk. As you develop your applications, you should carefully decide what, if anything, is granted to PUBLIC.
You also should consider what may not appear to be a risk today, could be a risk tomorrow. For example, suppose you have a table that stores user preferences for a web application. Initially, you allow users to save their preferences for the foreground and background colors as well as the font style that will be used in creating a personalized web page for them. Since none of this information is sensitive, you decide that it can be viewed by anyone.
scott@KNOX10g> CREATE TABLE user_prefs
2 (background_color VARCHAR2(6),
3 foreground_color VARCHAR2(6),
4 font_style VARCHAR2(20));
Table created.
scott@KNOX10g> GRANT SELECT ON user_prefs TO PUBLIC;
Grant succeeded.
Later, you might add a sensitive attribute. For example, you may want to allow the user to store hyperlinks to their favorite web sites and applications.
scott@KNOX10g> ALTER TABLE user_prefs ADD favorite_links VARCHAR2(250);
Table altered.
The addition of this attribute changes the overall sensitivity of the table. The grant to PUBLIC should now be removed. The security rule for governing PUBLIC privileges is: when in doubt, do not grant access to PUBLIC.{mospagebreak title=Oracle Supplied Objects}
In efforts to secure the Oracle database, you also have to consider the privileges that already have been granted to PUBLIC by both the applications you develop, or purchase, and the Oracle-supplied database objects.
There are two areas you should be concerned with respecting default grants to PUBLIC on Oracle objects:
- Access to data dictionary views There are several data dictionary views that will give a user information that could be used to aid in a database attack.
- Execute on procedures This includes PL/SQL functions and procedures and packages, as well as any Java procedures. These procedures perform many useful functions–such as opening network connections, reading files from the operating system, and setting identifier information about the user or application–all of which might be used in subsequent security processes, such as access control and auditing.
The Oracle database already provides some security to the database dictionary metadata by restricting access to the sensitive data. Over time, the definition of "sensitive data" has evolved. Originally, sensitive data referred to items such as the encrypted user passwords. Today, even the list of all usernames in the database is considered sensitive. However, some of this data is still available to PUBLIC.
As an example, the ALL_USERS view is accessible to PUBLIC and it lists the username of every database schema. A technique often used by hackers is to obtain and use a list of valid user accounts to try to access those accounts. Privileged database option schemas (such as MDYS), default application accounts, and user accounts will be listed by the ALL_USERS view as valid targets to a nefarious user. The list of valid database users then becomes a list of valid database targets. A malicious user could easily say, "Oh look, the <insert option name or your application here> is installed. Let me use the default password and try to access this privileged account.
Therefore, you should consider revoking PUBLIC access to certain database metadata. Looking at SYS objects that start with ALL is a good place to start:
SELECT table_name
FROM dba_tab_privs
WHERE grantee = 'PUBLIC'
AND owner = 'SYS'
AND table_name LIKE 'ALL%';
Before revoking PUBLIC access to default database objects, you should know that the revocation may break existing programs or applications. The following example shows 20 database objects that become invalid after the PUBLIC privileges have been removed from the ALL_USERS view.
sys@KNOX10g> SELECT count(*) FROM all_objects
2 WHERE status = 'INVALID';
1 row selected.
sys@KNOX10g> REVOKE SELECT ON all_users FROM PUBLIC;
Revoke succeeded.
sys@KNOX10g> SELECT count(*) FROM all_objects
2 WHERE status = 'INVALID';
1 row selected.
The damage isn't unrepairable. If an application relies on a revoked privilege that was once granted to PUBLIC, it can be fixed by granting the privilege directly to the application. To do this for the data dictionary views, simply list the schemas that require the direct grant.
sys@KNOX10g> — Show whose objects are broken.
sys@KNOX10g> SELECT distinct owner
2 FROM all_objects
3 WHERE status = 'INVALID';
6 rows selected.
Of these schemas, some have the system privilege SELECT ANY DICTIONARY, which already provides access to the ALL_USERS view. The objects in those schemas will recompile without requiring any grants; however, the other schemas will require a direct grant on the ALL_ USERS view. You can display the list of remaining schemas that require the direct grant by using the SQL minus function bolded in the following code. This code wraps the result set in the DDL you'll use to issue the grants:
sys@KNOX10g> — create list of users who require
sys@KNOX10g> — direct select privileges on ALL_USERS
sys@KNOX10g> SELECT DISTINCT 'grant select on all_users to '
2 || owner
3 || ';' sql_command
4 FROM (SELECT DISTINCT owner
5 FROM all_objects
6 WHERE status =
8 AND owner != 'SYS'
10 SELECT grantee
11 FROM dba_sys_privs
grant select on all_users to DMSYS;
grant select on all_users to EXFSYS;
grant select on all_users to LBACSYS;
grant select on all_users to XDB;
4 rows selected.
Using copy and paste technology for the values in the SQL_COMMAND, issue the direct grant to the users that require it. After the grant has been made, the invalid objects in those schemas will recompile.
Unfortunately, the consequences of the revocation are nearly impossible to predict. This is why Oracle hasn't already removed PUBLIC privileges to the database metadata views. The Oracle Database Security Guide also warns that revoking DML privileges from PUBLIC can be nontrivial:
PUBLIC Privileges on Programs
Revoking a privilege from PUBLIC can cause significant cascading effects. If any privilege related to a DML operation is revoked from PUBLIC, all procedures in the database, including functions and packages, must be reauthorized before they can be used again. Therefore, exercise caution when granting and revoking DML-related privileges to PUBLIC.
Next, analyze the execute privileges on programs granted to PUBLIC. Again, there are too many specific programs to list and the programs will constantly be changing. The same principle applies to securing these programs as to the preceding views. That is, knowing what the programs do is important to understanding what risks, if any, are present.
The programs you should be most concerned with are the ones that start with DBMS% and UTL%:
SELECT table_name
FROM dba_tab_privs
WHERE grantee = 'PUBLIC'
AND owner = 'SYS'
AND table_name LIKE 'DBMS%'
OR table_name LIKE 'UTL%'
Don't limit your evaluation to just these programs or SYS-owned objects. All options and applications in your database should be evaluated. The Oracle Database Security Guide suggests revoking execute privileges on UTL_SMTP, UTL_TCP, UTL_HTTP, and UTL_FILE from PUBLIC. You should not only do this, but also remember the point of this exercise is to restrict access to procedures to only those applications, users, and objects requiring access.
The Oracle Database Security Guide suggests revoking execute privileges on UTL_SMTP, UTL_TCP, UTL_HTTP, and UTL_FILE from PUBLIC. You should not only do this, but also remember the point of this exercise is to restrict access to procedures to only those applications, users, and objects requiring access.
Just as in the metadata example, there are often application dependencies created upon the PUBLIC grants to these programs. To successfully revoke privileges, you need to understand the dependencies and be able to rectify any problems that are created by the revocation process. Chapter 6 provides an example of this process to revoking the execute privileges on the DBMS_ SESSION package.{mospagebreak title=Securing the Network}
For most databases, security begins even before the users gain access to the database. The network that links together the users, applications, and databases is critical in the security chain. There are a few actions you should take to strengthen this link.Encryption
Today, some believe that network encryption isn't necessary. After all, antivirus software and firewalls are already in place.
This is wrong. While there is some level of security afforded by these technologies, the assumption that network traffic is totally secure is false. Anyone can place a network packet sniffer (readily available on the Internet) on the application server that connects to the database. Both are behind the firewall. With the sniffer they can easily capture all the traffic to and from the application server. Packets can be spooled to a file. Later, after the important data has been collected, the spool file can be sent via e-mail to an "anonymous" Internet account. This is not fiction; it really happens. Why bother breaking into the database with all its security when you can easily capture all the important data as it enters and leaves the database? This scenario illustrates the need for network encryption.
When deploying applications that communicate with an Oracle Database, the Oracle network encryption capabilities provide seamless and transparent encryption of all your database data as it moves through the network. While it may not be needed in all situations, it should always be considered and is strongly recommended.
There are three benefits to implementing Oracle's network encryption capabilities:
- The algorithm negotiation feature supports the concurrent use of different encryption algorithms with different key sizes for various clients. This flexibility means that security and performance can be accomplished simultaneously.
- The encryption remains transparent to the applications that utilize it.
- Independent lab tests show little overhead costs, which makes it an acceptable trade-off in most cases.
Configuring the network for encryption is simple. Either edit the SQLNET.ORA file with a text editor or use the Oracle Net Manager. A view into the file shows how easy it is to instruct the Oracle network software to secure the channel:
thisistheencryptionseed(S)DLKDk0(*)(*#IUI%$,k9r80dsa0__llk098 09cxf-08 SQLNET.ENCRYPTION_SERVER = requested SQLNET.ENCRYPTION_CLIENT = requested SQLNET.ENCRYPTION_TYPES_CLIENT= (AES256) SQLNET.ENCRYPTION_TYPES_SERVER= (AES256)
Using these settings, the network software will employ the SHA-1 algorithm to ensure data integrity and also will encrypt all data using the AES algorithm with 256-bit key sizes.Database Listener
The database listener is the process that handles connections over the network destined for the database. Two important points about the listener:
- It is a critical program and needs to be run much of the time.
- It is the forward application, which means that it stands the biggest risk of attack. User programs can interact with the listener directly even if they don't have database accounts.
As with most network processes, there are numerous attacks that can occur against the database listener. Securing the database listener is a top priority. The first task is to password protect the listener process. Limiting status information is critical to securing the listener since the listener will happily explain everything it knows when prompted. This information is useful to both DBAs and to hackers.
The database listener also comes defaulted to a well-known network port or two. While it's by no stretch of the imagination a "robust" security maneuver, changing the default port is nevertheless a good idea. If the listener is on a different port, someone who is scanning the network for open ports will detect a process listening on that port but may not know what it is. Some hackers only probe for well-known ports because the full port scans are obvious and can set off the intrusion detection alarms.
Changing the listening ports (and not only from 1521 to 1522) is a best practice. To configure the listener, either edit the LISTENER.ORA file with a text editor or use the Oracle Net Manager.
To configure the listener, either edit the LISTENER.ORA file with a text editor or use the Oracle Net Manager.
The database supports a useful capability whereby PL/SQL programs running inside the database can make external calls to a program running on the operating system. The benefit is that the OS programs will either execute faster (because they are C programs optimized to perform a specific task) or pass information about the operating system back into the database (such as uptime, currently executing processes, and logged in users).
However, the external procedure call capability is a high security risk; the process runs with the privileges of the database listener. If the external procedure is successfully compromised, the hacker may find themselves sitting in a privileged shell.
If youre using, or need to use, this capability be sure to keep it in check; otherwise, disable it. To do this, modify the Oracle network configuration files (the PLSExtProc service). Removing the binary that allows this, extproc.exe, is also a good idea.
If you need to support external procedures, it's best to configure the extproc listener to run as an unprivileged user; for example, the "nobody" user on UNIX. By default, the process runs with the privileges of the database listener. By following this configuration suggestion, the risks associated with a compromised external procedure are significantly diminished.IP Validation
IP addresses are the network method for naming entities. While the actual network protocols function at a lower layer (based on the MAC address), IP addresses remain a valuable identification asset. The main drawback with IP-based security is that it's not too difficult, relative to other tricks such as trying to break encryption, to impersonate another computer's IP Address (spoofing). The ability to successfully spoof depends on the network topology and the abilities of the network administrators to enforce strict IP addresses. Many network intrusion detection systems will alert administrators to duplicate IP addresses on their networks.
Assuming the IP address can be used to accurately identify the client, the IP address can then be incorporated into the database security implementations.
The Oracle database listener can be configured to allow or disallow access based on the client's IP address. This is an easy way to begin shielding your database from unwanted users.
The configuration can again be completed using the Oracle Net Manager. The settings are placed in the SQLNET.ORA file (prior to Oracle9i Database, this was the PROTOCOL.ORA file). For example, the following configuration will only allow a network connection from a single computer with the IP address of 192.168.1.21:
If your security policy dictates that the database only should be accessed from the application server, which has the previous IP address, these two lines can be added to your SQLNET.ORA file to ensure the database listener process will not accept any other connection requests. You can alternatively specify which specific nodes you want to exclude by setting the TCP.EXCLUDED_ NODES value.
Using the valid node checking capability is a good practice because it helps ensure that the only connections coming in over the network are from computers that are authorized.Summary
Building secure database applications is done on the assumption that the database is already operating securely. To ensure this happens, you often have to perform certain tasks to create a tighter security implementation. There are many important lessons in this chapter.
Securing database schemas means ensuring not only new schemas are created and managed properly but also that the default schemas are secured. The default schemas and their passwords are well known. There are several ways to prevent unwanted and unauthorized users from connecting to these well known and highly privileged accounts. Several techniques were shown for applying the defense in depth principle.
An understanding of Oracle's use of passwords is necessary because password authentication represents the most common authentication mechanism to the database. The database supports both password complexity routines and password profiles to support the secure and proper use of passwords.
Oracle's default roles exist today for legacy reasons and should rarely be used, and revoking existing privileges and limiting grants to the user group PUBLIC is essential for securing the database.
A final necessary piece of the security puzzle is network security. The entire security of an application and database can be subverted through poor network security. The database provides several ways to prevent this from happening. Applying security at the network tier ensures all the links in the security chain are strong.


text:
kungfuters needed a new logo design and created a contest on 99designs.
A winner was selected from 112 designs submitted by 25 freelance designers.
AwkwardTurtle.com is a social contest site where people submit stories about awkward experiences. Other visitors then vote on their favorite stories. Each contest lasts one week, and the prizes vary from t-shirts to Nintendo Wiis. The site is meant to be fun and is totally free to play. The look and feel is meant to be cute and humorous. If you do not know what the "Awkward Turtle" is, it is a hand gesture you make whenever you experience an awkward moment. (Google it or see attached file.) =) We like to have fun. We want our visitors to have fun and share the fun with their friends.
We are generally targeting college-aged people and maybe even some upper high schoolers. These people all know what the "Awkward Turtle" is and enjoy sharing stories (and have plenty of stories to tell) about awkward moments in their lives. We also want people who enjoy returning to our site just to see who said what next, looking for a good laugh to pass the time. These types of people are those who spend a lot of time on social networks. In fact, our site is fully integrated with Twitter and Facebook expressly for that reason. Our target audience is people who are already using Facebook and Twitter heavily.
The key part of this logo is going to be a turtle. You can find the existing logo at AwkwardTurtle.com (currently redirects to AwkwardTurtle.me) as an example (but not as a guide.) (Or see attached.) That turtle, however, isn't doing much. He's just standing there. I want a turtle that is more appealing, cuter. He needs to be in the middle of something active, and that activity needs to make him seem awkward. Perhaps he's off-balance. Perhaps he's falling or swimming poorly. Be creative. Make me a turtle that is having issues. =) The idea is to illustrate the point of the site, which is that everyone has awkward moments and should be able to laugh at them. The turtle needs to be fun and whimsical. Most importantly, he needs to be a unique character. I may use him in many different parts of the site in different poses and such. The color scheme should match the existing site.
For the text, I'd like a font that is whimsical but not too goofy. Or, if you feel there is too much happening with the turtle himself, maybe anchor it with a plain font. It's really up to you! You're the creative one! =) It should only say "Awkward Turtle" but have the ability to tack a ".com" on the logo somewhere when used off-site. Also, please include the ® symbol as the phrase is my registered trademark.
Deliver in RGB format as AI or EPS files. NO COREL. Needs to be reproducible in black & white.
Find out how a design contest works or learn more about our logo design services.

subset: commoncrawl


text:
This project combines two of my favorite things: crayons and rockets. It may have taken John Coker 12 years to complete this project (hey, who among us hasn't had a case of lingering works-in-progress?) but the result was more than worth it. He's even included a step-by-step of how he made the rockets. The detail in matching the Crayola design is pretty impressive. I just want to know if he could find a way to add in that awesome Crayola smell. [via @DotatDabbled]
How-To: Build an 8-Pack of Crayon Rockets


text:
Each Wednesday, blogger Matt Vensel will highlight five statistics that really mean something for the Orioles.
five -- go-ahead home runs in the ninth inning or later for Adam Jones since the start of the 2012 season.
With one swing of the bat Sunday, Jones helped give the Orioles one of their biggest wins of the season. That two-run ninth-inning home run off New York Yankees closer Mariano Rivera, which gave the Orioles a 2-1 lead, was his seventh go-ahead home run in the ninth inning or later since 2009. That ties him with three other players for the most such home runs over that span, according to Elias Sports Bureau. In fact, it was his fifth such home run since the start of last season, which is also the most in Major League Baseball.
123 -- hits for Manny Machado through 91 games this season.
Machado on Tuesday night hit his seventh home run of the season, a solo shot in the third inning off Texas Rangers starter Martin Perez. It was his 123rd hit in 91 games, and yes, in the process he hit another of those young-man milestones. According to Elias Sports Bureau, Machado's 123 hits before the All-Star break are the most in MLB history by a player who was 20 or younger at the start of the season. But Machado celebrated a birthday over the weekend and is 21, so he now has a whole new set of milestones to swing for.
20 -- losses in which the Orioles have scored at least four runs.
The Orioles lost again Tuesday, their second straight loss and their sixth in the past eight games. The hitters gave the pitchers four runs to work with, but the Rangers won, 8-4. It was the third time in four days that the Orioles had scored at least four runs in a loss. And according to my colleague Eduardo Encina, it was the 20th such loss this season for an Orioles club that is fourth in baseball in runs scored. The starters have shown flashes, but they have a 4.85 ERA overall and haven't taken advantage of that run support as much as they should have.
eight -- strikeouts for Chris Davis and Matt Wieters on Monday.
In Monday's loss to the Rangers, Davis and Wieters did something that hadn't been done by a pair of O's teammates since 1989. But that's not necessarily a good thing. Davis and Wieters each struck out four times -- they call that the golden sombrero -- in the loss. Phil Bradley and Craig Worthington were the last pair of Orioles to do it, but in their defense, those strikeouts came in a game started by Nolan Ryan.
2.10 -- Eddie Gamboa's ERA in his final five starts in Double-A.
Gamboa, who converted to a knuckleball pitcher this spring, was recently called up to Triple-A Norfolk after a very successful five-game stretch for Double-A Bowie. In his final five starts with the Baysox, Gamboa had three scoreless outings of seven innings or more, including a seven-inning no-hitter June 30. He pitched 34 1/3 innings over those five starts and compiled a 2.10 ERA. After that, the Orioles had seen enough of Gamboa's new repertoire to know he was ready for the next step. Now the 28-year-old is one step away from the major leagues.
Bloggers note: Have a nifty stat you want to share? E-mail me at firstname.lastname@example.com or tweet at me at @mattvensel. If I use it, I'll be sure to give you a nice plug on the blog.


text:
Sweet Almond Oil 100ml
Pure Sweet Almond Oil is a highly nourishing oil which is light and easy to apply. It contains vitamins A, E, B1, B2, B6 and has a high percentage of mono and poly saturated fatty acids. A few drops can be added at bath time to moisturise and hydrate dry, sensitive skin. It protects and nourishes the skin and calms the irritation caused by eczema, relieving itching, soreness, dryness and inflammation.
Alternatively almond oil can be directly applied to affected dry areas such as cradle cap, behind the ears, joints and so on. It can also be used at nappy changing time and as a gentle, nourishing massage oil.
product details
product code: NB4025
- 100% pure Sweet Almond Oil
- cold pressed
- no parabens, petrochemicals, sulphates, synthetic fragrances or colours
- no animal derived ingredients, not tested on animals. GE Free
- suitable for the whole family
- suitable for all skin types unless there is a nut allergy
- ingredients: Prunus Dulcis (Sweet Almond Oil)
- made in New Zealand
- fragrance free
- 100% pure Sweet Almond Oil
delivery and returns
Free shipping on all orders over $150 (excludes oversized items)
For more information about our flat rates and delivery, please see our delivery page.
You are welcome to return online purchases within 30 days, click here to view the full Returns Policy.
why choose organic skincare?
Our botanical skincare range is formulated specifically for the intricate needs of mothers and babies.Inspired by traditional botanical ingredients that have stood the test of time, we have ensured only the finest active ingredients have been selected, utilizing organic methods cultivating, harvesting and processing to guarantee potency and purity.
read more


text:
- Eat & Drink
- News & Features
- Travel
- Culture
- Style
- Home
- City Life
- Scene
- Videos
- Search
- Events
- Cityguide
- The List
- Guide to Private Schools
- Weddings
- Charity Datebook
- Interiors California
- Daily Newsletters
- Best of Wine Country
- Timepiece & Jewelry Book
Our Publications
- Aspen
- Atlanta
- Boston
- Chicago
- Dallas
- The Hamptons
- Hawai'i
- Houston
- Las Vegas
- Los Angeles
- Miami
- New York
- Orange County
- Palm Beach
- Philadelphia
- San Diego
- San Francisco
- Scottsdale
- Silicon Valley
- Washington, D.C.
Brooks Brothers & St. Jude Holiday Event
Brooks Brothers and special guests hosted its first ever San Francisco holiday celebration at its flagship store in Union Square to benefit St. Jude's Research Hospital. At this festive fete, 400 guests enjoyed bites, cocktails and mocktails by PlumpJack Catering; hip beats by DJ Oscar Adler, the thirteen year-old son of famed music producer, Lou Adler; and family activities including photos with Santa, cookie and ornament decorating, and balloon art. Adding to the night's celebration, special guests Modern Family's Jesse Tyler Ferguson and husband, Justin Mikita, actress Abigail Spencer and actors Josh Pence and Colton Haynes, stopped by to lend support to St. Jude by making cards for St. Jude patients and encouraging attendees to do the same. 10% of the evening's sales were donated to the charitable organization.
Photos by Drew Altizer


text: Hey guys, I am just graduating from school with a Bachelors in computer science and I have a good working knowledge of C++. I went out looking for some programming jobs and it seems that a lot of companies are looking for C# programmers. I was wondering if you had any tutorial sites or books to recommend me taking a look at to learn.


text:
You may be able to get assistance with travel costs when you begin to work. If you take public transportation, you may receive a one-time free monthly bus or train pass from NJ TRANSIT. You may also be eligible for an additional six months of bus or train passes: the first three months are free and you pay only one-half the cost for the second three months.For more information, contact your County Welfare Agency
For more information, contact your County Welfare Agency


text:
IRVINE — The UC Irvine women's basketball team failed on Wednesday to gain inspiration from Jack Taylor's prolific performance the night before.
Taylor, a sophomore guard for the Grinnell College men's team, made national news by scoring an NCAA-record 138 points on Tuesday. He made 52 of 108 field-goal attempts, including 27 of 71 three-point tries.
The Anteaters, who dropped a 62-52 nonconference home game to Denver on Wednesday at the Bren Events Center, might be hard-pressed to post those kinds of numbers in a week.
UCI (0-4) shot 34% from the field (18 for 53) to lift its season shooting proficiency to 29.6%. The Anteaters matched their season scoring average and junior point guard Jennifer Tsurumoto scored 10 points to mark only the fourth time this season that a UCI player has reached double figures.
"We got more going offensively tonight than we have the previous three games," said first-year coach Doug Oliver, whose UCI team seized leads of 6-0 and 12-7, only to succumb to a Pioneer outfit that posted its first victory in four contests this season. "For the most part, we are taking good shots, but we just can't get them to go in."
UCI found enough flow to finish the first half on a 7-0 run and Tsurumoto hit a three-pointer to open the second half to pull the hosts within 34-30.
A layup by freshman Mokun Fajemisin capped an 8-0 run that pulled UCI within 43-42 with 10:48 left. But Denver scored the next six points and was never challenged again.
"It's another learning experience," Oliver said. "But learning and losing is not a good combination."
UCI senior Kelly Meggs hit two early three-pointers, but then went cold until connecting again from threedom with 1:17 left. She finished with nine points, five rebounds and five assists, but was three of 10 from the field to typify her team's shooting struggles.
The 5-foot-6 Tsurumoto missed 10 of her 14 field-goal tries, but some of those came when a dwindling shot clock left her little recourse but to attack taller defenders. She also had a team-high seven turnovers.
UCI had more points from beyond the arc (18) than in the paint (16) and Denver managed a 38-36 rebounding advantage.
Both teams came in with 52 turnovers and both committed 16, at times casting a sloppy tone to a contest attended by 208.
Juniors Camille Buckley and Lauren Spinazze, as well as Fejemisin, had eight points apiece for UCI, which also began last season 0-4. Spinazze, who had a pair of three-pointers, was the only UCI player to make more field-goal attempts than she missed (three for five).
Denver sophomore Morgan Van Riper-Rose had a game-high 21 points, including five three-pointers. The Pioneers netted nine of 26 from threedom, while UCI was six for 23 from beyond the arc.
UCI senior Jazmyne White, who had season-ending knee surgery last year after only 15 games, made her debut this season and was in the starting lineup. But, according to plan, Oliver said, White played just seven minutes, collecting two points and two rebounds.
"She'll play a couple minutes in both of our games this weekend [Drake on Friday and George Mason on Saturday at the New Mexico State tournament]," Oliver said of White, a former Big West Conference Freshman of the Year.
UCI, which has gone nearly two years without a nonconfernce road win, returns home Dec. 5 against Idaho.
Denver 62, UC Irvine 52
Den – Wirth 4, Michel 3, Van Piper-Rose 21, Smith 12, Johnston 7, Neuhaus 5, Janecek 4, Edwards 2, Hunter 2, Bradley 2.
3-pt. goals – Van Riper-Rose 5, Smith 2, Johnston 1, Neuhaus 1.
Fouled out – None.
Technicals – None.
UCI – Buckley 8, White 2, Onogomuho 1, Tsurumoto 10, Meggs 9, Spinazze 8, Fajemisin 8, Bernard 4, Hanson 2.
3-pt. goals – Meggs 3, Spinazze 2, Tsurumoto 1.
Fouled out – None.
Technicals – None.
Halftime – Denver, 34-27.
Twitter: @BarryFaulkner5


text:
Baby boys Number 1 romper
Scuderia Ferrari Store Exclusive
Particular care has been given to even the smallest of details of this Number 1 baby designed to resemble the racing suit of a Ferrari driver.
This new item in the Scuderia Ferrari baby clothing collection is a joyous ode to the racing world. Inspired in every detail by the actual racing suits of the House of Maranello drivers, the Number 1 romper for newborns is made of cool interlock cotton and comes with a cute cap, an all-over print recalling the design of the helmet. The baby romper features "Number 1" written just below the must-have yellow Shield. The romper and bonnet come with a red bag made of perforated fabric with a silk ribbon.
- Water-based print
- Nickel-free buttons
- Opening in the back and at the crotch
- Composition: 100% Cotton
We offer both Standard and Express shipping: choose the service that best meets your needs at checkout.
We provide an easy return service: just ship your items back to us with a shipping service of your choice within 30 days of delivery.


text:
These may look like your grandma's needle point but they are in fact made entirely out of paint! Mixing a pixilated kind of neo-impressionist pointillism with the idea of textile weaving, Caroline Larsen's paintings are beautifully simple and yet hard to figure out. Her technique with oil paint is so expertly peculiar her viewer can be tempted to spend their time simply trying to figure out how she does it; this however, is a mistake, because her technique, impressive as it is, is fused to her subject matter in an inseparable way. Although her work balances formal interests with subjective ones, she invests fully in her imagery, culling series from her lived experience and most tenacious memories. Her current exhibition at Angell Gallery, P.A.N.A.M.A. R.E.N.A., records a strange and
menacing number of massive cargo ships, seen by the artist on her travels, notably in the Panama Canal. Reduced by her painting to pattern, surface and color but sacrificing little in terms of ability to reference the world (with all of its implications of economic and
environmental issues), these works are finally, simply of transportation machines hugely beyond our human scale. What they are about is the way those things affect us when we confront them.


text: Ledgers of a general store in Ashfield, Massachusetts, record accounts with numerous women. They appear producing hats for store credit, as well as for selling eggs, cheese, and butter. As these accounts cover a long period of time (from 1824 to 1879), one can follow the change in the transactions. While the palm-leaf hat industry changes dramatically and almost dies out in the 1860s, the women continue to bring their eggs and dairy products to the store for credit.


text:
NEWPORT BEACH — Local boutique winery owner Gus DeFalco's low-cost wines have something in common with the big-dollar bottles produced in California's established wine-making regions: the same grapes.
DeFalco owns Orange Coast Winery, which opened in April. He gets his grapes — about 4,000 pounds per vineyard harvest — from growers in Napa, Sonoma, Amador, Santa Barbara, Paso Robles, Mendocino, Santa Maria, Lodi and other swaths of California's wine country.
His varietals average $12 to $24 per bottle. He said he uses high-grade cork, stainless steel and oak barrels, and other materials similar to those used by recognized winemakers in his process.
"The most difficult part is to get great vine growers to sell their grapes to small boutiques like myself," DeFalco said.
"I've been graced with their grapes, you could say," he added with a laugh.
Some of the vineyards DeFalco buys from for his 2,500-square-foot winery on West 16th Street in Newport Beach are recorded as having produced grapes more than 110 years ago, he said.
DeFalco's enthusiasm for wine dates back to his childhood in Canada.
The Toronto native's affinity for the vine began when his whole family would gather to make several barrels of wine. The family would purchase shipments of California grapes.
DeFalco would take the grapes home from the train station to make the wine by hand in the basement of a relative's home.
"It was always a party," DeFalco said of yearly activity, which brought close to 30 members of his family together. "I just never grew out of it. It is such a fun process."
DeFalco still looks at winemaking as a social occasion. When the grapes arrive at the Newport winery, he invites friends to join "crushing" parties.
While a machine takes care of the de-stemming, wine-making still requires a lot of manual labor, he said.
"The way I look at it, it's like gardening," DeFalco said. "Why grow roses? I want to grow tomatoes. I want to have something that I can invite people over to share in with me."
Orange Coast Winery hosts weekend tastings, parties and has plans for a slew of educational events including pairings classes, cooking with wine and cheese-making courses.
The winery also offers a wine club, but DeFalco plans to cap membership at 200 people to keep the events intimate and fun.
"We're not a bar or a restaurant, we're a winery," DeFalco said. "Being able to do the events and the wine education is what we want to do. It's half the fun of the business."
And whether you're a wine expert or a novice, if you buy $75 bottles or $10 bottles, in the end there's just one key lesson for everyone, DeFalco said.
"The only thing that matters is how the wine tastes to you, because my palate is going to be different than your palate," DeFalco said. "And who cares about price if that's what you like."


text: To provide you with unrestricted use of Total Egypt Website, it is necessary to set cookies. Some of these cookies require your express consent. Please agree to the use of cookies, so that you can enjoy full access to all functions on the website. For detailed information on the use of cookies on this website, please click on More Information. Here you can also revoke your consent to the use of cookies.


text:
After traveling nearly three hours, the members of the Glendale Panthers 14-and-under boys' basketball team found themselves on the biggest stage — the 24th rendition of the California States Games in San Diego.
The Panthers sought the gold medal for the first time, but their bid fell a shot short. Instead, Glendale grabbed the silver medal for the first time in 14 years.
"It was just a great experience for the players, kind of like a mini Olympics," said Glendale Coach Mike Hailey, whose team suffered a 36-33 loss to favored San Luis Obispo on July 22 in the division's championship contest at Miramar College. "Their mouths were wide open to be a part of something like that.
"Getting the silver medal isn't too bad and they had a lot of fun."
Glendale reached the championship game after posting a 54-50 overtime victory against San Luis Obispo on July 21. In the title game, Hailey said the Panthers endured San Luis Obispo's physical play throughout. Glendale's Arman Atomyan made four three-pointers for a team-high 12 points and teammates Carl Mehrabian and Argin Sarkisian scored eight points apiece to stay close.
Atomyan made a three-pointer with 20 seconds left to bring Glendale to within 35-33. San Luis Obispo then made a free throw with five seconds remaining to make it 36-33, but Glendale's attempt to knot the game didn't come to fruition.
"We started out shaky and I think we expended our energy just to get there," Hailey said. "SLO readjusted and we made some changes and it came down to the last shot."
Atomyan said the state tournament proved to be a challenge.
"I'm very proud that we did well and got a medal," said Atomyan, who will attend Hoover High in the fall. "In the last game, we were ready to go and they were favored to win.
"We almost took it. You are going up against some of the best teams around and we nearly got the gold medal."
Glendale reached the championship game after rallying from an 11-point deficit in the second half to defeat San Luis Obispo the first time the teams played in the double-elimination format.
The Panthers began the tournament July 20 with a pair of games before attending the opening ceremonies at Qualcomm Stadium in front of nearly 20,000 spectators.
The Panthers started with a 45-35 loss against the San Francisco Hoops before regrouping three hours later to register a 57-32 victory against the San Diego Black Mambas. Danny Madden and Pedrum Ghaibi led the Panthers with 11 points each. Mehrabian collected nine points for the Panthers, who got eight points and eight rebounds from Sarkissian, six points from Argam Aghajani and five points from Ian Mocorro.
Glendale then recorded a 40-27 win against the Corona Lakers on July 21. Andre Hovsepian paced Glendale with 15 points. Mehrabian added eight points and seven rebounds for Glendale. Madden scored six points and Sarkisian added six points and 12 rebounds.
After claiming five second-place trophies and one third-place showing this summer, the Panthers finally notched a tournament win on Sunday when they defeated the Santa Ana Aztecs to win the Big City Sports Bash at the Beach in Huntington Beach.
Sarkisian led the way with 20 points and five rebounds. The Panthers also notched wins against the Seal Beach Magic and West Covina Lights Out.


text:
KILL DEVIL HILLS, N.C. — A strengthening Hurricane Arthur forced thousands of vacationers on the North Carolina coast to abandon their Independence Day plans while cities farther up the East Coast rescheduled fireworks displays threatened by rain from the storm.
Arthur strengthened to a Category 2 hurricane Thursday night, its winds strengthening to 100 mph before it made landfall near the southern end of the Outer Banks. Little change was expected in the storm's strength Thursday night and Friday, and Arthur was expected to weaken as it travels northward and slings rain along the East Coast.
The annual Boston Pops Fourth of July concert and fireworks show was rescheduled for Thursday because of potential heavy rain from Arthur, while fireworks displays in New Jersey, Maine and New Hampshire were postponed until later in the weekend.
Arthur reached land late Thursday between Cape Lookout and Beaufort, N.C., near the southern end of the Outer Banks, a 200-mile string of narrow barrier islands with about 57,000 permanent residents.
The islands are susceptible to high winds, rough seas and road-clogging sands, prompting an exodus that began Wednesday night.
Among the tourists leaving Hatteras Island were 27-year-old Nichole Specht and 28-year-old Ryan Witman of Lancaster, Pa. The couple started driving at 3:30 a.m. Thursday on North Carolina 12, the only road on and off Hatteras.
"We were just saying we were really, really lucky this year that the weather was so great, and then this," Specht said as she ended a two-week vacation.
Many island residents, meanwhile, decided to ride out the powerful storm rather than risk losing access to homes connected to the mainland by a highway prone to washouts.
"All the people that I know who live here are staying put," said Mike Rabe, who planned to stay in his Rodanthe home despite an evacuation order for surrounding Hatteras Island.
In the last hours before the hurricane's approach late Thursday, Lena Lines helped to move furniture from the basement to the first floor of the home she shares with her parents to save it from possible flooding. They live in a complex of canals and sound-front homes in the shadow of a memorial to the Wright Brothers, who made the first powered flight in Kill Devil Hills.
If you live in that neighborhood, "it's undeniable, you're going to get flooded" during a storm like this, Lines said.
Dave Gillis, who does maintenance work at Harris-Teeter grocery stores, was attaching sections of galvanized sheet metal over the glass wall at the entrance of a Kill Devil Hills location just as rain started to fall sporadically at 10:30 pm.
"We're just getting to it," he said. "We've had a pretty busy day."
The departures of vacationers left things "pretty dead" on Hatteras Island during the normally bustling run-up to the Independence Day weekend, Rabe said. He spent Thursday running errands and helping neighbors prepare their homes for the storm.
Before the storm hit, tourism officials had expected 250,000 people to travel to the Outer Banks for the holiday weekend. Gov. Pat McCrory sought to strike a balance between a stern warning to vacationers and optimism that part of the busy weekend could be salvaged.
"Of course, this holiday weekend, the July 4th weekend, is one of the biggest weekends for coastal tourism in the state, and we anticipate a beautiful weekend after the Tropical Storm Arthur or the Hurricane Arthur is out of North Carolina," he said.
Arthur, the first named storm of the Atlantic season, prompted a hurricane warning for much of the North Carolina coast. On the Outer Banks' Ocracoke Island, accessible only by ferry, a voluntary evacuation was underway.
Among those leaving the island was the Unmussig family of Midlothian, Va. They cut their vacation two days short when they left Thursday morning in an SUV towing a trailer filled with bicycles and kayaks.
"Our cottage was right on the sound and we didn't want that back-current surge coming in and flooding us out," said Donald Unmussig, 50.
"I just didn't want to risk getting caught there. I have to work Monday morning. I didn't want to be late," he added. "We just decided to cut the losses and go home."
Tropical storm warnings were also in effect for coastal areas in South Carolina and Virginia and as far north as Cape Cod, Mass.
On the Massachusetts island of Nantucket, no evacuations were planned, but residents who have lived through many a fierce storm said they know better than to totally relax.


text: > > http://www.storage.ibm.com/hdd/ipl/oem/tech/pfa.htm > > > >A (sic) periodic intervals, PFA's Generalized Error Measurement (GEM) > >automatically performs a suite of self-diagnostic tests which measure > >changes in the disk drive's component characteristics." which is a GREAT feature. > So I read the URL and don't see what this feature buys you on Linux why do you think there's some OS specificity? afaikt, the results would be reflected in SMART, which is most definitely available under Linux. > Even if PFA is a plus, why must gathering the information > require the generation of such an awful sound? seeking is inherently noisy. fast seeking is inherently noisier than slow seeking. many (most?) drives nowadays have an alternate mode that trades slower seeks for quieter operation, though its common to turn this off for obvious reasons. but if the disk is trying to measure its own seek performance, it's not too surprising that it tries fast seeks. I'm guessing that the only thing that needs to be tuned here is how often the drive looks for measurements. obviously, if you keep it fairly busy doing real work, it shouldn't need to do PFA-specific seeks nearly as much. similarly, if it's idle, it should probably do unsolicited seeks fairly infrequently, since there's little chance of spontaneous degredation.


text:
Dog Breeds
Dogs for Sale
Adopt a Dog
Dog Friendly
Dog Breeds
Adopt a Dog
Dog for Sale
Sign in
Sign up
All Featured Breeds
Dog Breeds
Hound Largest Dog Breeds
Irish Wolfhound
The dog breeds is important when you want to buy or adopt a dog. Walk across the dog breeds profiles that we collected and see the introduce,the story and everything about the dog breeds.
Irish Wolfhound
Scottish Deerhound
Sponsored Links
Sponsored Links
Popular Breeds List
Large Dogs that don't Shed
Medium Dogs that don't Shed
10 Dog Breeds That Shed the Least
Small Dogs that don't Shed
More Breed List
Sponsored Links
Privacy Policy
Terms of Service
Contact US
About US
© DogTheLove, 2016 - 2018 Beijing Jiesenjuli Limited


text:
The rocket launcher comes from a Monogram kit, and the German Kettenfraftkad and troops are from Tamiya. I made the walls and rocks from hydrocal and the vegetation from Woodland Scenics foam and a Walther's tree. I believe the barbed wire is a Verlinden productg. I constructed solid walnut base from wood I had milled to hold a piece of 5/8 inch plywood base and accomodate a 1/4-thick plastic cover.
In January 2006 this diorama was donated to Brown University's Anne S. K. Brown Military Collection at the invitation of its curator [GPL].
Airplanes World War II Scenes and Dioramas


text:
2D Imager Bluetooth Barcode Scanner/NFC/MSR SmartSled®
The KDC400 series works with all major smartphones and tablets to collect barcode, NFC, and MSR data. The KDC425N Bluetooth barcode scanner may be attached to a smartphone or tablet case (sold separately) for fast and convenient use. A Built-in 1200mAh rechargeable battery can be used as an external power source for smartphones.
KOAMTAC's innovative Bluetooth® technology and user friendly design allows users to upgrade the smartphone periodically while maintaining the KDC400 series system.
The KDC® was the world's first MFi-certified Bluetooth barcode scanner by Apple®, and comes with FREE KTSync® software and SDK for Android, Blackberry, iOS (iPad, iPhone, iPod touch), Mac OS X and Windows devices. KTSync® includes a keyboard wedging feature and application generation tool.


text:
Subscribe To Minute To Win It Review: Fieri Shines As Host Updates
I've already subscribed
I'm thinking that people are either going to love NBC's new game show Minute to Win It or else, not get it at all. The series has contestants attempting to complete random tasks in under a minute for a chance to win a cash prize. Successfully completing the task gives them the opportunity to advance to the next tier and try for more money.
Ever tie a cherry stem into a knot using only your tongue? If so, you might be the perfect person to participate in Minute to Win It. The series is a show that showcases games that require little to no skill and in some cases, just a bit of luck. Using items commonly found in the average household, the tasks the contestants are set to perform do get progressively harder. In the episode I saw, a woman had to use air from a balloon to knock plastic cups off a table. In another task, she had to roll marbles at an upright-standing pencil in an attempt to knock it over. While the clock ticked away, she rolled marble after marble at the pencil and in the end, we were treated to an instant replay of the "event."
It would be almost too easy to rip the show apart on the basis of the lameness of the games, but I have a feeling there will be an audience for this. While some people prefer game shows that include questions they might know the answer to or that require some semi-advanced level of physical skill, this show's going to cater to people who like seeing silly tricks performed or are perhaps looking for some new games to bring to their next family party.
Minute to Win It's strongest attribute is its host, Guy Fieri. Fieri, who's known for hosting his Food Network show Diners, Drive-Ins and Dives, brings a level of enthusiasm to the series that nearly sells the show as being this amazing, suspenseful game show, not unlike Who Wants To Be A Millionaire (in its earlier years, anyway). Fieri's friendly banter with the contestants and excited reactions to their performances is admirable, given the tasks being performed. And while I give him credit for bringing the most to the hosting gig, I'm still not sold on the show just yet.
Is Minute to Win It going to be the next Deal or No Deal? In terms of the level of skill that goes into it, very possibly. I'm not claiming that its easy to get an Oreo from your forehead to your mouth using only your facial muscles but from a viewers perspective, it's about as exciting as watching a contestant pick out suitcases. And its family friendly, which I'm sure will appeal to people looking for something they can watch with their kids on Sunday night.
Minute To Win It premieres Sunday, March 14 on NBC (7-9 p.m. ET) on NBC.


text:
In the graphic arts management major, you will gain a broad technical knowledge of graphic arts and hands-on experience with modern printing processes and equipment. Your degree will prepare you with the technical and managerial skills you need for a professional career in the dynamic and diverse graphic arts and printing industry.
You will learn about all aspects of printing and have opportunities to use some of the same printing equipment used in the industry. Your classes will cover topics like:
You'll also complete a required minor in business administration to gain the supervision and management skills you'll need to advance to senior-level positions.
The mission of the graphic arts management major at Ball State University is to prepare individuals for technical and management oriented careers in the dynamic field of graphic communications.
The goal of our program is to prepare professionals who:
Rene Church
Hans Kellogg
Alan Leduc
Renmei Xu


text:
Via Andrew Marchand, the Yankees have decided to shut top pitching prospect Manny Banuelos down for the rest of the season in hopes of getting him healthy in time for winter ball. The 21-year-old southpaw has thrown just 24 innings this year due to a minor back problem and a non-structural elbow injury that VP of Baseball Ops Mark Newman described as a bone bruise.
"He'll recover from this," said Newman. "That's what our doctors say. We have no doubt about it. At this point, there is no reason to push it. We are trying to be as prepared as we can for next season." The Yankees could sent Banuelos to the Arizona Fall League, but that's a rough environment for a young pitcher. A trip home to Mexico or one of the other Latin American winter leagues could be in order, assuming the elbow actually heals up at some point. A few weeks ago we heard that Banuelos was on a throwing program.