Application behavior enforcement for Microsoft Windows was capable of preventing the various MS-RPC exploits, before they were discovered, by preventing the RPC listener from doing any system calls that did not fit the "model" of what the service should do in normal circumstances.
...even those running AV software won't be protected from a super-fast-moving virus...
The next step beyond simple pattern-matching virus scanners is mechanisms to to model the good behavior of processes, and terminate a process if it goes outside those bounds.
On OpenBSD and other Unix-like operating systems there is the free Systrace.
Windows and Solaris users can pay Cisco around $800 per server for "Cisco Security Agent" (Formerly Okena), which does the same thing as systrace, but with a nicer GUI and some packet filtering (I do not work for Cisco, I do not sell software.)
Workstation licenses were around $35 per seat.
When I tried to convince a Fortune 500 corporation of the value of deploying this type of security, the answer I received was "But this doesn't protect against SQL injection or Cross Site Scripting!"
The worm/virus explosion is because RBLs are WORKING, and spammers are finding less IP space they can operate from. Their only alternative is to infect client PCs and turn them into proxies.
Most of the malware I run across, and many worms, include payloads to turn infected hosts into either an open proxy or more commonly a "bot" (IRC zombie).
One (unfortunate) solution to spam from compromised workstations is for mail servers to refuse to accept SMTP messages from hosts in dialup and DHCP address ranges.
The exceptions seem to be the most heavily populated areas. Chicago, New york and the like.
The gun laws in Chicago are insane. The state of Illinois would have Indiana-style CHL if it were not for Cook county and Mayor Daley.
New York State has relatively easily obtained "may issue" CHL, except in New York City and the surrounding counties where for some reason only celebrities and other rich white people can obtain a permit.
None of the information mentioned seems particularly sensitive.
Want to tell us what brand and version of firewall you have installed too?
Even prior to Sarbanes, it has generally been pretty easy for outsiders to find out what brand of firewall corporations have installed at the outermost perimeter -- obtaining version information is often nearly as easy. Now with SOX, corporations have a duty to show investors they take IT security seriously.
And there are very few corporations using non-cisco products for routing. I know of several corporations which use Foundry or Dell or even Lucent for workgroup switches (because I've seen their names in press releases and marketing material from Foundry and Dell and Lucent) but it's rare to see anything other than Cisco in key routing roles.
Regarding "joint press releases", most people in a CIO/CTO position are sensitive to the risks, but it's difficult to resist the lure of points off a major software purchase just for letting the vendor use your name and logo in their marketing and financial PR documents...
I had an incident where one employee left a cell phone at their desk, it rang (one of those really annoying music rings) on and off for nearly an hour. Another employee (next cube over) turned it off. The first employee went ballistic about that. That was fun. Once in a while I'll have an employee who just spends wayyy too much time talking on their cell phone.
Clearly they handled the situation incorrectly by turning off the other employee's abandoned cell phone.
The correct solution is to remove the battery, microwave for 7 seconds on "HIGH" then re-insert the battery.
No fireworks, just a slight scorched smell and the blissful sound of silence.
I've noticed that in the last three rounds of layoffs, 90% of the employees let go were white, had a "senior" title married men.
Men whose wives had very recently had a child kept their jobs, while single men and married men with toddlers got the ax.
Re:Warning: Vaporware Company Detected
on
The Universal Card
·
· Score: 1
Any company that has a hyperlink marked "Investor Information" above-the-fold (shown without a need to scroll down on a typical 800x600 setup) is automatically a bit suspect.
Unlike Open BSD, Windows Installs many obscure features into the the default install of the desktop. So although it wasn't a bug in the kernel, it was in Ie or windows messaging or RPS or something else. I sort of prefer the OpenBSD idea that the end user has to decide what to put on their computer besides the shell and basic utilities.
Absolutely. One reason I purchase the OpenBSD release CD set is because the install set includes pretty much every application I need to have a usable system, with most necessary network services installed in the base install, but 99.9% of services are turned off by default.
Compare this to MS-Windows, where 90% of the network services included are turned on by default, and it is difficult for even an experienced user to know which services can be safely disabled, and which are necessary for a usable system.
How difficult would it be for Microsoft to default all services to 'off', and bind all network services only to the loopback interface?
If they can't make thge security posture of MS-Windows approach that of OpenBSD, at least they can try to match MacOS X, where the default install has no remotely accessible listening ports!
If you're not averse to free software then I suggest you try Cygwin (http://www.cygwin.com/). It's a lot easier to set up than Hummbingbird eXeed. It's also free. I've been using it for a few years now to get X access to remote *nix boxen, never had any problems cos it's easy to setup and use. And did I mention that, unliek Hummingbird eXeed, it's free?
I'm not adverse to free software, but I've had difficulty getting cygwin to run reliably on some Windows systems, and it's not always easy to automate and make it usable by non-geeks.
I use Kea! X for giving access to specific Solaris applications to Windows users who just want an easy way to bring up a user interface and access some data.
While Kea is cheaper than Hummingbird, we chose it primarily because so many users were already familiar with their 3270 terminal client. And it works, has built-in SSH, and seems to have fewer screen geometry and refresh issues than other X servers.
If I could find a reliable "rootless" X server for MS-Windows that would let me script SSH connections to specific Solaris applications from an icon, I'd switch.
Does Linux or BSD have ppriv? Or is this something new?
The closest thing to this that I have encountered is the kernel-level "Type Enforcement" in SecurOS, a BSD variant used for Secure Computing firewalls.
BSD and Linux can use Systrace, which offers some similar process-level controls (can set execution system call profiles per application).
While Solaris has offered file level ACLs forever, they weren't used by default to protect critical system files and very few admins knew to enable them.
One of the things I like about Solaris (I still prefer OpenBSD) is the cool little security and debugging tools that are included in the default install -- when you don't have source, "truss" was a godsend, and "dtrace" takes debugging to a whole new level.
It's more likely a type of fluorescense, sort of like a more socially acceptable version of those glow in the dark skull rings most of us had as a kid.
One possibility I haven't seen discussed much is to make mail transmission intentionally unreliable. What would happen if a mail server rejected 90% of the attempts to send a message through it (and the sender was configured to keep trying until it went through)?
Quite a few sites seem to be doing this unintentionally.
One more refined implementation of this approach is to keep a table of hosts from which you have accepted email recently (hosts that sent you messages which were not blocked by your spam filter).
When a host you haven't seen before tries to connect, for the first hour, all attempts from that IP (subnet) get a temporary failure result code, after the first hour, the new host is temporarily added to the "permit" list, so their next attempt (if they bother to try again -- spammers won't bother) is successful.
Hosts that send you good email just about every day, never expire off the permit list, and don't get transient failures. Hosts that you have never seen before have their first delivery attempt fail with a 4xx class error.
Normal, legitimate, one-off emails would take up 10 times as much bandwidth (and time) due to failed requests
If the mail is rejected early in the conversation, before the DATA phase, then the actual bandwidth wasted would be much much less. After the first rejected attempt, each time a host delivers "good" email their 24-hour "pass" to send additional email without rejection is renewed...
Since a lot of spammers rely on open relays, maybe it's about time a few honeypots are set up with open relays that send all port 25 activity to/dev/null, sends the spammers fake ACKs, and log who's trying to send the spam.
This is already being done on a small scale. For example, Chuckmail was first conceived in 1996.
The problem is that the open relay finding applications now try to deliver a couple of messages through the server before making large-scale use -- the spammers use basically the same open relay detection as do anti-spammers.
The workaround is to actually make your honeypot act as an open relay, at least for a few messages from any one IP address/subnet, and then after the spammer gets comfortable, start dumping to/dev/null.
The problem with this approach is that in order to stop spam, you end up running a (low throughput) open relay. As a hardcore anti-spam zealot I can't bring myself to do this -- it just feels too dirty.
One of the key difficulties in the war against spam is that while most spammers are complete idiots and most spamming is not profitable, there are still smart people making money writing and improving spam transmitting software and related programs.
Smart, evil people -- but no less smart for their evilness.
Or more generally, get him something that takes considerable effort to locate and obtain -- glowrings are one example:
H3 products original glowring
Important Note - Due to International Regulatory differences regarding the use of GTLS (H3 lights), this product can only be sent to residents of the UK.
Other less extreme examples might be a book signed by a favorite author, products from Japan (not just porn), or a real wasabi root (from Oregon).
A crash means you killed, not just a task, but the whole system. In a system as robust as BSD this usually means that the code that was corrupted by the exploit was running at a kernel permission level. So if you can take it over you can get it to give you any permission you want.
You make a good point.
However, keep in mind that there are quite a few areas in (all?) BSD-derived IP stacks where a seriously malformed packet will cause the kernel itself to throw up it's hands and call panic("WTF?!?").
$ grep panic/usr/src/sys/netinet6/*.c | wc -l
42
I've found that just about any system will eventually panic if you sic ISIC at it from within the same subnet.
Cool OpenBSD kernel panic messages:
panic("can't happen: system seems to have no memory!");
panic("pmap_init: bogons in the VM system!");
This guy found a crash in qmail, too. I don't think he showed it was exploitable, so he doesn't win DJB's security guarantee prize. In fact I'm not sure DJB reacted to the news at all.
This isn't "a crash in qmail", it is a (minor) bug, which only affects the current child process, not the daemon; it's really quite silly to make a big deal out of this.
Basically, Georgi Guninski found a way to cause the current child process of 'qmail-smtpd' to abend -- this is not a DoS, as it only affects your child SMTP session, and is likely not possible in an RFC-compliant message.
Technically the issue is the use of a signed integer as a counter when it is also used as an index into the array (containing the current line?). If the counter is incremented to the point that it "wraps around" (technically overflows, but not in the same sense as a buffer overflow), then when the counter is used as an offset into an array, it causes a "segment violation" fault.
Because the counter is used as an offset into an array for the purpose of reading the value of a byte, and the process is killed as soon as it tries to access memory outside of it's segment (SEGV), this is inherently non-exploitable for privilege escalation.
As I said, it's silly, is only an issue because the rest of DJB's code is so clean you could eat off it, and as Georgi Guninski says,
I agree that the site in question will get the most benefit from moving their "clean" content to a new IP address, leave the porn content on the old IP.
The way that censorware works is that it blocks IP's, not domains.
This is not absolutely true -- while nearly all web filters have a list of IP addresses that are blocked, most block on both domain names and IP addresses.
As a result, other sites hosted on the same IP as a site with undesirable content as defined by some censorware's black list are also blocked.
Depends on the filter, and on the hosting site. Sometimes this is unavoidable, where the hosting company intentionally or unintentionally makes it easy to bypass domain name filters by going through another site hosted on the same IP address.
NOt all web filtering software will block all sites hosted on an IP address that contains just one objectionable site.
This obviously has many serious problems -- the best writeup on the myriad issues with censorware is at Peacefire.
Asking Peacefire about web filtering software is like an "Ask Slashdot" about Microsoft software -- any answer you get is indelibly tinged with the fanatacism of the source.
There are some well-written web filtering applications, there are some legitimate reasons to install and use filters. But you'll never hear anything positive about "censorware" from Peacefire.
...who it is that is opening email, saving attachments, opening the attachment, running the payload, and is not using AV software.
Symantec (makers of Norton) only released a special DAT update a few hours ago, and I believe Trend was only slightly ahead of them.
So running normal pattern-based antivirus would not have helped. Even with the pattern files being distributed, not all users of all AV software are configured to receive "push" updates or check for new pattern files often enough to prevent infection.
The problem is worse with worms (which self-propagate) than with viruses (which require human action to infect a vulnerable host).
Is it that there is a subset of people that for their own sick reasons *always* runs infection attachments just to watch the LAN go down so they can go home early? I'm becoming suspicious [tinfoil hat goes on and is pulled down hard]
When the user doesn't feel any ownership stake in "their" workstation (true of many employees of corps), and there is no direct consequence for taking stupid actions, why not click?
Blocking SSH/ESP and tracking HTTPS is reasonable, in part because it catches the "low hanging fruit", users and automated attack tools not smart enough to try less alarm-triggering channels first.
Applications which tunnel through the HTTP application layer (not just SSH o port 80) using fully obscured forms encryption are prevalent and readily available to the non-technical PC user. Such applications are very popular in Saudi Arabia and China, for example.
Like restrictive nations, one benefit of banning encryted protocols and logging all traffic is that you do not need to know what the user is doing with the connection, just proving that they are using unapproved connectivity is sufficient to fire the offender.
As a related example, I've heard from Saudi visitors that the government run dialup ISPs will drop your session (not sure if they drop carrier, or just shun your IP address) the moment you try to bring up an encrypted session to a foreign destination.
No, this doesn't stop the spies, but it does discourage the average visitor from using encrypted sessions, and the log of attempts gives the defenders an idea of who might deserve closer scrutiny.
It is well-known to the steganography community that any open channel, even email, are insecure. Unless such channels are closely monitored by a professional cryptographer, there is no chance that they can reliably be monitored to prevent unfriendly traffic.
True, though latency on email (assuming inbound/outbound email is passed through a chain of SMTP relays, not just "permit TCP 25" packet filters) is high enough that it's not an effective way to tunnel IP traffic.
I don't know about others, but I do traffic analysis on the raw volume of sessions and bytes in/out by source (by IP, by subnet, etc), and by the internet source/destination of the traffic. The average porn hound is going to be caught not by the nature of the HTTP sites he visits, but by the sudden spike in bandwidth, and the sudden increase in traffic to and from an internet destination not commonly seen.
There are exceptions, e.g. Google Image Search. OTOH, most of the porn hounds we fire are caught first by their poor job performance, any logs or evidence on their PC are just insurance against the former employee filing a "wrongful dismissal" lawsuit...
You can buy fruit juice that says "contains 100% fruit juice" or something similar, but really it is made up of lots of things. The actual juice is 100% fruit juice (whatever that means), but the added water and sugar and preservatives and apple juice concentrate (most drinks are cut with apple juice) have nothing to do with the actual "fruit" part of the juice, and therefore do not apply to the 100% rule. Or I could be wrong
Yes, you are 100% wrong:)
A bottle that claims "100% fruit juice not from concentrate" must contain only juice from fruit, no sugar, no water. A bottle of cranberry juice which says "cranberry juice", contains only the juice of cranberries. If it says "from concentrate" then it contains cranberry concentrate and water -- different batches of cranberries may be mixed together adjust the sweetness/tartness, but no sugar or acid is added.
A bottle of cranberry drink labeled as "100% fruit juice" is probably not actually 100% cranberry juice -- as you say, most fruit juice is "cut" with apple juice (Okay, so you were right on that). But it's all fruit juice, from some fruit or another.
If the label says "drink", "cocktail", "punch" or "delight", it may contain water, sugar, etc.
Lastly, the contents of a "fruit flavored drink" may not actually include any fruit products at all!
(The above is based on UK labelling standards, IANAL, YMMV)
"... Consider limiting outbound connections that use encrypted protocols, such as SSH, HTTPS, IPsec. Permitting unncessary encrypted connections may allow users to perform actions that security controls cannot monitor. For example, a user could establish a SSH connection to an external server and download illegal materials; because the connection is encrypted, network security controls would not determine the nature of the activity. Possible methods for limiting the traffic include firewall rulesets and URL filtering..."
Who the hell wrote this crap?
Apparently, somebody who knows how smart slacker geeks get their porn, and wants to put a stop to it.
No really, blocking SSH/ESP and tracking HTTPS is a reasonable suggestion -- if anything, I'd say the above doesn't go far enough. The excerpted paragraph doesn't mention the more serious risks of SSH (port forwarding, tunneling, etc).
I'm not particularly worried about a smart internal user establishing an SSH session to the Internet and downloading "illegal materials",
I'm worried about the airhead secretary who brings in a floppy provided by her uberhacker boyfriend, and runs a rootkit, setting up an outbound SSH session providing him with a command prompt on her workstation...
That's just one risk of permitting outbound crypto channels...
Re:SILC: Secure open source chat, GPL licensed.
on
Enterprise IM?
·
· Score: 2, Informative
Actually, there are a couple of GUI clients for windows -- the one that comes in the standard package is just there as a example implementation to show what can be done with the library.
The other SILC clients available for MS-Windows are GUI win32 binarie with a point-n-click interface with graphical icons. In some ways this is worse, since the icon imagery in some clients doesn't seem to have any relationship to what the buttons actually do!
But users in a corporation have graphical interfaces, they use the mouse, they click, they want to see smilies and pictures. Stupid? Maybe, but this is how things are in an enterprise, and solutions are deployed for users sake, not for ours.
Exactly. And while there are GUI clients for SILC on Windows, they are still the most unattractive chat clients I've ever seen.
SILC: Secure open source chat, GPL licensed.
on
Enterprise IM?
·
· Score: 2, Informative
So far, the only complaint I've received is the lack of a good MS-Windows client.
The X and text clients for Unix are usable, and there's even an Irssi module. but the Windows clients lack the polished user interface that people have come to expect from their Microsoft-centric chat services.
Only problem is, the free Jabber has a number of bugs, and isn't really built for an enterprise deployment. It lacks support for integration into existing directories and authentication structures, an easy mechanism for pre-populating buddy lists, and many other "corporate" features and services.
Slashdot Mirror
On OpenBSD and other Unix-like operating systems there is the free Systrace.
Windows and Solaris users can pay Cisco around $800 per server for "Cisco Security Agent" (Formerly Okena), which does the same thing as systrace, but with a nicer GUI and some packet filtering (I do not work for Cisco, I do not sell software.)
Workstation licenses were around $35 per seat.
When I tried to convince a Fortune 500 corporation of the value of deploying this type of security, the answer I received was "But this doesn't protect against SQL injection or Cross Site Scripting!"
So yes, Clueless people deserve it...
One (unfortunate) solution to spam from compromised workstations is for mail servers to refuse to accept SMTP messages from hosts in dialup and DHCP address ranges.
For this I use the Pan-Am Dynamic List (PDL).
New York State has relatively easily obtained "may issue" CHL, except in New York City and the surrounding counties where for some reason only celebrities and other rich white people can obtain a permit.
For all your CHL questions, see http://www.packing.org/
And there are very few corporations using non-cisco products for routing. I know of several corporations which use Foundry or Dell or even Lucent for workgroup switches (because I've seen their names in press releases and marketing material from Foundry and Dell and Lucent) but it's rare to see anything other than Cisco in key routing roles.
Regarding "joint press releases", most people in a CIO/CTO position are sensitive to the risks, but it's difficult to resist the lure of points off a major software purchase just for letting the vendor use your name and logo in their marketing and financial PR documents...
The correct solution is to remove the battery, microwave for 7 seconds on "HIGH" then re-insert the battery.
No fireworks, just a slight scorched smell and the blissful sound of silence.
Men whose wives had very recently had a child kept their jobs, while single men and married men with toddlers got the ax.
Compare this to MS-Windows, where 90% of the network services included are turned on by default, and it is difficult for even an experienced user to know which services can be safely disabled, and which are necessary for a usable system.
How difficult would it be for Microsoft to default all services to 'off', and bind all network services only to the loopback interface?
If they can't make thge security posture of MS-Windows approach that of OpenBSD, at least they can try to match MacOS X, where the default install has no remotely accessible listening ports!
I use Kea! X for giving access to specific Solaris applications to Windows users who just want an easy way to bring up a user interface and access some data.
While Kea is cheaper than Hummingbird, we chose it primarily because so many users were already familiar with their 3270 terminal client. And it works, has built-in SSH, and seems to have fewer screen geometry and refresh issues than other X servers.
If I could find a reliable "rootless" X server for MS-Windows that would let me script SSH connections to specific Solaris applications from an icon, I'd switch.
BSD and Linux can use Systrace, which offers some similar process-level controls (can set execution system call profiles per application).
While Solaris has offered file level ACLs forever, they weren't used by default to protect critical system files and very few admins knew to enable them.
One of the things I like about Solaris (I still prefer OpenBSD) is the cool little security and debugging tools that are included in the default install -- when you don't have source, "truss" was a godsend, and "dtrace" takes debugging to a whole new level.
One more refined implementation of this approach is to keep a table of hosts from which you have accepted email recently (hosts that sent you messages which were not blocked by your spam filter).
When a host you haven't seen before tries to connect, for the first hour, all attempts from that IP (subnet) get a temporary failure result code, after the first hour, the new host is temporarily added to the "permit" list, so their next attempt (if they bother to try again -- spammers won't bother) is successful.
Hosts that send you good email just about every day, never expire off the permit list, and don't get transient failures. Hosts that you have never seen before have their first delivery attempt fail with a 4xx class error.
If the mail is rejected early in the conversation, before the DATA phase, then the actual bandwidth wasted would be much much less. After the first rejected attempt, each time a host delivers "good" email their 24-hour "pass" to send additional email without rejection is renewed...The problem is that the open relay finding applications now try to deliver a couple of messages through the server before making large-scale use -- the spammers use basically the same open relay detection as do anti-spammers.
The workaround is to actually make your honeypot act as an open relay, at least for a few messages from any one IP address/subnet, and then after the spammer gets comfortable, start dumping to /dev/null.
The problem with this approach is that in order to stop spam, you end up running a (low throughput) open relay. As a hardcore anti-spam zealot I can't bring myself to do this -- it just feels too dirty.
One of the key difficulties in the war against spam is that while most spammers are complete idiots and most spamming is not profitable, there are still smart people making money writing and improving spam transmitting software and related programs.
Smart, evil people -- but no less smart for their evilness.
Other less extreme examples might be a book signed by a favorite author, products from Japan (not just porn), or a real wasabi root (from Oregon).
However, keep in mind that there are quite a few areas in (all?) BSD-derived IP stacks where a seriously malformed packet will cause the kernel itself to throw up it's hands and call panic("WTF?!?").
I've found that just about any system will eventually panic if you sic ISIC at it from within the same subnet.
Cool OpenBSD kernel panic messages:
or the elegantly simple:
Basically, Georgi Guninski found a way to cause the current child process of 'qmail-smtpd' to abend -- this is not a DoS, as it only affects your child SMTP session, and is likely not possible in an RFC-compliant message.
Technically the issue is the use of a signed integer as a counter when it is also used as an index into the array (containing the current line?). If the counter is incremented to the point that it "wraps around" (technically overflows, but not in the same sense as a buffer overflow), then when the counter is used as an offset into an array, it causes a "segment violation" fault.
Because the counter is used as an offset into an array for the purpose of reading the value of a byte, and the process is killed as soon as it tries to access memory outside of it's segment (SEGV), this is inherently non-exploitable for privilege escalation.
As I said, it's silly, is only an issue because the rest of DJB's code is so clean you could eat off it, and as Georgi Guninski says,
NOt all web filtering software will block all sites hosted on an IP address that contains just one objectionable site.
Asking Peacefire about web filtering software is like an "Ask Slashdot" about Microsoft software -- any answer you get is indelibly tinged with the fanatacism of the source.There are some well-written web filtering applications, there are some legitimate reasons to install and use filters. But you'll never hear anything positive about "censorware" from Peacefire.
So running normal pattern-based antivirus would not have helped. Even with the pattern files being distributed, not all users of all AV software are configured to receive "push" updates or check for new pattern files often enough to prevent infection.
The problem is worse with worms (which self-propagate) than with viruses (which require human action to infect a vulnerable host).
When the user doesn't feel any ownership stake in "their" workstation (true of many employees of corps), and there is no direct consequence for taking stupid actions, why not click?This would fare better as a Fark photoshop contest than as an ask slashdot.
Like restrictive nations, one benefit of banning encryted protocols and logging all traffic is that you do not need to know what the user is doing with the connection, just proving that they are using unapproved connectivity is sufficient to fire the offender.
As a related example, I've heard from Saudi visitors that the government run dialup ISPs will drop your session (not sure if they drop carrier, or just shun your IP address) the moment you try to bring up an encrypted session to a foreign destination.
No, this doesn't stop the spies, but it does discourage the average visitor from using encrypted sessions, and the log of attempts gives the defenders an idea of who might deserve closer scrutiny.
True, though latency on email (assuming inbound/outbound email is passed through a chain of SMTP relays, not just "permit TCP 25" packet filters) is high enough that it's not an effective way to tunnel IP traffic.I don't know about others, but I do traffic analysis on the raw volume of sessions and bytes in/out by source (by IP, by subnet, etc), and by the internet source/destination of the traffic. The average porn hound is going to be caught not by the nature of the HTTP sites he visits, but by the sudden spike in bandwidth, and the sudden increase in traffic to and from an internet destination not commonly seen.
There are exceptions, e.g. Google Image Search. OTOH, most of the porn hounds we fire are caught first by their poor job performance, any logs or evidence on their PC are just insurance against the former employee filing a "wrongful dismissal" lawsuit...
A bottle that claims "100% fruit juice not from concentrate" must contain only juice from fruit, no sugar, no water. A bottle of cranberry juice which says "cranberry juice", contains only the juice of cranberries. If it says "from concentrate" then it contains cranberry concentrate and water -- different batches of cranberries may be mixed together adjust the sweetness/tartness, but no sugar or acid is added.
A bottle of cranberry drink labeled as "100% fruit juice" is probably not actually 100% cranberry juice -- as you say, most fruit juice is "cut" with apple juice (Okay, so you were right on that). But it's all fruit juice, from some fruit or another.
If the label says "drink", "cocktail", "punch" or "delight", it may contain water, sugar, etc.
Lastly, the contents of a "fruit flavored drink" may not actually include any fruit products at all!
(The above is based on UK labelling standards, IANAL, YMMV)
Apparently, somebody who knows how smart slacker geeks get their porn, and wants to put a stop to it.
No really, blocking SSH/ESP and tracking HTTPS is a reasonable suggestion -- if anything, I'd say the above doesn't go far enough. The excerpted paragraph doesn't mention the more serious risks of SSH (port forwarding, tunneling, etc).
I'm not particularly worried about a smart internal user establishing an SSH session to the Internet and downloading "illegal materials",
I'm worried about the airhead secretary who brings in a floppy provided by her uberhacker boyfriend, and runs a rootkit, setting up an outbound SSH session providing him with a command prompt on her workstation...
That's just one risk of permitting outbound crypto channels...
The other SILC clients available for MS-Windows are GUI win32 binarie with a point-n-click interface with graphical icons. In some ways this is worse, since the icon imagery in some clients doesn't seem to have any relationship to what the buttons actually do!
Exactly. And while there are GUI clients for SILC on Windows, they are still the most unattractive chat clients I've ever seen.It's like IRC, but with public key encryption built in from the ground up. And All SILC software is Open Source (GPL).
So far, the only complaint I've received is the lack of a good MS-Windows client.
The X and text clients for Unix are usable, and there's even an Irssi module. but the Windows clients lack the polished user interface that people have come to expect from their Microsoft-centric chat services.
BTW, SILC Client 1.0.1 was released this week.
Only problem is, the free Jabber has a number of bugs, and isn't really built for an enterprise deployment. It lacks support for integration into existing directories and authentication structures, an easy mechanism for pre-populating buddy lists, and many other "corporate" features and services.
As it happens, most missing features are available in the commercial jabber.com release, which costs big big bucks.. thousands to tens of thousands for licensing, plus annual fees of around ten bucks per user.