As everybody else is wondering: how do they plan to ferret out NAT users? Go to everyone's home and count the number of computers?
Various NAT solutions leave evidence of their meddling; for example, Linux 2.0/2.2 IP Masquerading by default will modify the source port to one in the range 61000-65095.
Basing their conclusions on this isn't foolproof, particularly if someone's monkeyed around and isn't using the default config, but how many people do???
It's a typical judgement for the UK courts to rule to the absolute letter in cases such as this. Problem is, the judges don't appear to have a firm grasp of the implications caused by these rulings.
I'm usually quite cynical, but sometimes UK judges do this in order to prove a point; they'll follow the law to the letter in order to say (in veiled terms) "hey, did you realise that this law, as it's presently worded, makes *this* possible. I suspect this isn't what you intended, so you might want to think about reviewing the law". Case in point, the recent attempt by a pro-life group that went to court to try and get cloning outlawed and ended up with exactly the opposite legal conclusion!
I am not 100% on the DMCA and what is says/means. I was under the impression that it was only applied to copyrighted closed sorce stuff. I must be wrong could someone please explain how the DMCA really effects Linux and The Opensource community?
The specific issue you're referring to (Alan's Changelog that omitted details of a security fix for DMCA-related reasons) was, IIRC, related to a flaw in enforcement of file permissions. Because someone could use file permissions to build a Digital Rights Management (DRM) system (dumb, but that may not stop them), it is feasible that by Alan documenting the problem more precisely than I've done, he could be found to be distributing a circumvention device, as outlawed in the DMCA.
If anyone's got a better insight on this, feel free to correct me, but I think I've pretty much nailed it.
After I installed Kernel 2.4 w/o any hard drive errors for 6 months using Kernel 2.2, I started receiving Bad CRC errors.
Which either means the 2.4 drivers are buggy... or... the 2.2 drivers aren't reporting your CRC errors.
It's (probably) the latter; the 2.4 drivers report CRC errors caused during transmission along the IDE cables. You've (probably) always had the problem, now you know about it and should fix it (hint: start by buying some good quality IDE cables...)
--
On Behalf of the USENET Preservation Society...
on
How Google Saved USENET
·
· Score: 3, Insightful
Google did save USENET for me - though I never post, searching through all the linux and comp newsgroups is usually faster than looking up a HOWTO.
As a regular USENET poster, I'm gratified that you've found our posts useful, but please, please do consider participating yourself!
"But I don't know anything worth posting!"
, I hear you cry. Well, for a start, since when has that stopped anyone on USENET, myself included! Besides, I'm sure everyone knows something about something, even if it's "only" mexican cooking (alt.food.mexican-cooking) and Italian manga (alt.italian.anime-manga).
Take the trouble to subscribe to a few groups and get involved. Keep them as lively discussion fora, not dusty historical archives and a spam collection!
I discovered USENET in 1992, and I've rarely gone away. It's definitely the most consistently interesting and useful part of the Internet, IMHO.
When performing calculations that can take hours or days even, an increase in performance of even 10% can result in significant time/money savings. There are those mid level workstation users (like me) and high end users that can and do need every last bit of performance they can get. At this level, a few hundred $$'s every few months is nothing.
I agree with your VFM argument, but surely, if you're performing calculations that take hours or days (weather forecasts, biotech, scientific research, nuke simulation), they're likely to be important enough that you'd like to have confidence that they're actually correct, rather than save a few bucks/hours and run an overclocked system, right?
--
Re:Picture of bills with US bill
on
The Euro
·
· Score: 4, Funny
The US's money looks like serious money, dignified, beefy and substantial.
OTOH, I prefer knowing that my european "disney dollars" and British pounds have substantial anti-counterfeiting measures which mean that although they may look insubstantial, they're actually more likely to be real money than a random US dollar bill...:-P
...but only if you're actually expected to fix real problems yourself. A lot of organizations rely on support contracts and begging their vendor to fix problems.
I've provided post-sales support for a number of proprietary products for a number of years and having an understanding of programming from assembly and bare metal up certainly helps me. It has baffled my (non-programmer) colleagues who wonder how I appear to pull correct diagnoses and solutions out of thin air, though. This sometimes causes problems if they think I'm being unprofessional and guessing.
At the very least, knowing what strace/truss is telling you, being able to find the executable or binary producing a certain error message (strings) and being able to distinguish between the static and the dynamic parts of error messages (so you can search using Google for the static parts) helps enormously.
Having said all that, the combination of x86 and C/POSIX is the first platform I've not bothered to learn how to write assembly for... might come in handy for implementing l33t 0-day sploitz though.
The cleverest loading trick, IMHO, was coded by David Jones for the game 'Spellbound'. (Released on Mastertronic Added Dimension for 3 quid!)
Basically, he'd edited the internal representation of the basic loader so that it started the programme 3 bytes on from what the loader appeared to say when looking at the code. e.g. although it claimed to start executing from memory location 31000, it actually started at 31003.
Hmmm... I think I can figure this one out; Spectrum BASIC had two representations for a number - 5 bytes for arithmetic and as many numeric ASCII bytes as necessary for Us Dumb Humans. IIRC, there was no requirement for the ASCII representation to match the underlying arithmetic representation (though, of course, for any non-twiddled bit of BASIC, they would match...)
Given that a 100G hard drive is cheaper than any removable media solution, why not just buy another hard drive and install it in a removable (not hot-swappable, just removable) rack?
Some thoughts:-
1) IME, Racks cause heat build-up and kill HDDs. I won't use them and I recommend others don't either.
2) If you're going to permanently mount and power the drive, then it stands as much chance of dying through power cycles and usage as your main drive.
3) If you're going to leave the drive unpowered most of the time, then you probably won't bother backing up because it'll require a shutdown, an opened case, a boot and another shutdown.
IMHO, If you're going to use another drive, you might as well go for RAID and have the backups done automatically and continuously.
Let's say the journaling file system has 5% overhead (it probably has more). That means you lose more than 1h per day on a busy server--it's spread out, but it's still lost. You'd have to do a lot of rebooting in order to make up for that in terms of "saved" fsck time.
Actually, Andrew Morton reckons ext3 is actually quicker than ext2 in spite of the journalling. Go figure.:)
Some nice firewalls, like Checkpoint, have an HTTP security server which does bounds checking and similar to HTTP requests.
That's all very well, but the inspection performed by the FW-1 HTTP Security Server is quite expensive in performance terms (effectively it turns FW-1 from a stateful packet filter into a proxy).
Not only that, but historically, there have been plenty of problems with the Security Servers to the extent that I wouldn't be happy deploying it on a production, high traffic network (and certainly not without extensive validation).
To be fair, I haven't worked with FW-1 recently and haven't looked at NG (aka v5) at all, so things may well have gotten better.
Also consider that it's possible the struggle for collectively owned information and intellectual property may some day move far outside of the internet, and into the real world. That might require a whole new re-evaluation of our tactics and ideals.
It already has. My involvement with Free software has already led me to protest about the actions of RiceTec Inc. who have patented Basmati rice!
IMHO, Basmati rice is used by humanity under the terms of a GPL-like license (if it wasn't, why does it produce seeds (aka source code) that can be grown (compiled) to produce new rice?)
Why is it that Star/Open Office wants to be installed on a per user basis, instead of a system wide location where everyone can use it. I've never had any luck getting it to work unless I installed it in my home directory. Does anyone know of a way that I can make it available to everyone?
RTFM. Basically, you run 'setup -net' as root and install under/opt or/usr/local or something, then as each user run setup from the installed tree, and it'll copy about 2MB of stuff into your home directory. It's all documented.
> Chances are they had no clue what the 'established' keyword was and just allowed ports 1024 through 64k. (in the cases where their firewall did not automatically
recognize that exchange works in a fashion similar to rpc)
Just out of curiosity: how do you configure a firewall for those kinds of protocol? The principle of those protocols (Sun RPC, Java RMI, DCOM) is that the client does a
first connection to a "naming service" (i.e. portmapper, RMI registry, etc.) which is on a fixed port, and then learns from that "naming service" which port the actual service
uses. The latter being variable of course, which makes it tough to allow through the firewall.
Your remark seems to suggest that there is a general way of allowing those kinds of connections. Does it only work for specific RPC-like protocols, or does it also work in
the general case? Wouldn't the firewall need to parse the actual "RPC-like" protocol to do it?
Yup. You'll need some kind of stateful firewall to do this right. The sad thing is that, to the best of my knowledge, no stateful firewall on the market deals with sunrpc or DCOM in a stateful manner. *sigh*
We had the problem here at work (both with java RMI and DCOM), and yes,
we did eventually resort to opening everything between 1024 and 65535. If there is a cleaner way (i.e. a more selective way) to do it, I'd be interested.
Sometimes you can limit the range of ports that an RPC-like service will use at the cost of limiting the number of concurrent connections. Doing this, you could shift the RPC range up to about 60000-65000 or something, well out of the way of other services you would like to unconditionally block (X11, rplayd, Back Orifice, NetBus, Napster spring to mind, depending on administrative tastes). Yes, you're still letting a bunch of random connections through, but at least there's unlikely to be anything listening. Of course, if you're concerned about "Inside Jobs" (and you probably should be...) then this probably won't cut the mustard either. Life's a bitch.:(
...and Apocalyptica. They're a Finnish cello quartet who started playing Metallica (*spit*) covers (very well) who've now progressed to a little Sepultura and some original works.
...and I took a look. I can only echo the comments of some other posters saying that it appeared to be jumping on the bandwagon started by Hacking Exposed, but doing so merely by re-stating everything that's been said online already in a more verbose form. Lots of source code listings of exploits, lots of tables showing stuff that's already easily available in RFCs and IEEE standards but very little actual meat.
Sorry, I can't recommend this book. I didn't, however, look at the TigerSuite CD... maybe that/is/ useful. Personally, I would recommend Hacking Exposed, 2nd Ed as a starters/reference guide, though to be any good at pen testing, you really need to have a natural inquisitiveness and back that up with private study and experimentation.
(Disclaimer, I pen. test for a living and got my copy of Hacking Exposed free direct from the authors...:)
An often overlooked advantage of hardware-based encryption devices is that if they are properly designed and implemented (i.e. tested and conformant with FIPS-140-1 security level of 3+) then the private key can be reasonably assured to never leave the device, even if it is disassembled.
Oh, and we can't make gun ownership contingent on millitary training. Not without ammending the Constitution.
I'm not a constitutional lawyer, but it seems to me as a brit that the natural reading of the second amendment is that the "people keeping and bearing arms" should also be "a well regulated militia". Now that sounds more like the Swiss model than every Tom, Dick and Harry being able to walk into their nearest Wal-Mart and buy a semi-automatic assault rifle.
I do wonder sometimes how many Americans have actually read their constitution.
If they had dropped the price down to even $1-$2, licensed it to any manufacturer other than Sony, and made a few pennies off the
billions of disks made and sold, they would have come out ahead, and we wouldn't still be giving away floppy disks.
Er... they did; I've seen Zip disks manufactured by Fujifilm and Maxell. Same price as Iomega-branded disks though.
My guess is that their licensing fees were too high for other manufacturers to sell at competitive prices.
...*if* it's properly authenticated. A start is to limit SSH clients to "trusted" IP addresses or netblocks.
To go further, use ssh keys (rather than passwords) to grant access; this means those keys (and the password to unlock them) need to be stolen for an intruder to gain access (naturally, you'll be firewalling the client as well, right?!)
If more than one person needs access to SSH on a given host, you might be able to tie things down by running several SSH servers, each listening on it's own port and each running as a seperate, regular user (rather than root, which is the normal configuration). This way, compromising your SSH server will only give your priviledges. (Note: I haven't actually tried doing this, but I don't know of a reason it can't be done...:)
To go a bit further, install filtering rules on the ssh server to limit what outbound connections it can make. If it's a Linux box, perhaps look into using iptables, which can provide filtering according to UID/GID.
Finally, in order to provide some kind of audit trail for when it does all go wrong, use one-time authentication at your firewall to allow or disallow the SSH TCP connection appropriately.
Several options here; in (approixately) increasing level of difficulty and inconvenience. Stop when you feel your paranoia level has been exceeded.:)
Slashdot Mirror
Various NAT solutions leave evidence of their meddling; for example, Linux 2.0/2.2 IP Masquerading by default will modify the source port to one in the range 61000-65095.
Basing their conclusions on this isn't foolproof, particularly if someone's monkeyed around and isn't using the default config, but how many people do???
--
I'm usually quite cynical, but sometimes UK judges do this in order to prove a point; they'll follow the law to the letter in order to say (in veiled terms) "hey, did you realise that this law, as it's presently worded, makes *this* possible. I suspect this isn't what you intended, so you might want to think about reviewing the law". Case in point, the recent attempt by a pro-life group that went to court to try and get cloning outlawed and ended up with exactly the opposite legal conclusion!
--
The specific issue you're referring to (Alan's Changelog that omitted details of a security fix for DMCA-related reasons) was, IIRC, related to a flaw in enforcement of file permissions. Because someone could use file permissions to build a Digital Rights Management (DRM) system (dumb, but that may not stop them), it is feasible that by Alan documenting the problem more precisely than I've done, he could be found to be distributing a circumvention device, as outlawed in the DMCA.
If anyone's got a better insight on this, feel free to correct me, but I think I've pretty much nailed it.
--
Which either means the 2.4 drivers are buggy ... or ... the 2.2 drivers aren't reporting your CRC errors.
It's (probably) the latter; the 2.4 drivers report CRC errors caused during transmission along the IDE cables. You've (probably) always had the problem, now you know about it and should fix it (hint: start by buying some good quality IDE cables...)
--
As a regular USENET poster, I'm gratified that you've found our posts useful, but please, please do consider participating yourself!
"But I don't know anything worth posting!" , I hear you cry. Well, for a start, since when has that stopped anyone on USENET, myself included! Besides, I'm sure everyone knows something about something, even if it's "only" mexican cooking (alt.food.mexican-cooking) and Italian manga (alt.italian.anime-manga).
Take the trouble to subscribe to a few groups and get involved. Keep them as lively discussion fora, not dusty historical archives and a spam collection!
I discovered USENET in 1992, and I've rarely gone away. It's definitely the most consistently interesting and useful part of the Internet, IMHO.
--
I agree with your VFM argument, but surely, if you're performing calculations that take hours or days (weather forecasts, biotech, scientific research, nuke simulation), they're likely to be important enough that you'd like to have confidence that they're actually correct, rather than save a few bucks/hours and run an overclocked system, right?
--
OTOH, I prefer knowing that my european "disney dollars" and British pounds have substantial anti-counterfeiting measures which mean that although they may look insubstantial, they're actually more likely to be real money than a random US dollar bill... :-P
--
I've provided post-sales support for a number of proprietary products for a number of years and having an understanding of programming from assembly and bare metal up certainly helps me. It has baffled my (non-programmer) colleagues who wonder how I appear to pull correct diagnoses and solutions out of thin air, though. This sometimes causes problems if they think I'm being unprofessional and guessing.
At the very least, knowing what strace/truss is telling you, being able to find the executable or binary producing a certain error message (strings) and being able to distinguish between the static and the dynamic parts of error messages (so you can search using Google for the static parts) helps enormously.
Having said all that, the combination of x86 and C/POSIX is the first platform I've not bothered to learn how to write assembly for... might come in handy for implementing l33t 0-day sploitz though.
--
Basically, he'd edited the internal representation of the basic loader so that it started the programme 3 bytes on from what the loader appeared to say when looking at the code. e.g. although it claimed to start executing from memory location 31000, it actually started at 31003.
Hmmm... I think I can figure this one out; Spectrum BASIC had two representations for a number - 5 bytes for arithmetic and as many numeric ASCII bytes as necessary for Us Dumb Humans. IIRC, there was no requirement for the ASCII representation to match the underlying arithmetic representation (though, of course, for any non-twiddled bit of BASIC, they would match...)
--
Some thoughts:-
1) IME, Racks cause heat build-up and kill HDDs. I won't use them and I recommend others don't either.
2) If you're going to permanently mount and power the drive, then it stands as much chance of dying through power cycles and usage as your main drive.
3) If you're going to leave the drive unpowered most of the time, then you probably won't bother backing up because it'll require a shutdown, an opened case, a boot and another shutdown.
IMHO, If you're going to use another drive, you might as well go for RAID and have the backups done automatically and continuously.
--
You might like to take a look at using xdelta for your binary files. Who knows, maybe Midway can sponsor the integration of xdelta with CVS?
Actually, their top lawyer has just stepped down.
Actually, Andrew Morton reckons ext3 is actually quicker than ext2 in spite of the journalling. Go figure. :)
--
That's all very well, but the inspection performed by the FW-1 HTTP Security Server is quite expensive in performance terms (effectively it turns FW-1 from a stateful packet filter into a proxy).
Not only that, but historically, there have been plenty of problems with the Security Servers to the extent that I wouldn't be happy deploying it on a production, high traffic network (and certainly not without extensive validation).
To be fair, I haven't worked with FW-1 recently and haven't looked at NG (aka v5) at all, so things may well have gotten better.
--
It already has. My involvement with Free software has already led me to protest about the actions of RiceTec Inc. who have patented Basmati rice!
IMHO, Basmati rice is used by humanity under the terms of a GPL-like license (if it wasn't, why does it produce seeds (aka source code) that can be grown (compiled) to produce new rice?)
Luckily, it looks as though, for once, the system came through and ruled that 75% of their claims were invalid
RTFM. Basically, you run 'setup -net' as root and install under
Just out of curiosity: how do you configure a firewall for those kinds of protocol? The principle of those protocols (Sun RPC, Java RMI, DCOM) is that the client does a first connection to a "naming service" (i.e. portmapper, RMI registry, etc.) which is on a fixed port, and then learns from that "naming service" which port the actual service uses. The latter being variable of course, which makes it tough to allow through the firewall.
Your remark seems to suggest that there is a general way of allowing those kinds of connections. Does it only work for specific RPC-like protocols, or does it also work in the general case? Wouldn't the firewall need to parse the actual "RPC-like" protocol to do it?
Yup. You'll need some kind of stateful firewall to do this right. The sad thing is that, to the best of my knowledge, no stateful firewall on the market deals with sunrpc or DCOM in a stateful manner. *sigh*
We had the problem here at work (both with java RMI and DCOM), and yes, we did eventually resort to opening everything between 1024 and 65535. If there is a cleaner way (i.e. a more selective way) to do it, I'd be interested.
Sometimes you can limit the range of ports that an RPC-like service will use at the cost of limiting the number of concurrent connections. Doing this, you could shift the RPC range up to about 60000-65000 or something, well out of the way of other services you would like to unconditionally block (X11, rplayd, Back Orifice, NetBus, Napster spring to mind, depending on administrative tastes). Yes, you're still letting a bunch of random connections through, but at least there's unlikely to be anything listening. Of course, if you're concerned about "Inside Jobs" (and you probably should be...) then this probably won't cut the mustard either. Life's a bitch. :(
...and Apocalyptica. They're a Finnish cello quartet who started playing Metallica (*spit*) covers (very well) who've now progressed to a little Sepultura and some original works.
Sorry, I can't recommend this book. I didn't, however, look at the TigerSuite CD... maybe that /is/ useful. Personally, I would recommend Hacking Exposed, 2nd Ed as a starters/reference guide, though to be any good at pen testing, you really need to have a natural inquisitiveness and back that up with private study and experimentation.
(Disclaimer, I pen. test for a living and got my copy of Hacking Exposed free direct from the authors... :)
An often overlooked advantage of hardware-based encryption devices is that if they are properly designed and implemented (i.e. tested and conformant with FIPS-140-1 security level of 3+) then the private key can be reasonably assured to never leave the device, even if it is disassembled.
Someone didn't read the USENET Primer before they started! :-P
(See "Be Careful What You Say About Others")
I'm not a constitutional lawyer, but it seems to me as a brit that the natural reading of the second amendment is that the "people keeping and bearing arms" should also be "a well regulated militia". Now that sounds more like the Swiss model than every Tom, Dick and Harry being able to walk into their nearest Wal-Mart and buy a semi-automatic assault rifle.
I do wonder sometimes how many Americans have actually read their constitution.
Er... they did; I've seen Zip disks manufactured by Fujifilm and Maxell. Same price as Iomega-branded disks though.
My guess is that their licensing fees were too high for other manufacturers to sell at competitive prices.
To go further, use ssh keys (rather than passwords) to grant access; this means those keys (and the password to unlock them) need to be stolen for an intruder to gain access (naturally, you'll be firewalling the client as well, right?!)
If more than one person needs access to SSH on a given host, you might be able to tie things down by running several SSH servers, each listening on it's own port and each running as a seperate, regular user (rather than root, which is the normal configuration). This way, compromising your SSH server will only give your priviledges. (Note: I haven't actually tried doing this, but I don't know of a reason it can't be done...:)
To go a bit further, install filtering rules on the ssh server to limit what outbound connections it can make. If it's a Linux box, perhaps look into using iptables, which can provide filtering according to UID/GID.
Finally, in order to provide some kind of audit trail for when it does all go wrong, use one-time authentication at your firewall to allow or disallow the SSH TCP connection appropriately.
Several options here; in (approixately) increasing level of difficulty and inconvenience. Stop when you feel your paranoia level has been exceeded. :)