I own one of the great miracles of the modern age -- a filter pitcher. While this has made my life much more enjoyable, there's a flaw inherent in the design of the pitcher I have.
The problem is the filter insert seals the top of the pitcher, except for the spout. This is fine, until you try to pour at full tilt. When water leaves the pitcher through the spout, a vacuum is formed inside and air is sucked back in. Pouring is slow and uneven when this happens.
We can fix this by adding a vent. A small hole drilled into the back of the pitcher allows air to enter and the pitcher to empty faster.
Brita Slim Filter Pitcher
Fix what's broken.
Update: I've received many comments about the orientation of the insert. When in the "proper" orientation, the insert wants to come off with the cover when opened and then blocks part of the spout. I use the tab now to hold the insert in.
The first thing to know is you can't assume a client browser will accept gzipped content. We need to check the request headers for something like this:
Each of the options below does this in some way or another.
One option is to use mod_deflate. This causes CPU overhead, and is not supported by many shared webhosts because of it. So we can't distribute an application assuming we can use mod_deflate. Deflate compresses files as they are requested.
To use mod_deflate, you'd add something like this to your config or htaccess:
A second option is to use MutliViews in mod_negotiation. MultiViews allows Apache to choose a file based on the browser's request headers and is designed to specifically support different encoding and languages which a client browser claims to support. This method allows to you pre-compress your files and avoid the overhead associated with on-the-fly compression.
To use mod_negotiation to handle gzip, you'd add something like this to config or htaccess:
AddEncoding x-gzip .gz
You'd create two versions of each file:
Then, in your application, you'd link to non-existent file:
But, as you can tell, if MultiViews isn't enabled for some reason, the application will request the file "myscript.js" and since the file doesn't exist (and cannot exist, or else MultiViews won't try and find the correct file), we get a 404 and the application breaks. If you're distributing your application across multiple server types and configurations, your application will just plain break. This also won't work if a browser doesn't support the English language (should be very rare).
The third and most appealing option is to use mod_rewrite and combine the best of the first two methods, pre-compression and conditional file responses.
To use mod_rewrite to handle gzip, you'd add something like this to config or htaccess:
The mod_rewrite configuration checks the client headers for gzip support then checks to see that the .gz version of the file exists before rewriting the request for the .gz version. AddEncoding ensures the gzip content encoding header is sent to the browser. The ForceType directives make sure the proper content type is sent to the browser for the .gz extensions.
Then you'd create two versions of each file (you don't have to do this for all files, just the most compressible):
rblspy is an irssi script that checks a list of DNSRBLs for hosts that join a channel. If that host matches, the match can be announced to the channel, reported to the client or automatically banned with a short knockout (to prevent filling the banlist). This script is designed to assist in managing abuse from anonymous proxies.
Encoded IP usernames from web clients
Having been in many situations where the Windows environment I was working in was secured from external file transfer, I've devised a few methods for transferring binary files without the need of physical drives or network connections. Such environments are found in kiosks, POS terminals, Citrix/RDP/VNC/etc. remote terminals and other "thin" clients.
I'm gonna show you some methods of exploiting functionality not often thought of as useful for attackers in hardened environments using plain text encoding.
Tip:If the target environment has a working unzip/decompress application like that built into Windows XP/Vista, compress the binary before encoding it.
Outlook Express/Windows Mail
E-mail applications use MIME to attach non-text files to messages. This feature can be used locally to encode files into a plain text format (usually base64). Here's how to transfer a binary file with the keyboard:
1. In the source environment, compose a new e-mail message.
2. Change the message format to Plain Text, this will reduce clutter in the file.
3. Attach the binary file you want to transfer.
4. In the File menu, choose "Save As...". Save the file as the Mail (*.eml) type.
5. Open the saved .eml file in Notepad to view the contents.
6. Open Notepad in the target environment and copy the contents of the saved .eml file.
7. Save the file with a .eml extension.
8. Open the .eml file with OE/WM.
9. Right-click the attachment and choose "Save As...".
Caveat:OE/WM restricts access to executable files from attachments by default. Adjust the security settings or rename your file if necessary.
Windows Scripting Host
The Windows Scripting Host gives access to components which are capable of taking plain text encoded data and saving it as a binary file.
For example, this pair of scripts will hex-encode a binary file to a plain text file and back:
Some remote terminal environments like RDP support copy and paste operations, but most won't -- namely Citrix MetaFrame (or whatever they call it these days). A great way to manipulate this keyboard/mouse only interactivity is to run a WSH script in the host environment. The following script reads a file and types it into the target environment:
Tip:Useful binary files small enough to be typed into an environment are hard to come by. Compile your own.
You may not be able to attach a USB Mass Storage Device, but it's highly likely your target will allow you to attach USB HID (Human Interface Device) or PS/2 keyboard. Both use a standard Windows driver and would not require elevated privileges to install.
It's simple to create hardware devices that emulate HID or PS/2 devices. Encoded files can be loaded onto a microcontroller and "typed" for you.
Schematics and source code for such a device may show up here eventually.
Notepad missing? Windows has some other options like wordpad/write.exe, edit.com, web browsers.
In some cases you may need to encode certain HTML entities to prevent the browser from parsing them. Also be cautious of how the browser saves the file. The browser might attempt to change CR/LF to whitespace or save the file as Unicode which can create parsing problems.
It seems a requisite for a secure environment is a read-only filesystem.