Unfortunately your HTML is completely out of order, and the images aren’t set to resize fluidly. In fact, it’s likely impossible to achieve more desirable gallery behavior without rewriting your HTML.
The reason your images appear the way the do is because they’re not wrapped in any container that’s interacting manageably with the other elements present on the page. In particular, your #front-page has an absolute position that’s giving the visual illusion that that it’s at the top of the document. It’s that same rule that’s forcing the images to ignore the #front-page. Unsetting it will make your design “break,” but it’s a necessary first step toward achieving what you want.
Here’s a working example of what (I assume) you’re going after. I suspect more complex media queries would yield a better result, but this is a starting point for a more maintainable document:
http://codepen.io/anon/pen/EjmmYB
Note that
<div class="mock-image"></div>
Represents an <img> tag that I was too lazy to add, but the behavior should remain the same for any 1:1 dimensioned image. As an added benefit, setting the padding of the <img> instead of the height will allow you to maintain consistent aspect ratios for images that aren’t 1:1.
edit
The rationale
Positioning
Keep it simple. By default elements are static-ly positioned in the document, and most layout elements are display: block, meaning they stack on top of one another. This is good. Converting them to relative has very few drawbacks, and often enhances default behavior (enabling z-indexing, among other things). If you notice, of the four elements that are direct children of <body> (<header>, .splash, .gallery, and <footer>), they’re all either static or relative. You don’t have to keep those class names, but I recommend keeping almost all elements either static or relative, with very few, specific exceptions. Certainly you should keep layout containers static or relative. Using position: absolute or fixed takes them out of the flow of the document, and this has very unintuitive consequences.
Containers
You’ll also notice that where there’s content (the .guts and .mock-image elements), that content is wrapped in containers (.splash and .gallery, respectively). Those containers are there to decrease complexity. Instead of having eight images butting up against the .splash, we only have one .gallery. It’s far more manageable to deal with two interacting elements than nine, and this is a simple case. Complexity will only grow from here. Additionally, they’re both set to width: 100%, meaning as long as they’re positioned relative or static, they’ll always stack on top of each other, which is exactly the kind of predictable behavior you want.
The gallery
An added benefit of setting the containers to width: 100% is that it scales with the window, meaning all percentage-based children (in this case your images) will scale with the window too. Typically you do want it to max out at some point (hence the .wrap with a max-width: 1000px), but up until that point, especially for galleries, this is the behavior you want. The @media query is a bonus: since 12.5% of a mobile screen is tiny (on an iPhone it would be only 40px by 40px), on smaller screen dimensions the media query sets images to 25% instead of 12.5%, resulting in an 80px by 80px image.
Since your thumbnails will only ever be at most 162.5px by 162.5px in this case, you also, as another poster said, want to crop them in an image editing program before you use them, otherwise you’re wasting crazy bandwidth.