Yes, I've got multiple boxes (an alarming number when I count them!) but I don't think this is the solution. The problem is that ZA has to know which application is calling out, and that pretty well means it has to run on the same box as the application. If it's running on another box, I think it would only be able to identify the protocol and ports, and unfortunately many trojans call home on otherwise innocuous ports such as 80/tcp.
I don't see anything good about this. What they say is:
The DMA told the Senate Commerce committee in April 2001 that a law governing spam might not be objectionable if it overruled about 20 state laws currently on the books and prohibited only "the practice of sending fraudulent electronic mail messages" with forged headers.
Isn't the key that they want to overrule 20 state laws, which in some cases would apply financial penalties for UCE even with valid headers?
Come to that, when they say they are willing to accept a ban on fraudulent headers, are they talking about on their emails or on ours? I usually make up a one-shot address when I have to give an address to a trader, so that I can devnull spam. Do they want to ban that?
You are using NAT for outgoing connections. If you do not specify redirect rules for incoming connections, you effectively have very strict rules for incoming traffic
Well, up to a point, but more because NAT and a firewall happen to produce similar results (which is why I mentioned it) rather that because that's how a firewall works. My point was that NAT is fail-safe, whereas I've seen a couple of consumer-grade firewalls let through packets in situations I wouldn't have expected, and I don't have the time, skill or inclination to grovel through poor quality docs to find out why. Hence I suspect that even with IPv6, I might like to use NAT for safety and ease of use.
Using NAT for IPv6 is silly. Why use NAT if you have plenty addresses?
When I started using NAT rather than a computer directly interfaced to an ADSL modem, the number of attacks dropped from about a dozen a day to one or two a month - and those were only to my HTTP server, which NAT couldn't protect. I'm not a sysop, so I feel a bit happier with NAT rather than relying purely on a low-end firewall that I'm not able to evaluate.
I personally have 2^68 addresses allocated to me by my provider. All my machines are reachable directly via IPv6, no redirects of whatever.
<OT question="naive">How does that work in practice? Are you tunnelling IPv6 in IPv4, or do you have a native connection?<OT>
Corporate users can look at using 802.1x authentication with a protocol such as EAP-TLS - this allows a new negotiated WEP key for each session, which stops the main cracking problem. 802.1x has a few remaining problems, but it's a huge improvement on relying on static WEP.
Uhhh, how much closer can a human come to machine language than assembler?
You can't physically plug hex into a file, hoping to make it run.
we don't have punchcards anymore:)
Well, the only way I know of doing Z80 opcodes on an 8080 assembler is to use DB with machine language. (Thank you, Digital Research). And very occasionally it's convenient to patch binary with a low level debugger.
GSM is analog switched technology... GPRS is packet based. Lets see... which one do we want? Since GSM never really took off in the US, why not work on getting GPRS standard accepted in the US
GPRS is a packet-based extension to GSM, using spare timeslots (well, you can have dedicated timeslots, but you get the idea). You can't have GPRS without GSM. It's good for data access, but it's not intended for voice.
In theory you could use VoIP, but it would be an expensive way of doing the job worse than GSM (e.g. you'd lose echo cancellation). Also most networks don't yet allocate dedicated bandwidth to it, so while I've used it for streaming video, I've had to put up with the odd jerky patch.
BTW, someone else seemed to think GPRS was high-speed circuit-switched - that's HSCSD, basically GSM with some of the error correction turned down, and with potentially more than one time slot allocated.
and suffers from insane 'big brother' cell tower syndrom (or whatever you wanna call it when the phone is constantly telling the tower where it is, and what it's doing).
GSM doesn't do that. Simplifying a bit: a handset only communicated with the network when it's switched on, or when it moves between large areas (containing hundreds of base stations), or after a timeout of a few hours. The network needs to know roughly where it is to start incoming calls, but then it broadcasts a "wake-up" call from all of the base stations in the area. When that happens, the phone contacts a base station to pick up the call, and at that point the network knows exactly where it is.
Who wants GSM?
It's so weakly encrypted, anyone with a cheap pentium can crack it real-time.
While GSM isn't state of the art (it's 20 years old), I've not come across a way of breaking it in real time, and I've only come across a theoretical attack with recorded information which would be quite difficult to perform in practice. Can you provide a reference?
I suspect you are thinking of cracking the SIMs (the smartcard used to give a mobile its phone number) - if you have physical possession of the SIM you can clone it quite quickly - but only for those GSM companies daft enough to use an implementation of the A3/A8 algorithms which was only intended for demonstration use. (A3 and A8 are placeholders - it's up to the operator to select which algorithms will be used to implement them).
Companies in England & France have problems with industrial espionage -- people sit on each side of the channel with parabolic dishes and listen in on other companies' cell calls.
Again, can you substantiate that? I find it very difficult to believe, partly on technical grounds, and because even if the signals were in the clear, this would be very unproductive as compared with hacking the wetware.
I wouldn't use it as a standard desktop, purely because if you have space for a monitor you have space for a slightly larger unit - true, but then some of us run headless boxes as X clients. I like to do that to get Linux (via Cygwin) and Windows on the same screen.
Minor point - 3G can go up to about 2Mbit/s if the user is stationary and close to an aerial - i.e. in conditions comparable to those for which 802.11b works.
Much more important is that in practical terms, the bandwidth of the airside isn't the limiting factor in a public-access network. In an office environment, you can get something like 3.4-4Mbit/s out of 802.11b (depending on your adapter, and on whether you are using WEP encryption). In a public-access network, you've got to pipe that down some back-haul pipe to an upstream PoP. Either you use cheap-and-cheerful 2Mbit/s DSL, and put up with contention at the DSLAM, or you pay for something like a T1/E1 with dedicated bandwidth. Even if you pay for the dedicated bandwidth, you're probably going to end up with at most 2Mbit/s shared between your active customers.
You'll have to check prices yourself, but it's difficult to see how you can make a profit unless you dimension the system for a fairly low target bandwidth, say 256kbit/s, when you cost in the bandwidth and the installation labour. That makes it much closer to 3G in practical terms - probably a bit faster and a bit cheaper, but with access restricted to hot-spots.
Won't help you if your site uses an HTTP proxy and blocks everything else!
Re:First they came for the Indians...
on
Shop Till It Drops
·
· Score: 1
> Automats have been around for a hundred years.
The first known one was in the first century AD, invented by Heron of Alexandria to dispense water for ritual washing at a temple (Ancient Inventions, P James and N Thorpe).
Colourblind people actually do see colour! There's a few people who can't see any colour at all - this is achromatopia (Oliver Sacks has a book on this, Island of the Colorblind, I think). That's rare. The problem normally called colour blindness in English (Daltonism in some other languages) is more of a failure to match colours, than to distinguish them. As an example - in the UK we have green traffic lights that are what I would think of as "blue-green", which I find very easy to distinguish from the amber and red lights. In Belgium, they often use "red-green" for the green lights, which I find harder to distinguish. I can't see any similarity between the two greens, and I have to learn to call them the same colour - on the other hand, I can see a distinction in shade between the "red-green" and red traffic lights, but they aren't something I would naturally group separately.
Yes, I've got multiple boxes (an alarming number when I count them!) but I don't think this is the solution. The problem is that ZA has to know which application is calling out, and that pretty well means it has to run on the same box as the application. If it's running on another box, I think it would only be able to identify the protocol and ports, and unfortunately many trojans call home on otherwise innocuous ports such as 80/tcp.
Come to that, when they say they are willing to accept a ban on fraudulent headers, are they talking about on their emails or on ours? I usually make up a one-shot address when I have to give an address to a trader, so that I can devnull spam. Do they want to ban that?
Corporate users can look at using 802.1x authentication with a protocol such as EAP-TLS - this allows a new negotiated WEP key for each session, which stops the main cracking problem. 802.1x has a few remaining problems, but it's a huge improvement on relying on static WEP.
Well, the only way I know of doing Z80 opcodes on an 8080 assembler is to use DB with machine language. (Thank you, Digital Research). And very occasionally it's convenient to patch binary with a low level debugger.
Why does anyone need permission?
In theory you could use VoIP, but it would be an expensive way of doing the job worse than GSM (e.g. you'd lose echo cancellation). Also most networks don't yet allocate dedicated bandwidth to it, so while I've used it for streaming video, I've had to put up with the odd jerky patch.
BTW, someone else seemed to think GPRS was high-speed circuit-switched - that's HSCSD, basically GSM with some of the error correction turned down, and with potentially more than one time slot allocated.
GSM doesn't do that. Simplifying a bit: a handset only communicated with the network when it's switched on, or when it moves between large areas (containing hundreds of base stations), or after a timeout of a few hours. The network needs to know roughly where it is to start incoming calls, but then it broadcasts a "wake-up" call from all of the base stations in the area. When that happens, the phone contacts a base station to pick up the call, and at that point the network knows exactly where it is.I suspect you are thinking of cracking the SIMs (the smartcard used to give a mobile its phone number) - if you have physical possession of the SIM you can clone it quite quickly - but only for those GSM companies daft enough to use an implementation of the A3/A8 algorithms which was only intended for demonstration use. (A3 and A8 are placeholders - it's up to the operator to select which algorithms will be used to implement them).
Again, can you substantiate that? I find it very difficult to believe, partly on technical grounds, and because even if the signals were in the clear, this would be very unproductive as compared with hacking the wetware.I wouldn't use it as a standard desktop, purely because if you have space for a monitor you have space for a slightly larger unit - true, but then some of us run headless boxes as X clients. I like to do that to get Linux (via Cygwin) and Windows on the same screen.
Much more important is that in practical terms, the bandwidth of the airside isn't the limiting factor in a public-access network. In an office environment, you can get something like 3.4-4Mbit/s out of 802.11b (depending on your adapter, and on whether you are using WEP encryption). In a public-access network, you've got to pipe that down some back-haul pipe to an upstream PoP. Either you use cheap-and-cheerful 2Mbit/s DSL, and put up with contention at the DSLAM, or you pay for something like a T1/E1 with dedicated bandwidth. Even if you pay for the dedicated bandwidth, you're probably going to end up with at most 2Mbit/s shared between your active customers.
You'll have to check prices yourself, but it's difficult to see how you can make a profit unless you dimension the system for a fairly low target bandwidth, say 256kbit/s, when you cost in the bandwidth and the installation labour. That makes it much closer to 3G in practical terms - probably a bit faster and a bit cheaper, but with access restricted to hot-spots.
Of course, the One True Faith is the way of the Psion.
Won't help you if your site uses an HTTP proxy and blocks everything else!
The first known one was in the first century AD, invented by Heron of Alexandria to dispense water for ritual washing at a temple (Ancient Inventions, P James and N Thorpe).
Colourblind people actually do see colour! There's a few people who can't see any colour at all - this is achromatopia (Oliver Sacks has a book on this, Island of the Colorblind, I think). That's rare. The problem normally called colour blindness in English (Daltonism in some other languages) is more of a failure to match colours, than to distinguish them. As an example - in the UK we have green traffic lights that are what I would think of as "blue-green", which I find very easy to distinguish from the amber and red lights. In Belgium, they often use "red-green" for the green lights, which I find harder to distinguish. I can't see any similarity between the two greens, and I have to learn to call them the same colour - on the other hand, I can see a distinction in shade between the "red-green" and red traffic lights, but they aren't something I would naturally group separately.