Ben Callahan is the CEO of Sparkbox, a writer, a designer, and a speaker on the subject of Responsive Web Design. Ben was nice enough to sit down with Allison for an extensive interview on Responsive Web Design for the Gold Members of Treehouse. Lucky for us here on the blog, Ben recorded a gem about the value in sharing what you know.

The post Sharing What You Know – Interview with Ben Callahan appeared first on Treehouse Blog.

Glass apps will require people to create new content filters. Maybe that’s just a losing battle.

Would you want your daily horoscope beamed to your right eye? That’s the vision of the future I saw when I tried out the fashion magazine Elle’s app for Google Glass yesterday, one of several apps announced at the extravagant software developer love-fest the internet company puts on every year.

This is a terrific opportunity to learn about ethical issues related to research. Also, being a member of the IRB looks good on a curriculum vitae or resume. Please contact Dr. Susan Sonnenschein, IRB Chair, (sonnensc@umbc.edu) no later than June 7, 2013 if you wish to apply. Your email should include a copy of your curriculum vitae or resume and a few sentences describing your research interests and experience. We are particularly interested in people who have had research experience with human participants.

There are several firewall applications for Linux, but what you may not realize is that, at the heart of all these programs is a single all-mighty application that is built right into the Linux Kernel: iptables. This is the Linux firewall. No matter which program you use to configure your firewall under Linux, it ultimately all comes down to iptables. All that these other programs do is configure it.

So, here comes the question: if those programs simply configure iptables, why not simply configure it directly yourself? Doing so is easier than you might think!

Networking Background

If you’re familiar with networking terms, like connections, IP, TCP, and Port, then feel free to skip ahead to the next step. Otherwise, if you’re new to networking, read on to familiarize yourself with the terms that you will need to understand, in order to follow along with this tutorial.

Please note that the terms and definitions below have been intentionally over-simplified. They’re meant for every-day users, not sysadmins. So if you are a seasoned sysadmin or you have a CCNA in you pocket, please excuse me for not entering into the details.

TCP/IP

TCP/IP is a protocol that allows computers to communicate with one another over Internet and Ethernet Networks.

Failure is the last resort.

Imagine an Ethernet Network as a small local network (LAN – local area network), like your home PC, laptop, and smart phone. It’s a small heterogeneous network that is isolated from the rest of the world. A network of such networks is what we all know as the Internet: a set of interconnected networks.

TCP/IP is a combination of two protocols working at different levels in the hierarchy of the network communication chain. We won’t delve into details about that hierarchy. TCP stands for Transfer Control Protocol, and its core responsibility is to ensure that communication is successful. It controls the correctness of the data sent, and ensures its success. It has different algorithms to perform sophisticated checksums, autocorrect, and retry. Failure is the last resort. The name, IP comes from Internet Protocol. You can best associate it with the “phone-number” of your PC. Each machine capable of communicating over the Internet must have an IP address – a unique phone number – so that communication packets can find their destinations. A packet is a small piece of data inside a communication stream, which is self contained and can be checked for correctness. Essentially, we can say that our computers send TCP packets over the Internet using the IP protocol.

Each network communication is bound to a specific port. Network ports range from 0 to 2^16 (65536). Each network connection has an outgoing port for the one who initiates it, and an inbound port for the one who is listening for other computers’ messages. There can be several connections between several computers over identical ports. A computer can, however, talk over several ports at once. So, basically, ports are good to identify services and define channels of communications, but they do not limit the amount of data or connections.

Some computers can have similar IP addresses. You may have observed that both your computer at home and at work have IP addresses that takes the form of something along the lines of 192.168.something.something, or 10.0.something.something, or 172.16.something.something. These are the so-called private IP addresses that can be used only inside your LAN. You can’t go out to the Internet with IP addresses like this. They are akin to interior numbers for your company’s phone network.

Gateway & Bridge

A Bridge is what computers with real (public) IP addresses pass to the Internet.

Essentially, these computers have the rights and capabilities to talk to one another on the Internet directly. But, since there are no direct connections between all the computers in the world (that would be quite hard to accomplish), bridges are responsible for connecting segments of the Internet.

Keeping our telephony analogy alive, you can imagine these bridges to be similar to the telephone centers in your town or neighborhood. If you make a call to another local number (the computers on the left in our schema), the communication could have been made directly by your telephone center by physically connecting your line with you neighbor’s. However, if you instead want to call your distant uncle Bob, your call would have to be redirected over several phone centers until your uncle’s phone could be connected. These form a bridge between your town and his town.

A Gateway is a way for computers from a private network (LAN with private IP addresses) to communicate with other computers on the Internet.

A private network is like your company’s private phone network. You can call interior numbers, but in order to call someone who is outside of your company’s network – like your wife at home – you must first dial a special number or prefix.

Computers actually function in a similar way. When you are on a private network, you have a so-called gateway computer. When your computer attempts to talk to another computer on the Internet, it will automagically contact the gateway first and request “a line” to the outside world. The gateway will do the talking to the computer found on the Internet, and will forward the message back to your computer. You, as an ordinary user, see no difference between a bridge and a gateway. Your computer will know how to deal with them.

Definition of a Firewall

A firewall is a program running on a Gateway, Bridge or PC/Laptop/Smartphone that is capable of filtering incoming, outgoing, and forwarded network packets. A firewall is essentially a tool that lets you restrict you or your network’s access to the Internet, and someone else’s access from the Internet to your network.

And yes, your cable router or home Wi-Fi is, in fact, a firewall for all your computers and gadgets that connect to the internet through it.

The Problem We Will Solve

To set the context, let’s imagine a very possible network architecture. I’ve seen many small companies running something similar to this.

What we have here is actually something quite simple:

• A few computers and other network-connected devices – the green boxes
• An e-mail server – the red box
• A Microsoft Active Directory server – the blue box
• A gateway, which is also a firewall, for our network running Linux – the black box
• Between all of these is a simple network switch

In the following section, we will configure iptables on that gateway, so that it will allow all the devices in the network to connect to the Internet. It will allow us to connect to it, via SSH, and will allow external mail servers to reach the mail server inside our network – a computer that does not even have a public IP address; only a private one.

Iptables Components

Iptables’ name actually has a meaning in its functionality. It’s a set of tables of IP address and ports with some actions attached to them. In iptable’s terms, these tables are referred to as chains. An unconfigured, empty iptables might look like this:

csaba ~ # iptables -L
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         

You can observe that there are three main chains:

• INPUT – all incoming connections
• FORWARD – connections passing through
• OUTPUT – connections departing from this server

The term, “policy ACCEPT” in parenthesis means that ACCEPT is set as the default policy for that particular chain. So, when there is no match for a connection, that rule will be applied. There are three main concepts you can use when configuring your firewall:

• default policy ACCEPT & deny selectively all you need to – it may be difficult to specify all that it is denied. I do not recommend this approach.
• default policy DROP or REJECT & allow selectively all you need to – this is better, but it has a problem. If you make a mistake in your iptables configuration, you can easily remain with empty chains denying access to everything and everyone, including you. So, unless you always have physical access to your firewall server/computer, I recommend that you use the next approach.
• default policy ACCEPT & an explicit policy to DROP all & then allow selectively all you need – this is a combined solution between the first two possibilities. It will use an ACCEPT default policy, so if something goes wrong, you can log back over SSH or whatever remote connection you use for your firewall. At the same time, an explicit DROP rule for any unmatched connections ensures that you are safe. Allowing only what you know about and actually need to use offers the best possible protection.

Adding Rules to Iptables

There are two ways to add a new rule to iptables. One is to insert it at the begining of a chain. The other option is to append it to the end of a chain. Why does it matter in which order the rules occur?

You must design your rules in such a way to consider the above mentioned behavior of iptables. After the first match of a rule, iptables will take the actions specified by the rule, and then cease the search. If no rule matches the connection that is checked, the default policy applies.

Inserting a New Rule

Let’s say that we want to add a rule to our iptables that will allow anyone to connect to port 22 on our firewall. Port 22 is the port for the SSH protocol. Of course, a good server admin will change this port to something unexpected for obvious security/obscurity reasons, but that’s another story for another tutorial. We will stick with 22.

csaba ~ # iptables -I INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
    csaba ~ # iptables -L
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh

I presumed that the IP address facing the Internet with the public IP on it is on the network interface, called eth0. Let’s dissect this command:

• -I – stands for insert the rule
• INPUT – specifies the desired chain
• -i – stands for network interface – in our case, eth0
• -p – is for protocol (tcp or udp)
• –dport 22 – is for destination port 22 – it has a corresponding --sport version for source port verification
• -j – actually comes from “jump,” and is followed by an action -in our case, the action to accept the connection

However, you may have already guessed that this rule has little effect at this time. Our default policy is ACCEPT, so accepting something explicitly does not offer us any extra functionality. Now, remember the third recommended way to set up our firewall: the explicit rule to deny everything not matched. Let’s add that rule.

Appending Rules

We want to append a rule that blocks incoming traffic. But be careful: we only want to block what could be harmful. If we block everything, we will not be able to do anything, because the replies to our requests will be rejected. For example, when you browse a web page, you make a request, then you receive an answer. This answer comes into your computer, so, on the INPUT chain, we must have a rule to allow it.

First, we will append a rule to accept incoming traffic for already established connections, such as responses to requests.

csaba ~ # iptables -A INPUT -i eth0 -m conntrack  --ctstate ESTABLISHED,RELATED -j ACCEPT
    csaba ~ # iptables -L
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Now that we’ve safeguarded our existing connections and the replies to the connections we initiated, we can deny everything else that wasn’t matched.

csaba ~ # iptables -A INPUT -i eth0 -p tcp -j DROP
    csaba ~ # iptables -L
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
    DROP       tcp  --  anywhere             anywhere
    

We’ve appended another line, with a rule to DROP all connections that match. Remember: this rule will only apply if none of the previous ones actually match.

There are two ways to refuse a connections.

1. You can use DROP, which is equivalent to dialing a non-existent phone number with the difference that, after some time, the network connection times out. With a phone number, a robot informs you that the number does not exist. But the end result from the point of view of the caller is the same: it thinks that the destination does not exist.
2. The second way to refuse the connection is with the rule, REJECT, and an optional message. This is analogous to the number you are trying to call being busy. You may know that there is a number, you know it can be called, but it simply refuses to take your calls. Optionally, you can provide a message with a REJECT rule; the default is “ICMP port unreachable” or something similar.

Allow Computers to Access the Internet

At this point, we have some basic rules for the INPUT chain. But we have a network of computers having private IP addresses. We need to provide a gateway to the Internet. This is also done by iptables: the firewall.

Network Address Translation (NAT)

Likely, you’ve already heard this term: NAT. This refers to the procedure of translating one network address to another and forwarding the information between the two. It’s most frequently used in architectures like our own. The gateway has to do NAT in order to translate any computer’s IP from the LAN into its own public IP and then back.

Routing is the procedure by which a system can figure out on what network interfaces and toward what gateway it can communicate to reach its destination. Each computer has a routing table of its own to determine this. Iptables can hook into this routing procedure at two different points: before and after the procedure has occurred.

Nating with Iptables

csaba ~ # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 89.72.31.243

This command adds a rule as POSTROUTING to the NATing table (-t nat). POSTROUTING essentially means that the packets first pass the routing mechanism on the gateway, and, only after that are they modified. The rule -j SNAT means Source NAT; the source address of the packets will be changed to the address on the interface specified by -o eth0 – in our case, to the IP address specified by the option, --to-source. So, anyone contacted by a computer in your network will assume that it is talking directly to your gateway. It will have absolutely no clue about the fact that the packets are destined for some different computer. The gateway, using iptables, will keep an internal list of all the translated IP addresses, and, when a reply comes, it will revert the change and pass the answer to the computer inside the network.

Allow Client from the Internet to the Email Server

Another problem that we face is what to do when we have a server that is behind a firewall. We need to allow the clients, coming from the Internet, to communicate with our server in some way. This is the case with our mail server. When an email arrives that has to be delivered to a mail account on our server, the sending email server will have to connect to our receiving one.

But our mail server only has a private IP address. There is no way that an external computer could connect to it directly. On the other hand, our gateway has an external IP that anyone could connect to. The solution? Open a port on our gateway so that a request from the Internet to that port will actually go to our email server. The answer, of course, will travel through the gateway back to the client. The trick is to use a different type of NAT here, called Destination NAT. This changes the packets destination and then reverts them back when the response occurs. Think of DNAT as the reverse of SNAT.

csaba ~ # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 25 -j DNAT --to-destination 192.168.1.2:25

So, what is happening here? A packet comes in to our gateway at the port 25 (the port used for SMTP, the email protocol the whole Internet uses). The rule above catches this packet because of the --dport 25 option, which basically says, “Match anything that goes to this port on the interface specified by -i eth0. Now that the packet is matched, change its destination from the current machine (the gateway) to the one specified by --to-destination.” Please note that you can specify the port explicitly after the IP address by separating it with a colon.

Finally, note that this is in the PREROUTING hook. The destination has to be changed before the routing actually takes place. Otherwise, the packets would end up on the gateway and find no way to the mail server.

Persisting iptables Configuration

The rules you insert or append to iptables are in memory. After a reboot, spoof: everything is gone! To save your configuration, you should dump it into a file, like so:

csaba ~ # iptables-save > /some/directory/my_rules.fw

The file’s name doesn’t matter, nor does its extension. To restore the rules, run this command when your computer starts.

iptables-restor < /some/directory/my_rules.fw

If you take a look at the saved content, you’ll see that they’re the same parameters that we used with the iptables commands. There are some minor differences, but you can easily understand the saved file, and could even write your own such files by hand and load them.

Final Thoughts

In closing, here are some thoughts on when and when not to use a firewall with a Linux computer.

Use a firewall on Linux when you configure a server (like a gateway in our example), or when you have a computer with important information on it that is directly exposed to the Internet. Before you jump on to configure your iptables, consider the potential danger. Ask yourself: is my computer known on the Internet? There are a few billion computers out there. If yours is just one, the chance of being targeted is incredibly low. Are there people directly interested in your information? Hackers don’t waste time stealing random data in the hopes that they might find something. They usually know what they are looking for, and then target the computers containing the desired information. Of course, there are countless attacks against random computers that attempt to install some kind of worm or virus, but on Linux, you are immune by design.

Don’t waste your time with configuring a firewall on Linux when it is a computer that is alway behind a firewall, such as your home PC behind your home router, or when you have no particularly important information on your laptop. If you keep the services that listen on the network to a minimum and have a decently secure password, you can forget your firewall. I personally have no personal computer, laptop or smartphone with a firewall running. I have, however, a home router with a well-configured firewall.

I think you can safely apply these ideas to Mac OSX as well. If you’re a Windows user, sorry: a firewall is your first line of defense. For Linux or MacOSX, though, a firewall is your last line of defense. A carefully selected password and not running useless services should handle the bulk of your computer’s protection.

Thanks for reading. Questions?

This offer ends soon! Act now and don’t miss out on cash back when trying a monthly Tuts+ Premium subscription.

At $19 a month, Tuts+ Premium is fantastic value. But it’s even better when we hand your first $19 right back to you!

For a limited time, we’re offering $19 cash back to new Tuts+ Premium monthly subscribers when signing up via PayPal. If you’ve been thinking about checking out our extensive library of courses, tutorials, eBooks and guides there’s never been a better time to join up and dive in.

This offer ends at noon on the 20th of May AEST, so act fast.

Become a Tuts+ Premium Member and take your creative & technical skills to a new level.

Join now and get instant access to your very own library of courses, tutorials, and eBooks, available whenever you need them. Become part of a community of over 15,000 members and start getting better at the skills you care about. Our dedicated team adds new content weekly, so there’s always something fresh to sink your teeth into.

Join Tuts+ Premium

Among the many super nice design features of the Yahoo! Weather app for iOS is the transition between city screens. The background image doesn't just move away as the screen moves from one screen to the next, the background image itself slides. It appears to be hiding some of the "old" screen and revealing more of the "new" screen those closer you have it to being in full view.

Let's try and pull it off on the web.

The HTML

Like any slider, there are three main components:

• The container that holds everything into shape
• A sliding container that is as wide as all the slides in a row
• Each individual side container

We won't bother too much with content inside the slide. I'll just add the temperature to show each slide can indeed hold content on top.

<div class="slider" id="slider">
      <div class="holder">
        <div class="slide" id="slide-0"><span class="temp">74°</span></div>
        <div class="slide" id="slide-1"><span class="temp">64°</span></div>
        <div class="slide" id="slide-2"><span class="temp">82°</span></div>
      </div>
    </div>

The container might be a <section>, slides might be <article>. It really depends. I'll let you make the semantic choices for your own needs.

The layout plan is like this:

The CSS

The "slider" (visual container) and the slides need to have explicity the same size. We'll use pixels here but you could make it work with anything.

.slider {
      width: 300px;
      height: 500px;
      overflow-x: scroll;
    }
    .slide {
      float: left;
      width: 300px;
      height: 500px;
    }

Floating those slides to the left isn't going to make them line up in a row, because the parent element of the slides isn't wide enough to let them do that. That's one of the reasons we need the holder element. It will be 300% wide (Num. of slides × 100%) which will fit three slides exactly.

.holder {
      width: 300%;
    }

Each one of our slides has a unique ID. This is useful because, if we choose, we can create anchor links that link to those ID's and the slider will "jump" to those slides. We'll add JavaScript to do some actual "sliding", but our slider will work even without that. ID's make that possible, so let's use them here to drop in some lovely background images.

#slide-0 {
      background-image: url(http://farm8.staticflickr.com/7347/8731666710_34d07e709e_z.jpg);
    }
    #slide-1 {
      background-image: url(http://farm8.staticflickr.com/7384/8730654121_05bca33388_z.jpg);
    }
    #slide-2 {
      background-image: url(http://farm8.staticflickr.com/7382/8732044638_9337082fc6_z.jpg);
    }

With all this in place, our layout comes into shape:

The CSS (black fading)

Just as a small detail, the temperature set in white may be in danger of not being visible depending on the photo behind it. To ensure that it is, we can make the photo subtly fade to black toward the bottom. A pseudo element will do nicely.

.slide:before {
      content: "";
      position: absolute;
      bottom: 0;
      left: 0;
      width: 100%;
      height: 40%;
      background: linear-gradient(transparent, black);
    }

A picture explanation is in order here:

The JavaScript (background sliding)

We're going to use jQuery here because we love life. Our goal is the adjust the background-position of the slides as we scroll. We can set background-position in percentages in CSS, but that alone doesn't do the cool hide/reveal more effect we're looking for. Based the amount scrolled (which we can measure in JavaScript), we'll adjust the background-position. Alone, that would look something like this:

$("#slider").on("scroll", function() {
      $(".slides").css({
        "background-position": $(this).scrollLeft()/6-100+ "px 0"
      });  
    });

The "6" and "-100" in there are magic numbers. Not CSS magic numbers that are prone to frailty, but traditional magic numbers. Just some numbers that happen to make the effect work. A bummer, perhaps, but not that big of a deal. Design-y things are sometimes like that. Perhaps best to leave a comment in the code to that effect. These particular numbers are based on the images I used and their size and what looked good.

The effect here is the background shifting we're after:

The JavaScript (imparting structure)

That little snippet of JavaScript looks lonely up there without any structure behind it. A slider is a great excuse to look at a simple way to structure JavaScript.

We can make everything slider-related one object.

var slider = {
    
    };

Then we'll group up the related elements into one area, bind our events together, and write little functions that do very specific things.

var slider = {
      
      el: {
        slider: $("#slider"),
        allSlides: $(".slide")
      },
     
      init: function() {
        // manual scrolling
        this.el.slider.on("scroll", function(event) {
          slider.moveSlidePosition(event);
        });
      },
      
      moveSlidePosition: function(event) {
        // Magic Numbers
        this.el.allSlides.css({
          "background-position": $(event.target).scrollLeft()/6-100+ "px 0"
        });  
      }
      
    };
    
    slider.init();

The HTML (adding navigation)

Adding swipe stuff would be super (super) sweet (hint). But for now let's add little press-able links to change slides, rather than relying on the scrollbar. You might even remove the scrollbar in real life (straight up overflow: hidden; on the container). What we need is anchor links that link to the ID's of the individual slides.

<nav class="slider-nav">
      <a href="#slide-0" class="active">Slide 0</a> 
      <a href="#slide-1">Slide 1</a> 
      <a href="#slide-2">Slide 2</a> 
    </nav>

Style those as you will. For the demo, I make them little tiny gray circles with the text hidden.

The JavaScript (adding navigation)

Our structure is more useful now. We simply add a few more elements we're dealing with, add a new event we're watching for (clicks on nav), and write a little function to deal with that event.

We know how far to animate the scroll position when a nav link is clicked from the ID on the link itself. The link might be href="#slide-1", which we can get "1" from easily. Then the position we need to scroll to is (1 × width of slide), so 300 in our case. We'll store that 300 value right in the JavaScript.

var slider = {
      
      el: {
        slider: $("#slider"),
        allSlides: $(".slide"),
        sliderNav: $(".slider-nav"),
        allNavButtons: $(".slider-nav > a")
      },
      
      timing: 800,
      slideWidth: 300, // could measure this
      
      init: function() {
        // You can either manually scroll...
        this.el.slider.on("scroll", function(event) {
          slider.moveSlidePosition(event);
        });
        // ... or click a thing
        this.el.sliderNav.on("click", "a", function(event) {
          slider.handleNavClick(event, this);
        });
      },
      
      moveSlidePosition: function(event) {
        // Magic Numbers
        this.el.allSlides.css({
          "background-position": $(event.target).scrollLeft()/6-100+ "px 0"
        });  
      },
      
      handleNavClick: function(event, el) {
        // Don't change URL to a hash, remove if you want that
        event.preventDefault();
    
        // Get "1" from "#slide-1", for example
        var position = $(el).attr("href").split("-").pop();
        
        this.el.slider.animate({
          scrollLeft: position * this.slideWidth
        }, this.timing);
        
        this.changeActiveNav(el);
      },
      
      changeActiveNav: function(el) {
        // Remove active from all links
        this.el.allNavButtons.removeClass("active");
        // Add back to the one that was pressed
        $(el).addClass("active");
      }
      
    };
    
    slider.init();

We have an "active" class on the nav links just to use in CSS to visually indicate which slide is active. We handle that by removing "active" from all links and then adding it back to the one that was clicked.

Demo!

Check out this Pen!

Slider with Sliding Backgrounds is a post from CSS-Tricks