Saturday, March 8, 2008
at
9:53 PM
|
As explained in Why are ads displayed on this site?, most of the pages on this site display text ads from Google's AdWords program. To display these ads, a site must join Google's AdSense program. Joining is free, but not all sites are eligible to join. Once you're accepted, however, it's very simple to place the ads on your pages and to start generating revenue for your site. AdSense will serve ads that are generally very relevant to the content of a particular page. Here are some tips based on my experiences so far with the AdSense program. Tip #1: Don't put ads on empty pages. When I reworked my site, I built a skeleton set of pages that had no content, just titles and some meta tags. I displayed ads on those pages, however. Although all you see are public service ads at first, the very act of displaying ads on a page causes the AdSense web crawler to quickly fetch that page for analysis. A page with good content will thus begin showing relevant paying ads fairly quickly. If you don't have any content, then, Google will have to guess as what your page is about. It may guess wrong, and so the ads that it displays may not be relevant. You'll have to wait until Google re-crawls the site for the ads to correct themselves. Here is what Google had to say when I asked them about how often the AdSense crawler updates a site: | Thank you for taking the time to update your site. New ads will start appearing on your site the next time our crawler re-indexes your site. Unfortunately at this time, we are unable to control how often our crawlers index the content on your site. Crawling is done automatically by our bots. When new pages are added to your website or introduced to the AdSense program, our crawlers will usually get to them within 30 minutes. If you make changes to a page, however, it may take up to 2 or 3 weeks before the changes are reflected in our index. Until we are able to crawl your web pages, you may notice public service ads, for which you will not receive any earnings. | It's better to flesh out the page before you start displaying ads on it. Tip #2: Don't be afraid to ask questions If you're wondering about something, don't be afraid to ask Google. So far, they've always responded to my questions within a working day. There are two email addresses to use, depending on the type of question: Their responses are always very polite, and they appreciate getting problem reports and suggestions. Tip #3: Avoid non-English characters on English pages This one is a bug, to be honest. My surname is French, and I prefer to write it out correctly with the accent grave on the first "e". Every page on my site would then include at least two accented letters, because my name shows up twice in the footer. On some pages my name shows up two or three more times. Normally, this wouldn't be an issue. But on some pages the presence of the accented characters is enough to cause AdSense to display non-relevant ads in French. This happens whether the browser indicates a preference for French or not. When I reported this to Google, this is the answer they gave me: | Hello Eric, Thank you for bringing this issue to our attention. We are currently working as quickly as we can to address this problem. As soon as we have more information for you, we will email you again. We appreciate your patience. Sincerely, The Google Team | Until this is resolved, I've decided to strip out all accents except on the pages that are actually in French. Tip #4: Check your keyword density Although Google doesn't release exact details as to how they determine the ads to serve on a given page, they do tell us that it's the text content of the page that matters, not the meta tags. Before serving ads on a page, then, you might want to check its keyword density. A good, free tool for doing this is found here: http://www.ranks.nl/tools/spider.html
This lets you fine-tune the page before exposing it to the AdSense crawler.
Posted by
admin
Labels:
Info IT
Netfilter is a framework that provides a set of hooks within the Linux kernel for intercepting and manipulating network packets. The best-known component on top of netfilter is the firewall which filters packets, but the hooks are also used by other components which perform network address translation, stateful tracking and packet enqueueing to user space. The name Netfilter also refers to the name of the project that provides a set of firewalling tools for Linux. These components are usually loadable kernel modules, although the project also offers a set of userspace tools and libraries. Backward compatibility support for ipchains has been recently removed.
iptables is the name of the user space tool by which administrators create rules for the packet filtering (both inbound and outbound) and NAT modules. While technically iptables is merely the tool which controls the packet filtering and NAT components within the kernel, the name iptables is often used to refer to the entire infrastructure, including netfilter, connection tracking and NAT, as well as the tool itself. iptables is a standard part of all modern Linux distributions.
History
The netfilter/iptables project was started in 1998 by Rusty Russell, also author of the project's predecessor, ipchains. As the project grew, he founded the Netfilter Core Team (or simply coreteam) in 1999. The software they produced (called netfilter from here on) is licensed under the GNU General Public License (GPL), and was merged into Linux 2.3 in March 2000. In August 2003 Harald Welte was made chairman of the coreteam, and in April 2004, following a crack-down by the project on those distributing the project's software embedded in routers without complying with the GPL, Welte was granted a historic injunction by a German court against Sitecom Germany who refused to follow the GPL's terms (see GPL-related disputes). In September 2007 Patrick McHardy, who led development for past years, was elected the new chairman of the coreteam.
Prior to iptables, the predominant software packages for creating Linux firewalls were ipchains in Linux 2.2 and ipfwadm in Linux 2.0, which in turn was based on BSD's ipfw. Both ipchains and ipfwadm alter the networking code so they could manipulate packets, as there was no general packet-control framework until netfilter. iptables preserves the basic ideas introduced into Linux with ipfwadm: lists of rules which each specified what to match within a packet, and what to do with such a packet. ipchains added the concept of chains of rules, and iptables extended this further into tables: one table was consulted when deciding whether to NAT a packet, and another consulted when deciding how to filter a packet. In addition, the three points at which filtering is done in a packet's journey were altered, so any packet only passes through one filtering point.
Whereas ipchains and ipfwadm combine packet filtering and NAT (particularly three specific kinds of NAT, called masquerading, port forwarding and redirection), netfilter makes it possible to separate packet operations into three parts: packet filtering, connection tracking, and Network Address Translation. Each part connects to the netfilter hooks at different points to access packets. The connection tracking and NAT subsystems are more general and more powerful than the stunted versions within ipchains and ipfwadm.
This split allowed iptables, in turn, to use the information which the connection tracking layer had determined about a packet: this information was previously tied to NAT. This makes iptables superior to ipchains because it has the ability to monitor the state of a connection and redirect, modify or stop data packets based on the state of the connection, not just on the source, destination or data content of the packet. A firewall using iptables this way is said to be a stateful firewall versus ipchains, which can only create a stateless firewall (except in very limited cases). It can be said that ipchains is not aware of the full context from which a data packet arises, whereas iptables is, and therefore iptables can make better decisions on the fate of packets and connections.
iptables, the NAT subsystem and the connection tracking subsystem are also extensible, and many extensions are included in the base iptables package, such as the iptables extension which allows querying of the connection state mentioned above. Additional extensions are distributed alongside the iptables utility, as patches to the kernel source code, along with a patch tool called patch-o-matic.
A version of iptables for IPv6 was written, called ip6tables after the name of the administration tool.
Operational summary
The netfilter framework allows the system administrator to define rules for how to deal with network packets. Rules are grouped into chains—each chain is an ordered list of rules. Chains are grouped into tables—each table is associated with a different kind of packet processing.
Each rule contains a specification of which packets match it and an optional target that specifies what to do with the packet if it is matched by that rule. Every network packet arriving at or leaving from the computer traverses at least one chain, and each rule on that chain attempts to match the packet. If the rule matches the packet, the rule's target dictates what to do with the packet. If a packet reaches the end of a predefined chain without being matched by any rule on the chain, the chain's policy target dictates what to do with the packet. If a packet reaches the end of a user-defined chain without being matched by any rule on the chain or the user-defined chain is empty, traversal continues on the calling chain (implicit target RETURN). Only predefined chains have policies.
Rules in iptables are grouped into chains. A chain is a set of rules for IP packets, determining what to do with them. Each rule can possibly dump the packet out of the chain (short-circuit), and further chains are not considered. A chain may contain a link to another chain - if either the packet passes through that entire chain or matches a RETURN target rule it will continue in the first chain. There is no limit to how many nested chains there can be. There are three basic, predefined chains (INPUT, OUTPUT, and FORWARD) in the "filter" table, and the user can create as many as desired. A rule can merely be a pointer to a chain.
Connection trackingOne of the important features built on top of the netfilter framework is connection tracking. Connection tracking allows the kernel to keep track of all logical network connections or sessions, and thereby relate all of the packets which may make up that connection. NAT relies on this information to translate all related packets in the same way, and iptables can use this information to act as a stateful firewall.
Connection tracking classifies each packet as being in one of four states: NEW (trying to create a new connection), ESTABLISHED (part of an already-existing connection), RELATED (related to, but not actually part of an existing connection) or INVALID (not part of an existing connection, and unable to create a new connection). A normal example would be that the first packet the firewall sees will be classified NEW, the reply would be classified ESTABLISHED and an ICMP error would be RELATED. An ICMP error packet which did not match any known connection would be INVALID.
The connection state is completely independent of any TCP state. If the host answers with a SYN ACK packet to acknowledge a new incoming TCP connection, the TCP connection itself is not yet established but the tracked connection is - this packet will match the state ESTABLISHED.
A tracked connection of a stateless protocol like UDP nevertheless has a connection state.
Furthermore, through the use of plugin modules, connection tracking can be given knowledge of application layer protocols and thus understand that two or more distinct connections are "related". For example, consider the FTP protocol. A control connection is established, but whenever data is transferred, a separate connection is established to transfer it. When the nf_conntrack_ftp module is loaded, the first packet of an FTP data connection will be classified RELATED instead of NEW, as it is logically part of an existing connection.
iptables can use the connection tracking information to make packet filtering rules more powerful and easier to manage. The "conntrack" match extension allows iptables rules to examine the connection tracking classification for a packet. For example, one rule might allow NEW packets only from inside the firewall to outside, but allow RELATED and ESTABLISHED in either direction. This allows normal reply packets from the outside (ESTABLISHED), but does not allow new connections to come from the outside to the inside. However, if an FTP data connection needs to come from outside the firewall to the inside, it will be allowed, because the packet will be correctly classified as RELATED to the FTP control connection, rather than a NEW connection.
iptables
iptables is a user space application program that allows a system administrator to configure the netfilter tables, chains, and rules (described above). Because iptables requires elevated privileges to operate, it must be executed by user root, otherwise it fails to function. On most Linux systems, iptables is installed as /usr/sbin/iptables and documented in its man page [1]. This simple example of its use illustrates how to redirect all traffic on the default HTTP port, port 80, to port 8080, allowing the HTTP daemon to run as a non-privileged user, unable to listen on port numbers below 1024.
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
Note: if you launch this command on your computer it will only work for external IP addresses connecting to your machine. Connections from localhost do not traverse the PREROUTING chain in the "nat" table. If you want this feature to also work, use another rule:
iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080
which reroutes packets on the loopback (lo) interface from port 80 to port 8080.
ipset
ipset is used to set up, maintain and inspect so called "IP sets" in the Linux kernel. An IP set usually contains a set of IP addresses, but can also contain sets of other network numbers, depending on its "type".
Any entry in one set can be bound to another set, allowing for sophisticated matching operations.
ipset supports the following set types:
* ipmap - The ipmap set type uses a memory range, where each bit represents one IP address.
* macipmap - The macipmap set type uses a memory range, where each 8 bytes represents one IP and a MAC address.
* portmap - The portmap set type uses a memory range, where each bit represents one port.
* iphash - The iphash set type uses a hash to store IP addresses.
* nethash - The nethash set type uses a hash to store different size of network addresses.
* ipporthash - The ipporthash set type uses a hash to store IP address and port pairs.
* iptree - The iptree set type uses a tree to store IP addresses, optionally with timeout values.
A set can only be removed (destroyed) if there are no iptables rules or other sets referring to it.
Posted by
admin
Labels:
Info IT,
Security
|
|
