Mysidia
Sunday, February 22, 2009
Untangle
For small networks, I recently became aware of a new firewall/web filter option for Linux, it's called Untangle.
What I love most about this product, is although it's based on Linux, it's a cinch to setup, and administration is a breeze. It has many features like Snort you want on your gateway, in a standard format suitable for most very small networks, but in the past always required a lot of manual Linux config file editing and command line work to setup and maintain.
There are other software appliances for Linux, but few inexpensive ones have good as a user interface. And fewer still provide web filtering and a decent block list, and software updates out of the box, for free.
For 90% of small networks, pfSense, or Untangle will be great. The free version is nothing to sneeze at.
Untangle have some professional options, commercial addons, for advanced policy config, which are downright cheap, compared to competitors like Smoothwall. We're talking prices on the order of $50 a month or so, for 50 users.
When prices like annual $1000 or so are common, for a tenth the number of features available.
Needless to say, i'm very impressed. ¶ 11:34 AM 0 Comments
What I love most about this product, is although it's based on Linux, it's a cinch to setup, and administration is a breeze. It has many features like Snort you want on your gateway, in a standard format suitable for most very small networks, but in the past always required a lot of manual Linux config file editing and command line work to setup and maintain.
There are other software appliances for Linux, but few inexpensive ones have good as a user interface. And fewer still provide web filtering and a decent block list, and software updates out of the box, for free.
For 90% of small networks, pfSense, or Untangle will be great. The free version is nothing to sneeze at.
Untangle have some professional options, commercial addons, for advanced policy config, which are downright cheap, compared to competitors like Smoothwall. We're talking prices on the order of $50 a month or so, for 50 users.
When prices like annual $1000 or so are common, for a tenth the number of features available.
Needless to say, i'm very impressed. ¶ 11:34 AM 0 Comments
Saturday, February 21, 2009
A hotspot logging format
This logging format is intended to be a compact notation usable for equipment and software implementing wireless hotspots (Wi-Fi) allowing remote user access, DHCP servers, etc, to keep long-term records of addresses assigned.
The goal is to be a lightweight compact format, suitable for keeping the info in archives for 2 years as may be required in the US by pending legislation.
The format should be a binary format, as compact as possible.
Each record should be of a fairly uniform size, but future extensibility should be provided for.
The following is a 256-bit record format.
All integers are represented in the network byte order.
Values are padded up to the required length with NUL bits inserted to the right.
The first 4 bits are used to indicate record type and version. In a standard record, they should be all set to 0 presently.
The next 4 bits are reserved for future use, and always set to 0, until future versions.
The next 4 bits indicate "action", (i.e. Lease = 0000, Un-lease = 0001)
The next 4 bits are reserved for a "hardware address type", all bits are 0 for Ethernet
The next 4 bits are reserved for "assigned address type", use the IANA address family number
The next 48 bits are for a "hardware address".
The next 33 bits are the "action" timestamp, which is an offset in seconds since the UNIX epoch, Jan 1, 1970 00:00:00
The next 24 bits are for "longevity" in minutes, i.e. DHCP lease duration. An infinite lease is recorded as all bits "1".
The next 128 bits are for "assigned address data"
The next 3 bits are a simple checksum
By recording events using a binary logging format, the storage requirements are drastically reduced over text-based logging formats.
Automated searching and archiving also becomes much easier.
The number of records that need to be generated can be minimized in a home network environment by using a fairly long lease duration, say one week.
A DHCP server can retain a hash table in memory and on disk that points Ethernet hardware addresses to the proper log position for the past lease.
When a lease is requested, the hash table is first searched for the hardware address.
If found, the existing log entry is loaded, and the lease entry is extended, instead of generating a new identity log, the assigned address is the same.
However, the hash table entry must be purged if a lease is allowed to expire and a new lease assigns the IP address to a different hardware address.
Also, if the host releases the lease, or goes offline, an 'unlease' record should be generated, or the lease duration should be shortened to indicate the proper duration according to a system clock reliably sync'ed to a trusted time source.
Renewals are effectively the same as increase in the original lease duration.
Some applications might like to record a new entry altogether, even for such lease extensions, and a log reader application must be prepared to accept either behavior.
Shorter record formats might be defined to indicate inactivity of a hardware address.
In a home environment, there are fewer hardware devices, and a hash table and lease-duration update strategy makes sense, and allows for a minimal amount of storage to record the identity assignment history of all IP addresses with no loss of data.
In a public hotspot, there are many hardware devices, and it is more optimal to simply use an archival log and plenty of storage.
Still, the storage requirements are not huge.
100,000 full-sized event records can fit within 3 megabytes of storage.
For a 2 year retention period, this allows for 136 address assignment events per day,
or 5 per hour.
In a home environment, this is ample, particularly if long lease durations are used, so addresses rarely need to be assigned, and with IPv6 on the LAN, the lease assignments can be permanent with no danger of subnet exhaustion.
Especially, when we consider a variety of compression schemes can be used to further reduce storage requirements. ¶ 2:54 PM 0 Comments
The goal is to be a lightweight compact format, suitable for keeping the info in archives for 2 years as may be required in the US by pending legislation.
The format should be a binary format, as compact as possible.
Each record should be of a fairly uniform size, but future extensibility should be provided for.
The following is a 256-bit record format.
All integers are represented in the network byte order.
Values are padded up to the required length with NUL bits inserted to the right.
The first 4 bits are used to indicate record type and version. In a standard record, they should be all set to 0 presently.
The next 4 bits are reserved for future use, and always set to 0, until future versions.
The next 4 bits indicate "action", (i.e. Lease = 0000, Un-lease = 0001)
The next 4 bits are reserved for a "hardware address type", all bits are 0 for Ethernet
The next 4 bits are reserved for "assigned address type", use the IANA address family number
The next 48 bits are for a "hardware address".
The next 33 bits are the "action" timestamp, which is an offset in seconds since the UNIX epoch, Jan 1, 1970 00:00:00
The next 24 bits are for "longevity" in minutes, i.e. DHCP lease duration. An infinite lease is recorded as all bits "1".
The next 128 bits are for "assigned address data"
The next 3 bits are a simple checksum
By recording events using a binary logging format, the storage requirements are drastically reduced over text-based logging formats.
Automated searching and archiving also becomes much easier.
The number of records that need to be generated can be minimized in a home network environment by using a fairly long lease duration, say one week.
A DHCP server can retain a hash table in memory and on disk that points Ethernet hardware addresses to the proper log position for the past lease.
When a lease is requested, the hash table is first searched for the hardware address.
If found, the existing log entry is loaded, and the lease entry is extended, instead of generating a new identity log, the assigned address is the same.
However, the hash table entry must be purged if a lease is allowed to expire and a new lease assigns the IP address to a different hardware address.
Also, if the host releases the lease, or goes offline, an 'unlease' record should be generated, or the lease duration should be shortened to indicate the proper duration according to a system clock reliably sync'ed to a trusted time source.
Renewals are effectively the same as increase in the original lease duration.
Some applications might like to record a new entry altogether, even for such lease extensions, and a log reader application must be prepared to accept either behavior.
Shorter record formats might be defined to indicate inactivity of a hardware address.
In a home environment, there are fewer hardware devices, and a hash table and lease-duration update strategy makes sense, and allows for a minimal amount of storage to record the identity assignment history of all IP addresses with no loss of data.
In a public hotspot, there are many hardware devices, and it is more optimal to simply use an archival log and plenty of storage.
Still, the storage requirements are not huge.
100,000 full-sized event records can fit within 3 megabytes of storage.
For a 2 year retention period, this allows for 136 address assignment events per day,
or 5 per hour.
In a home environment, this is ample, particularly if long lease durations are used, so addresses rarely need to be assigned, and with IPv6 on the LAN, the lease assignments can be permanent with no danger of subnet exhaustion.
Especially, when we consider a variety of compression schemes can be used to further reduce storage requirements. ¶ 2:54 PM 0 Comments
Sunday, September 07, 2008
Once again FF3 brings in this dangerous IDN feature
That can be used by phishers.
Naturally, to disable about:config
Click the "I'll be careful, I promise!" button, to that silly FF message about "This might void your warranty!" . o O ( What warranty? )
type: network.enableIDN into the filter
find the line that says "network.enableIDN default boolean true"
double click to change it to "user set boolean false"
*poof* we're done. Closing the IDN security hole that keeps coming back every time a clean
install of FF is done.
Will they never learn ? ¶ 9:24 AM 0 Comments
Naturally, to disable about:config
Click the "I'll be careful, I promise!" button, to that silly FF message about "This might void your warranty!" . o O ( What warranty? )
type: network.enableIDN into the filter
find the line that says "network.enableIDN default boolean true"
double click to change it to "user set boolean false"
*poof* we're done. Closing the IDN security hole that keeps coming back every time a clean
install of FF is done.
Will they never learn ? ¶ 9:24 AM 0 Comments
Sunday, July 13, 2008
anti-cheat for multiplayer games
The ultimate anti-cheat measure for PC games will be a dedicated OS for playing the game.
The "installer" would place binary blobs in C:\program files\vendor\gamename.
The files would be loaded to self-patch the game during boot, but otherwise, the game runs entirely from RAM. Any swap file or data written to a hard drive must be encrypted.
These files would only hold any 'saved data' and digitally-signed patches to the
game image. The game can only be played in multi-player mode by booting the
computer from CD.
The CD would boot the system into the game's dedicated OS.
Completely contained in RAM.
The first stage of the bootloader would verify the integrity of the digitally-signed
OS files on the CD/DVD, and verify that the data is actually being read from an internal
CD drive, and not a USB stick.
It would be responsible for verifying that it was running on real hardware, and not a
virtual machine, and writing back encrypted hardware information to a binary blob.
Any detected attempt to operate the game on say virtual hardware, or specifically
banned hardware, results in permanent
deactivation written to the binary blobs, which the user is not notified about until the last
boot stage (After information about the "deactivation for hacking" is uploaded to
the manufacturer's game servers, to ensure merely "restoring some files from backup"
won't reverse the deactivation).
First OS
would also be responsible for verifying that the C:\ directory containing game patches
resides on an ATA, SATA, or SCSI drive, verifying that the Serial number, volume serial,
and make on the drive matches data in an encrypted header file (in the binary blobs),
proving the files have not been moved to a different drive.
(It is not permissive to restore to a new drive from backup, the software must be reinstalled.)
(The hard drive and other hardware verifications would be repeated at each OS loading
stage, upon any detection of hardware change, and every 30 minutes or so, during gameplay)
The verifications would be at independent codepoints, so a hacker patching the binary would
have more trouble finding all the different places where the verification is done in a different
way.
Next the first "binary blob" would be loaded into the RAMDISK and the patch applied to the game binary. Each blob would be provided by the manufacturer and contain a patch to the game binary.
Patches to the loader OS other than the game binary would be done, but would have to be digitally signed.
The individual patches are signed only with a SHA256 sum, but the binaries being patched have not been started yet.
Each _entire_ patched codebase (game binary, os binary) is signed, and the codebase's SHA256 sum is contained in a binary data blob. The digital signature and then the SHA256 sums will be verified before the second OS, or the game binary is started.
Both OSes will repeat the same verification and load only binaries with a properly-signed digest.
After all digital signatures are verified, the loader OS transfers control to the "second game OS"
(the fully patched OS that has all features such as networking support, that the game will be run under)
The second OS will immediately connect to the game server to upload some feedback
about the verification process: all encrypted with a server's public-key and tied to the
customer's serial number, a special "product key", IP address, and MAC addresses of all NICs:
if there was an attempt to hack something, successful or not, the blob of information will probably indicate it.
(Because the information uploaded will provide many details about the environment, hardware, and even unusual elements not part of the "verify to boot" process)
Periodic binary patches would be released to the game _just_ to move key areas of the
OS and game code around, and adjust protocols, to keep cheaters having to constantly
re-hack the code, if they ever figured out Version X: Version X+1 will be coming out in a few
weeks.
This doesn't need to be done manually: a special compiler can be used that randomizes
the memory areas, or applies slightly different code optimizations.
It doesn't prevent hacking, but it makes automatic patching very hard.
The game binary version and OS version will be checked.
If a new version of either is available, the patch is downloaded.
The binary blobs on the hard drive are automatically updated to combine
all patches into one patch. Then the system reboots.
If all signatures check out, the versions are the latest, then the server will send
an "approval key" (valid for 1 connection and a max lifetime of 5 minutes), which
is linked to user's Serial Number, IP, and E-mail address. The game binary starts.
The game binary will self-validate itself and its host OS (to detect any alterations).
The game binary will connect to the game server.
The game will present its approval ID to the game server.
It will re-run SHA256 checksum and additional checksums of itself, the host OS,
and certain areas of memory, and present those to the game server.
Along with player's e-mail address, and password.
The final step is for the gameserver to approve or reject the connection.
All traffic exchanged with the game server or other players will be over a
TLS-encrypted channel, except for untrusted information (such as chat).
With special monitoring proceduers in place to detect any attempt to tamper with
connections.
(Every client has a unique X.509 certificate for SSL, digitally signed by the game maker,
every server has a similarly verified X.509 certificate, and a specific, strong encryption
algorithm is utilized, completely outside the user's control.) ¶ 12:28 PM 0 Comments
The "installer" would place binary blobs in C:\program files\vendor\gamename.
The files would be loaded to self-patch the game during boot, but otherwise, the game runs entirely from RAM. Any swap file or data written to a hard drive must be encrypted.
These files would only hold any 'saved data' and digitally-signed patches to the
game image. The game can only be played in multi-player mode by booting the
computer from CD.
The CD would boot the system into the game's dedicated OS.
Completely contained in RAM.
The first stage of the bootloader would verify the integrity of the digitally-signed
OS files on the CD/DVD, and verify that the data is actually being read from an internal
CD drive, and not a USB stick.
It would be responsible for verifying that it was running on real hardware, and not a
virtual machine, and writing back encrypted hardware information to a binary blob.
Any detected attempt to operate the game on say virtual hardware, or specifically
banned hardware, results in permanent
deactivation written to the binary blobs, which the user is not notified about until the last
boot stage (After information about the "deactivation for hacking" is uploaded to
the manufacturer's game servers, to ensure merely "restoring some files from backup"
won't reverse the deactivation).
First OS
would also be responsible for verifying that the C:\ directory containing game patches
resides on an ATA, SATA, or SCSI drive, verifying that the Serial number, volume serial,
and make on the drive matches data in an encrypted header file (in the binary blobs),
proving the files have not been moved to a different drive.
(It is not permissive to restore to a new drive from backup, the software must be reinstalled.)
(The hard drive and other hardware verifications would be repeated at each OS loading
stage, upon any detection of hardware change, and every 30 minutes or so, during gameplay)
The verifications would be at independent codepoints, so a hacker patching the binary would
have more trouble finding all the different places where the verification is done in a different
way.
Next the first "binary blob" would be loaded into the RAMDISK and the patch applied to the game binary. Each blob would be provided by the manufacturer and contain a patch to the game binary.
Patches to the loader OS other than the game binary would be done, but would have to be digitally signed.
The individual patches are signed only with a SHA256 sum, but the binaries being patched have not been started yet.
Each _entire_ patched codebase (game binary, os binary) is signed, and the codebase's SHA256 sum is contained in a binary data blob. The digital signature and then the SHA256 sums will be verified before the second OS, or the game binary is started.
Both OSes will repeat the same verification and load only binaries with a properly-signed digest.
After all digital signatures are verified, the loader OS transfers control to the "second game OS"
(the fully patched OS that has all features such as networking support, that the game will be run under)
The second OS will immediately connect to the game server to upload some feedback
about the verification process: all encrypted with a server's public-key and tied to the
customer's serial number, a special "product key", IP address, and MAC addresses of all NICs:
if there was an attempt to hack something, successful or not, the blob of information will probably indicate it.
(Because the information uploaded will provide many details about the environment, hardware, and even unusual elements not part of the "verify to boot" process)
Periodic binary patches would be released to the game _just_ to move key areas of the
OS and game code around, and adjust protocols, to keep cheaters having to constantly
re-hack the code, if they ever figured out Version X: Version X+1 will be coming out in a few
weeks.
This doesn't need to be done manually: a special compiler can be used that randomizes
the memory areas, or applies slightly different code optimizations.
It doesn't prevent hacking, but it makes automatic patching very hard.
The game binary version and OS version will be checked.
If a new version of either is available, the patch is downloaded.
The binary blobs on the hard drive are automatically updated to combine
all patches into one patch. Then the system reboots.
If all signatures check out, the versions are the latest, then the server will send
an "approval key" (valid for 1 connection and a max lifetime of 5 minutes), which
is linked to user's Serial Number, IP, and E-mail address. The game binary starts.
The game binary will self-validate itself and its host OS (to detect any alterations).
The game binary will connect to the game server.
The game will present its approval ID to the game server.
It will re-run SHA256 checksum and additional checksums of itself, the host OS,
and certain areas of memory, and present those to the game server.
Along with player's e-mail address, and password.
The final step is for the gameserver to approve or reject the connection.
All traffic exchanged with the game server or other players will be over a
TLS-encrypted channel, except for untrusted information (such as chat).
With special monitoring proceduers in place to detect any attempt to tamper with
connections.
(Every client has a unique X.509 certificate for SSL, digitally signed by the game maker,
every server has a similarly verified X.509 certificate, and a specific, strong encryption
algorithm is utilized, completely outside the user's control.) ¶ 12:28 PM 0 Comments
Tuesday, July 08, 2008
Massive Multi-vendor DNS vulnerability
http://it.slashdot.org/article.pl?sid=08/07/08/195225
US-CERT Technical Cyber Security Alert TA08-190B -- Multiple DNS implementations vulnerable to cache poisoning
http://www.us-cert.gov/cas/techalerts/TA08-190B.html
---
Be sure to apply patches if you run an effected DNS server!
As for client resolver vulnerabilities...
Perhaps in the future firewalls will adapt.
Firewalls should use pattern analysis to detect vulnerable unaddressed client resolvers.
And perform TXID and port number translations (think NAT).
Translating the vulnerable (TXID, source) port combinations into safe ones.
Dynamically modifying the interaction between server and client to workaround
vulnerable software.
The same principle should apply on the server side, as well.
The implication reads..
Messages from the client translated (Weak TXID, Weak Port) => (Safe TXID, Safe Port)
* Safe TXID,PORT pair generated dynamically for every new TXID and PORT, once a
source IP is decided "vulnerable" no TXID or PORT from the client will be used, a new
one will be generated.
Messages from the server translated from (Safe TXID, Safe Port) => (Weak TXID, Weak port)
* In case of collision, the translation is torn down, the query is lost.
* In all cases, the translation is obliterated after a DNS timeout interval (30 seconds, or so)
Procedure explained ¶ 7:31 PM 0 Comments
US-CERT Technical Cyber Security Alert TA08-190B -- Multiple DNS implementations vulnerable to cache poisoning
http://www.us-cert.gov/cas/techalerts/TA08-190B.html
---
Be sure to apply patches if you run an effected DNS server!
As for client resolver vulnerabilities...
Perhaps in the future firewalls will adapt.
Firewalls should use pattern analysis to detect vulnerable unaddressed client resolvers.
And perform TXID and port number translations (think NAT).
Translating the vulnerable (TXID, source) port combinations into safe ones.
Dynamically modifying the interaction between server and client to workaround
vulnerable software.
The same principle should apply on the server side, as well.
The implication reads..
Messages from the client translated (Weak TXID, Weak Port) => (Safe TXID, Safe Port)
* Safe TXID,PORT pair generated dynamically for every new TXID and PORT, once a
source IP is decided "vulnerable" no TXID or PORT from the client will be used, a new
one will be generated.
Messages from the server translated from (Safe TXID, Safe Port) => (Weak TXID, Weak port)
* In case of collision, the translation is torn down, the query is lost.
* In all cases, the translation is obliterated after a DNS timeout interval (30 seconds, or so)
Procedure explained ¶ 7:31 PM 0 Comments
Tuesday, April 29, 2008
Human pseudo-random selection based on word lists
(7/15/1997)
It is difficult for humans to pick numbers 'at random' and have them not have a pattern
or irregularities.
Maybe instead there is some mental task one could formulate..
A thought that occured the other day was wordlists.
Instead of trying to pick numbers at random, try to pick a word or list of words at random.
For example, pick 5 words at random.
Now, apply some sort of algorithm to the list of words to get numbers.
I.E. Convert the first letter to a numerical value based on the letter.
A => 1
B => 2
...
Z => 26
Take the sum of the differences in values of the first letter in the wordlist
modulo 10 plus 1 for a pseudo-random number between 1 and 10
This at least makes it difficult for a human to prejudicially pick a certain number in advance.
More complex formulae are also possible, like using some of the words chosen as a
decoder ring or partial translation table for the letters.
i.e. if the word is HELLO then
H -> 1
E -> 2
L -> 3
O -> 4 ¶ 5:36 AM 0 Comments
It is difficult for humans to pick numbers 'at random' and have them not have a pattern
or irregularities.
Maybe instead there is some mental task one could formulate..
A thought that occured the other day was wordlists.
Instead of trying to pick numbers at random, try to pick a word or list of words at random.
For example, pick 5 words at random.
Now, apply some sort of algorithm to the list of words to get numbers.
I.E. Convert the first letter to a numerical value based on the letter.
A => 1
B => 2
...
Z => 26
Take the sum of the differences in values of the first letter in the wordlist
modulo 10 plus 1 for a pseudo-random number between 1 and 10
This at least makes it difficult for a human to prejudicially pick a certain number in advance.
More complex formulae are also possible, like using some of the words chosen as a
decoder ring or partial translation table for the letters.
i.e. if the word is HELLO then
H -> 1
E -> 2
L -> 3
O -> 4 ¶ 5:36 AM 0 Comments
Wednesday, October 31, 2007
