MySQL optimization (I)

When MySQL is installed by a software packages manager such as yum or aptitude, we get instantly a valid database server ready to work.

It turns out that installation is performed with a series of settings applied by default, which are not the most optimal for our system in most cases, since there are many more variables (memory, CPU, other services configured, etc.) that we have to consider.

Therefore, it is the best that once the databases have been created, to leave a margin large enough time (for example a couple of days) to make the system stable and to be able to acquire its real work load.

In that moment , we can apply any sort of MySQL optimization or tunning tool, such as MySQL Performance Tuning Primer Script or MySQLTuner.

Then we are going to use the first tool on a Zabbix 1.8.1 installation, utilizing CentOS 5.4 64 bits with a MySQL 5.0.77 database.

[root@centos ~]# ./tuning-primer.sh

Using login values from ~/.my.cnf
- INITIAL LOGIN ATTEMPT FAILED -
Testing for stored webmin passwords:
None Found
Could not auto detect login info!
Found Sockets: /var/lib/mysql/mysql.sock
Using: /var/lib/mysql/mysql.sock
Would you like to provide a different socket?: [y/N]
Do you have your login handy ? [y/N] : y
User: root
Password:

Would you like me to create a ~/.my.cnf file for you? [y/N] :

-- MYSQL PERFORMANCE TUNING PRIMER --
     - By: Matthew Montgomery -

MySQL Version 5.0.77 x86_64

Uptime = 2 days 0 hrs 53 min 41 sec
Avg. qps = 19
Total Questions = 3375129
Threads Connected = 15

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10 sec.
You have 0 out of 3375150 that take longer than 10 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 0
Current threads_cached = 0
Current threads_per_sec = 1
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 15
Historic max_used_connections = 21
The number of used connections is 21% of the configured maximum.
Your max_connections variable seems to be fine.

INNODB STATUS
Current InnoDB index space = 112 M
Current InnoDB data space = 240 M
Current InnoDB buffer pool free = 0 %
Current innodb_buffer_pool_size = 8 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 75 M
Configured Max Per-thread Buffers : 274 M
Configured Max Global Buffers : 17 M
Configured Max Memory Limit : 292 M
Physical Memory : 1.96 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 71 K
Current key_buffer_size = 7 M
Key cache miss rate is 1 : 6
Key buffer free ratio = 81 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is supported but not enabled
Perhaps you should set the query_cache_size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 4 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 1024 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 64 tables
You have a total of 105 tables
You have 64 open tables.
Current table_cache hit rate is 0%
, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 85195 temp tables, 31% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 0 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 0 : 3375450
Your table locking seems to be fine

When we run the second tool, we pick up the following information:

[root@centos ~]# ./mysqltuner.pl

>>  MySQLTuner 1.0.1 - Major Hayden <major@mhtx.net>
>>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
>>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.77
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive +BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in InnoDB tables: 240M (Tables: 88)
[!!] BDB is enabled but isn't being used
[OK] Total fragmented tables: 0

-------- Performance Metrics -------------------------------------------------
[--] Up for: 2d 0h 56m 0s (3M q [19.168 qps], 23K conn, TX: 530M, RX: 331M)
[--] Reads / Writes: 69% / 31%
[--] Total buffers: 34.0M global + 2.7M per thread (100 max threads)
[OK] Maximum possible memory usage: 309.0M (15% of installed RAM)
[OK] Slow queries: 0% (0/3M)
[OK] Highest usage of available connections: 21% (21/100)
[OK] Key buffer size / total MyISAM indexes: 8.0M/67.0K
[!!] Key buffer hit rate: 85.3% (239K cached / 35K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 14K sorts)
[!!] Temporary tables created on disk: 31% (38K on disk / 123K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (64 open / 9K opened)
[OK] Open file limit used: 0% (0/1K)
[OK] Table locks acquired immediately: 100% (3M immediate / 3M locks)
[!!] InnoDB data size / buffer pool: 240.7M/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
Add skip-bdb to MySQL configuration to disable BDB
Enable the slow query log to troubleshoot bad queries
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Set thread_cache_size to 4 as a starting value
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (>= 8M)
tmp_table_size (> 32M)
max_heap_table_size (> 16M)
thread_cache_size (start at 4)
table_cache (> 64)
innodb_buffer_pool_size (>= 240M)

In the next two article, we will see how to fit these values.

IT security audits

At the moment to audit a computer system, there are three kinds of audits:

Black box audit. It is the sort of audit most difficult of all; it is carried out from the external network of the architecture to be audited, for instance from Internet. The auditor has got little data (usually, public IP addresses or URLs) and he has to use different techniques to attempt to access the system (Google hacking, social engeneering, scanning open ports and analysis of vulnerabilities, penetration tests, etc.)

This type of audit does not assure that a system will be absolutely secure, since there can be services which are properly protected through right perimeter security policies.

Grey box audit. In this sort of audits, the analysis is performed from the own internal network of the infrastructure to be audited. Unlike the black box audit, the auditor is connected to the internal network (he has not already to worry about evading the external network elements - routers, firewalls, security appliances, etc.) and therefore, he will have greater visibility about the differents devices which can be found inside.

Through various hacking techniques (inventory of equipments and services, internal traffic captures, analysis of vulnerabilities, intrusion tests, etc.), the auditor's goal will be obtaining administrative privileges of the most of the infrastructure elements.

White box audit. This type of audit is also made from the own network to be audited, but in contradistinction to the previous, the auditor will have credentials of the systems (normal user and administrator accounts), as well as the more detailed information of the architecture (it should be provided by the audited organization).

Therefore, the target of this type of audit will be looking into the configurations of the different services and systems, in order to look for possible anomalous situations (not updated software, weak passwords, malware infections, etc.) which depend on their own local security architecture. To do this, the auditor will be able to have tools provided by the own vendors, as well as other applications available in the market, which always try to realize a full system check.

From all this can be concluded that the three kinds of security audits which have been explained are complementary each other, because although the black box audit provides us a more generic view of how a supposed hacker would act, we must know that this person will not stop when he has achieved access for example to the web server, but that he will also attempt to gain access to the rest of systems.

White box audits supply us a more detailed information about the local security of the different devices, and they are usually the most requested audits by the companies, since they can prevent for example that the own or former employees of the company can make malicious tasks.

And why do companies often require white box audits and no grey box? The response is very simple: it is a time question that the auditor who is connected to the internal network of the company can get users credentials capturing network traffic. So just what is wanted is a time saving for both parts.

And finally it is also important to remind that securing an infrastructure does not mean that you have to set many security elements at the input point of Internet, but that it will be necessary to apply correct local security policies (network segmentation, strong passwords, antivirus, security patches, etc.).

System monitoring with top

Probably the most important tool for any Linux systems administrator is top, which has got an interface that provides a real time view of the main events that are happening in the system, such as CPU consumption, memory, processes state, etc.

[root@centos ~]# top
top - 11:29:56 up 53 min,  1 user,  load average: 0.16, 0.05, 0.05
Tasks: 136 total,   1 running, 135 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.5%us,  0.6%sy,  0.0%ni, 98.2%id,  0.5%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   2059768k total,   352036k used,  1707732k free,    21248k buffers
Swap:  4095992k total,        0k used,  4095992k free,   207520k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
3057 root      15   0 12732 1004  716 R  2.0  0.0   0:00.01 top
1 root      15   0 10344  672  560 S  0.0  0.0   0:00.45 init
2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0
3 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
5 root      10  -5     0    0    0 S  0.0  0.0   0:04.19 events/0
6 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 khelper
23 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kthread
27 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kblockd/0
28 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
85 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 cqueue/0
88 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 khubd
90 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kseriod
154 root      25   0     0    0    0 S  0.0  0.0   0:00.00 pdflush
155 root      15   0     0    0    0 S  0.0  0.0   0:00.03 pdflush
156 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kswapd0
157 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 aio/0
298 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 kpsmoused
...

We have a first line where the two most important data are the time that the machine is on (11:29:56 up) and the average number of system processes (load average) which have been waiting for any system resource (CPU, disk access, network, etc.) during the last 1, 5 and 15 minutes.

Then there is a data block where are showed the overall features of the system:

Tasks indicates the processes number which are up, where some of them will be able to be in running, sleeping, stopped or zombie state.

Cpu(s) shows the CPU use, by both the user (%us) and the system (%sy), as well as the percentage of CPU idle (%id).

Mem indicates the distribution which is being done of the RAM memory, offering the total amount available (total), the memory currently in use (used), the free memory (free), the buffers used (buffers) and within the total memory used, how much is cached (cached).

Swap shows the distribution of swap memory, providing the total amount available (total) and the part which is being used (used).

The other block of information presented by top is a set of columns with information about each process.

• PID: process ID number.


• USER: user name who has run the process.


• PR: process priority.


• NI: process priority change.


• VIRT: amount of virtual memory for process (including all code, data and shared libraries - if you have N instances of the same program running at the same time, the context of the application will be only once in memory). VIRT = SWAP + RES.


• RES: total physical memory (RAM) used by the process.


• SHR: amount of memory that can be shared with other processes.


• S: process status; D (sleeping and interruptible), S (sleeping), T (stopped) and Z (zombie).


• %CPU: percentage of CPU usage.


• %MEM: percentage of physical memory usage.


• TIME+: total CPU time used by the process.


• COMMAND: application which has run the process.

There are other fields associated with the tasks which are not displayed by default by top. If you want to view them, first you must press the 'f' key in order to see all available fields, and then press the key associated with the field to be added (e.g. 'p' key for SWAP).

Also say that the column values displayed by top can be ordered according to the memory (shift + m), PID (shift + n), CPU (shift + p) and the total CPU time used by the process (shift + t).

Finally also say that sometimes we can get that almost all physical memory is in use, but to sort the processes by memory, do not add the total amount of memory used. At this moment we will must look at the cached field, since in this way we will be able to see that the operating system is caching part of that memory, and the fact that a system caches memory is really the optimal situation.

Google hacking

Google stores a large amount of information in their databases related with all the websites indexed on Internet. We can consult those indexes at a given time to localize specific information.

The term Google hacking is refered to the fact of using certain searches, as well known as queries, to detect or find different types of information, such as hidden directories, sensitive data, passwords, credit card numbers, vulnerabilities, exploits, etc. These actions can be made through Google search or other applications based on this search engine.

For example, to locate websites that offer directory listings we can use the next query:

intitle:"index.of"

If we are examining a concrete website to look at whether it has got some hidden directory, we can also add the URL:

intitle:"index.of" site:redes-privadas-virtuales.blogspot.com

Handle these techniques correctly is very important to develop a good security audit, since this form we can find and revise security breaches that can be used by an attacker.

intitle:"index.of" (inurl:temp | inurl:tmp | inurl:private | inurl:admin)

intext:(password | passcode | pass) intext:(username | userid | user)

allinurl:”exchange/logon.asp”

filetype:c exploit

“Microsoft-IIS/5.0 server at”

We have been able to view that Google hacking is not an intrusive hacking method, since we can gather sensitive information without sending a single TCP packet against the target site.

There are lots of books written about the topic, and there is also a website named Google Hacking Database which contains many examples.