This won't gain you anything, as the decryption doesn't happen when the packet is received by the host, but in the application, therefore evading a host-based network-level IDS. As for regular host-based IDS such as Tripwire (both the free & non-free products), this should be used at all times, but always is after-the-fact and therefore should be the last layer of security.
Frankly speaking - I think you have a very limited idea how the Whale product works. You may have fallen prey to their marketing strategy that explains the whys and whats of their remote access product, but I was specifically referring to their Application Firewall product.
The solution is based on a logically split reverse proxy (it's actually separated by a physically half-duplex fixed-size memory bank that separates inside from outside, and that can only ever be accessed by one side at a time). A listener on the outside receives an HTTPS connection, shovels the payload data along with a connection identifier (no IP address, no TCP headers, etc.) over to the memory bank. The memory bank is then physically switched to the inside, where a process picks up the data, handles the SSL encryption/decryption, and then inspects the content.
Protocol conformance, as you suggest, is being checked, but this the least interesting aspect. It is more important that checks are being done up to the application level, i.e. individual URLs and associated parameters, cookies, and headers are changed for validity ("Is this an integer field? Is its value between 1 and 10, or is it 12?", "This field may contain text conforming to the regular expression...").
If ISA server, Sidewinder or Symantec go beyond that, I somehow didn't notice...
Regarding support for more protocols - dynamically opening ports and such - the Whale product line has a different approach; due to the logical separation of the inside and outside network, there is no traditional address or transport layer crossing the gap. Email and files may traverse the gap, but they do this as data; whether they arrive at the internal or external side as NFS data, FTP streams or something totally different does not matter; the protocol does not even reach the network on the other side.
There's a few very sophisticated application-level firewalls available on the market, but they all pertain to a very specific set of protocols. NFS and MAPI are none of them, as these are far too complex and it's too hard to distinguish bad from good traffic; HTTPS, on the other hand, is pretty well suited to full application layer inspection, and this can make it very practical to actually allow access to an application on your INTERNAL network from the outside. However, on the side of the application-level firewall, this requires very sophisticated rulesets that require modification whenever the application changes, and that require a very skilled administrator. Whale Communications makes one such product (e-Gap Application Firewall), which could easily be the most sophisticated application level firewall for HTTPS. There are other vendors though that offer reverse proxies including authentication that will do session management and only forward traffic belonging to live, authenticated sessions, that could possibly as well make it practical to have the application run on your internal network.
Just think about it - in an ideal world, you could connect your database only to the web - no replication to the insecure area (DMZ), no (not in the Windows meaning of the word!) trust relationship with the DMZ, no poking holes in your firewall for DB/RPC/other proprietary communication protocols, no bringing out and maintaining the same set of hardware and software twice...
BUT this comes at a price - secure application layer proxies require skill and money.
Disclaimer: I work for a company that has implemented the Whale solution in Germany for 2 years. However, I chose the Whale solution for its technical merit solely.
Yes, as if running a Windows system without RPC these days was practical. It is not, therefore you need firewalls to secure Windows systems in a DMZ network.
I don't know about the US or other parts of the world, but at least Germany has laws governing the validity of purchases negotiated between private individuals and companies over media such as telephone, the Internet, and regular mail, that allow for the private individual to cancel the contract at no cost and without any particular reason within 14 days.
As far as "mercy purchases" are concerned, rules like this should make it pretty hard to succeed for telemarketers, magazine subscription vendors and the like.
On Aug 28, there was a press release regarding the eRServer on the PostgreSQL website (link here). Project page for eRServer is here. Haven't checked it out yet though.
Running your own SMTP mailer on DynDNS service with dynamic IP addresses is insane as well, as this creates a considerable time window (of at least 60 seconds, which was the DynDNS.org TTL last time I checked; far more when you're offline for one reason or another) for your messages to hit the wrong customer - that is, assuming DNS in this world is working perfectly and all servers will respect the DynDNS record's TTL. I happen to believe that DNS has never been in this state, even though it appears to have improved a lot during the last years.
Anyway, as far as security is concerned, running your own mailer on dynamic IP addresses WITHOUT the cooperation of your ISP (having the ISP accept mail on behalf of you, then forward it to you based on e.g. RADIUS-supplied 'Current-IP' information) is just as insane...
Slashdot Mirror
This won't gain you anything, as the decryption doesn't happen when the packet is received by the host, but in the application, therefore evading a host-based network-level IDS. As for regular host-based IDS such as Tripwire (both the free & non-free products), this should be used at all times, but always is after-the-fact and therefore should be the last layer of security.
Troll.
Frankly speaking - I think you have a very limited idea how the Whale product works. You may have fallen prey to their marketing strategy that explains the whys and whats of their remote access product, but I was specifically referring to their Application Firewall product.
The solution is based on a logically split reverse proxy (it's actually separated by a physically half-duplex fixed-size memory bank that separates inside from outside, and that can only ever be accessed by one side at a time). A listener on the outside receives an HTTPS connection, shovels the payload data along with a connection identifier (no IP address, no TCP headers, etc.) over to the memory bank. The memory bank is then physically switched to the inside, where a process picks up the data, handles the SSL encryption/decryption, and then inspects the content.
Protocol conformance, as you suggest, is being checked, but this the least interesting aspect. It is more important that checks are being done up to the application level, i.e. individual URLs and associated parameters, cookies, and headers are changed for validity ("Is this an integer field? Is its value between 1 and 10, or is it 12?", "This field may contain text conforming to the regular expression ...").
If ISA server, Sidewinder or Symantec go beyond that, I somehow didn't notice...
Regarding support for more protocols - dynamically opening ports and such - the Whale product line has a different approach; due to the logical separation of the inside and outside network, there is no traditional address or transport layer crossing the gap. Email and files may traverse the gap, but they do this as data; whether they arrive at the internal or external side as NFS data, FTP streams or something totally different does not matter; the protocol does not even reach the network on the other side.
I would call this an application level firewall!
There's a few very sophisticated application-level firewalls available on the market, but they all pertain to a very specific set of protocols. NFS and MAPI are none of them, as these are far too complex and it's too hard to distinguish bad from good traffic; HTTPS, on the other hand, is pretty well suited to full application layer inspection, and this can make it very practical to actually allow access to an application on your INTERNAL network from the outside. However, on the side of the application-level firewall, this requires very sophisticated rulesets that require modification whenever the application changes, and that require a very skilled administrator. Whale Communications makes one such product (e-Gap Application Firewall), which could easily be the most sophisticated application level firewall for HTTPS. There are other vendors though that offer reverse proxies including authentication that will do session management and only forward traffic belonging to live, authenticated sessions, that could possibly as well make it practical to have the application run on your internal network.
Just think about it - in an ideal world, you could connect your database only to the web - no replication to the insecure area (DMZ), no (not in the Windows meaning of the word!) trust relationship with the DMZ, no poking holes in your firewall for DB/RPC/other proprietary communication protocols, no bringing out and maintaining the same set of hardware and software twice...
BUT this comes at a price - secure application layer proxies require skill and money.
Disclaimer: I work for a company that has implemented the Whale solution in Germany for 2 years. However, I chose the Whale solution for its technical merit solely.
Yes, as if running a Windows system without RPC these days was practical. It is not, therefore you need firewalls to secure Windows systems in a DMZ network.
Another part of what makes this country great is making fun of people who can't read and write their own language.
/. readers/posters all are from this country?
Ahem, so
I don't know about the US or other parts of the world, but at least Germany has laws governing the validity of purchases negotiated between private individuals and companies over media such as telephone, the Internet, and regular mail, that allow for the private individual to cancel the contract at no cost and without any particular reason within 14 days.
As far as "mercy purchases" are concerned, rules like this should make it pretty hard to succeed for telemarketers, magazine subscription vendors and the like.
- JanOn Aug 28, there was a press release regarding the eRServer on the PostgreSQL website (link here). Project page for eRServer is here. Haven't checked it out yet though.
-JanRunning your own SMTP mailer on DynDNS service with dynamic IP addresses is insane as well, as this creates a considerable time window (of at least 60 seconds, which was the DynDNS.org TTL last time I checked; far more when you're offline for one reason or another) for your messages to hit the wrong customer - that is, assuming DNS in this world is working perfectly and all servers will respect the DynDNS record's TTL. I happen to believe that DNS has never been in this state, even though it appears to have improved a lot during the last years.
Anyway, as far as security is concerned, running your own mailer on dynamic IP addresses WITHOUT the cooperation of your ISP (having the ISP accept mail on behalf of you, then forward it to you based on e.g. RADIUS-supplied 'Current-IP' information) is just as insane...