You might also trying setting up your tor config file. You do not HAVE to use the "trusted gateways" for the final drop, that is only how it is configured OOTB. Add "exit" to the untrusted gateway nodes permissions - heck you can even remove "exit" from the "trusted nodes" permissions. Now you're not connecting via those "known tor nodes."
1) With the development version of tor, any node whose port is reachable gains some "half verification". This means it can and will be used as an exit node. It can not, however, be used explicitly by adding..exit to the hostname or in a ExitNodes statement in the config.
2) I heard that Tor blacklists are done in a very clumsy way. They don't check exit policies, for example. This means that even if your node doesn't allow any connections to the outside, it will appear in the blacklist. This should definitely be changed, so that if I ran a website, I would only block Tor nodes that allow *:80. But I could be wrong here.
Just to note, some Linux distribs have an alias for that, too. Probably for people used with Windows shell, like those dir aliases.
But that's the point. An alias is a concept I can follow and I can see why an otherwise syntactically wrong command can work then. In the cmd.exe it's just there and you can't see in simple to follow steps why it works.
Without spaces I'm not sure, but cd... and cd.... respectively goes to grandparent and grandgrandparent. Not here (XP). Neither with space nor without does it do anything if you give it more than two dots. And that's the point again. It gives no error like "No such file or directory" or anything. It just sits there with no result.
And even if it worked, why don't I see the entries '...' and '....' in a dir output? This suggests they are some artificial kludges in the cd command or the cmd shell itself and have no proper equivalent in the underlying filesystem. They are probably the result of some "optimization" to save some whiners the hassle of typing../.. err, pardon..\..
This half-assedness is exactly my point and the reason why maintaining any Windows box is more a guesswork than anything else, because everything is done that way.
PS: not to mention the extreme stupidity once you try to actually script something. %var% comes to mind. It must have been like this:
"We can't use $ to denote variables. We already use it somewhere in UNC paths for 'special' services." "Just pick another sign *taps blindly on keyboard* How about %?" "OK, but just in case we later use it somewhere else, we will enclose variable in it instead of just preceeding them." "Wow, great thinking. You get the award for future-proof coding!"
Look at the 'for' syntax for starters. The whole thing feels as if they never heard about syntax parsers and go about coding a shell with string comparisons and huge if.. then.. else monstrosities.
I need a break. This fuckup is getting on my nerves again.
But what is bash without/bin/*,/sbin/*,/usr/bin/*,/usr/sbin/* and so on? Just a nice frontend.
The main reason why a shell for Windows 1) takes insanely long to develop 2) will suck anyway is that the whole system beneath it is completely rotten, non-elegant and a pain to use.
Take the 'ipv6' command for example, if you installed the IPv6 stack on XP. They use dash options (-p), where most of the "DOS" tools use slash options (which AFAIK are the reason they have backslashes instead of slashes in paths). The notion of an 'interface' with that ipv6 command is completely awkward. Since their real identifiers are nicely hidden away below the shiny Network control panel, you have to use 'ipv6 if' to retrieve an integer that corresponds to the desired interface.
Examples of the current CLI sucking are:
1) a tab-complete in the middle of the line destroys the rest of the line 2) why does 'cd..' without a space even work? 3) as in 2), a 'cd...' or 'cd....' works as well in that it returns no error, it just doesn't do anything! 4) 'UNC' paths (\\server\path) are 'not supported' as the current directory. However, they are supported as args for commands (all commands?).
These are examples that lead me to believe that there actually is no structure below the surface of Windows and the tools it offers. I believe that Microsoft developers look at something and go implement it in a quick and dirty way, without ever having a bigger design goal in mind and without ever changing something once it has been hacked into place.
It's magic! A single script and I can build a complete operating system for a big-endian 64bit architecture on a 32bit little-endian architecture, or any of the other 48 supported archs. More than that, I can build a complete NetBSD for any arch on any halfway POSIXish system.
build.sh bootstraps its own contained build utils (compiler, binutils et al) and builds the system with that. You can even build the complete system as non-root and get tarballs that you can use to install a complete system.
To think that my weak SPARCstation 2 should build its own system would be madness. Instead, I just run build.sh -m sparc distribution on a dumb, fast i386 box and have a world in an hour instead of week(s).
Oh, and NetBSD "feels" the same on any arch, no administration nightmare, no matter what arch you run it on.
On another OS, like MacOS X, UNIX or even maybe NT 3.5 or Windows 2K (if you know a lot) you can actually fix the OS.
Sorry, this attitude has no place when the system was compromised. Working with the system to fix it is dangerous when the tools you work with are not trustworthy anymore.
You could selectively "restore" system binaries using tools like tripwire. OTOH, "restoring" the system for example by compiling a fresh system from source on the compromised system itself would be stupid since the compiler could be compromised. Every output you get from ps(1) or top(1) or netstat(1) could be compromised and so on.
So when you say Well, what would you do? it tells me that you aren't even aware of another way of coexisting with a computer. OK. Maybe you are, but it points out that this is the "ONLY" way to fix a Windows XP install. The thing is to blinking convoluted to repair.
Remember, this is not about fixing your average XP install that has become rotten over time. It's about a system that was maliciously modified to cover the tracks of the intruder and to possibly provide hidden entry points to the intruder later.
The point is, you don't run any code from a compromised system. You wipe the system, install (the same or another system) from fresh install media and restore your data (not programs, not scripts without review, nothing except non-executable files).
While the "format and reinstall" attitude in the perspective of just running a system over a long time is certainly wrong, it is crucial after a security breach.
For the low-level stuff Uli is talking about (glibc, GCC), supporting minority targets is troublesome even when the best of coding practices are put to use.
Granted, NetBSD uses GCC, but I don't see NetBSD's libc causing much trouble on the 48(?) archs it runs on. I'm sure if the NetBSD people were using their own compiler, it would be of equal quality.
I don't want to dismiss GCC here, I just don't buy the "supporting more targets slows down the project". In my uninformed opinion this is more a sign of bad design to begin with.
But what do I know, I just use code, I don't make it.
Very good point. Supporting minority platforms is only troublesome if your code is riddled with i386isms and lazy coding practices. If you do it right the first time with always portability in mind, not only will you get cleaner and more maintainable code, you also get the ability to run just anywhere as a bonus. My prime example as usual is NetBSD.
It's sad that whenever you build some GNU sources or the latest Linux app du jour you get tons of warnings. Some projects even compile their files with 2>&1 >/dev/null. How sad is that?
It's not just the Linux folks. OpenSSL is actually worrying me:/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(85): warning: pointer casts may be troublesome [247]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(94): warning: pointer casts may be troublesome [247]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: bitwise operation on signed value possibly nonportable [117]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: possible pointer alignment problem [135]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: pointer casts may be troublesome [247]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: possible pointer alignment problem [135]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: pointer casts may be troublesome [247]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: possible pointer alignment problem [135]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: pointer casts may be troublesome [247]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: possible pointer alignment problem [135]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: pointer casts may be troublesome [247]/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: bitwise operation on signed value possibly nonportable [117]
etc. etc.
And this in a project that's driving quite an amount of sites, authentication mechanism and what not?
Most if not all of the sources that are native to NetBSD, i.e. not imported like OpenSSL and GCC compile without any warning. You automatically get a good feeling about using it.
1) IPv4 has a lot of addresses which don't suffice anymore 2) IPv6 has more
and you provided complete nonsense about how IPv6 addresses look like. Now you blame me for only correcting the technical aspect and not reaching out to explain the big picture which you didn't either. On top of that, 340282366920938463 sextillion are 340 undecillion.
Sorry, but that's just rubbish. IPv4 adresses are 32bit, IPv6 addresses are 128bit.
IPv6 addresses are represented by 8 blocks of 16bit numbers in hex: 1234:1234:1234:1234:1234:1234:1234:1234. Leading zeroes in a block can be omitted. The biggest continuous all-zero block can be omitted entirely: 0123:0000:0000:0000:0000:0123:0000:1234 is equal to 123::123:0:1234.
IPv6 is 340282366920938463 sextillion addresses, not just "275 trillion".
Actually you can have two serial ports on the wrt54g, and an SD card slot if you want.
After some googling I figure that's for people who like to get their hands dirty with soldering and hacking hardware instead of software, i.e. not for me. But thanks.
Slashdot Mirror
Alright, it just gets uglier and uglier, we should better stop digging.
Brilliant!
../.. works but dir ../.. doesn't. Need I say more?
cd
You might also trying setting up your tor config file. You do not HAVE to use the "trusted gateways" for the final drop, that is only how it is configured OOTB. Add "exit" to the untrusted gateway nodes permissions - heck you can even remove "exit" from the "trusted nodes" permissions. Now you're not connecting via those "known tor nodes."
..exit to the hostname or in a ExitNodes statement in the config.
1) With the development version of tor, any node whose port is reachable gains some "half verification". This means it can and will be used as an exit node. It can not, however, be used explicitly by adding
2) I heard that Tor blacklists are done in a very clumsy way. They don't check exit policies, for example. This means that even if your node doesn't allow any connections to the outside, it will appear in the blacklist. This should definitely be changed, so that if I ran a website, I would only block Tor nodes that allow *:80. But I could be wrong here.
One side-effect of TOR is that packets arrive and leave multiply encrypted.
They enter multiply encrypted. If the requested protocol is HTTP, they exit unencrypted, just as if the exit node had made the request itself.
Just to note, some Linux distribs have an alias for that, too. Probably for people used with Windows shell, like those dir aliases.
... and cd .... respectively goes to grandparent and grandgrandparent. Not here (XP). Neither with space nor without does it do anything if you give it more than two dots. And that's the point again. It gives no error like "No such file or directory" or anything. It just sits there with no result.
../.. err, pardon ..\..
But that's the point. An alias is a concept I can follow and I can see why an otherwise syntactically wrong command can work then. In the cmd.exe it's just there and you can't see in simple to follow steps why it works.
Without spaces I'm not sure, but cd
And even if it worked, why don't I see the entries '...' and '....' in a dir output? This suggests they are some artificial kludges in the cd command or the cmd shell itself and have no proper equivalent in the underlying filesystem. They are probably the result of some "optimization" to save some whiners the hassle of typing
This half-assedness is exactly my point and the reason why maintaining any Windows box is more a guesswork than anything else, because everything is done that way.
PS: not to mention the extreme stupidity once you try to actually script something. %var% comes to mind. It must have been like this:
.. then .. else monstrosities.
"We can't use $ to denote variables. We already use it somewhere in UNC paths for 'special' services."
"Just pick another sign *taps blindly on keyboard* How about %?"
"OK, but just in case we later use it somewhere else, we will enclose variable in it instead of just preceeding them."
"Wow, great thinking. You get the award for future-proof coding!"
Look at the 'for' syntax for starters. The whole thing feels as if they never heard about syntax parsers and go about coding a shell with string comparisons and huge if
I need a break. This fuckup is getting on my nerves again.
But what is bash without /bin/*, /sbin/*, /usr/bin/*, /usr/sbin/* and so on? Just a nice frontend.
The main reason why a shell for Windows 1) takes insanely long to develop 2) will suck anyway is that the whole system beneath it is completely rotten, non-elegant and a pain to use.
Take the 'ipv6' command for example, if you installed the IPv6 stack on XP. They use dash options (-p), where most of the "DOS" tools use slash options (which AFAIK are the reason they have backslashes instead of slashes in paths). The notion of an 'interface' with that ipv6 command is completely awkward. Since their real identifiers are nicely hidden away below the shiny Network control panel, you have to use 'ipv6 if' to retrieve an integer that corresponds to the desired interface.
Examples of the current CLI sucking are:
1) a tab-complete in the middle of the line destroys the rest of the line
2) why does 'cd..' without a space even work?
3) as in 2), a 'cd...' or 'cd....' works as well in that it returns no error, it just doesn't do anything!
4) 'UNC' paths (\\server\path) are 'not supported' as the current directory. However, they are supported as args for commands (all commands?).
These are examples that lead me to believe that there actually is no structure below the surface of Windows and the tools it offers. I believe that Microsoft developers look at something and go implement it in a quick and dirty way, without ever having a bigger design goal in mind and without ever changing something once it has been hacked into place.
This brings us to our next subject. Nerds and spelling . . . :)
(On my SPARC, MIPS, PA-RISC, and x86 machines) For portability and package management, nothing beats debian.
You misspelled NetBSD.
Heed my words: It will run and without major hacking.
1. The script is part of NetBSD. :)
2. http://cvsweb.netbsd.org/bsdweb.cgi/src/regress/ is supposedly used for regression testing. Ask a developer, I'm just a user
...the cross-platform, cross-hardware part?
It's magic! A single script and I can build a complete operating system for a big-endian 64bit architecture on a 32bit little-endian architecture, or any of the other 48 supported archs. More than that, I can build a complete NetBSD for any arch on any halfway POSIXish system.
build.sh bootstraps its own contained build utils (compiler, binutils et al) and builds the system with that. You can even build the complete system as non-root and get tarballs that you can use to install a complete system.
To think that my weak SPARCstation 2 should build its own system would be madness. Instead, I just run build.sh -m sparc distribution on a dumb, fast i386 box and have a world in an hour instead of week(s).
Oh, and NetBSD "feels" the same on any arch, no administration nightmare, no matter what arch you run it on.
Just FYI.
On another OS, like MacOS X, UNIX or even maybe NT 3.5 or Windows 2K (if you know a lot) you can actually fix the OS.
Sorry, this attitude has no place when the system was compromised. Working with the system to fix it is dangerous when the tools you work with are not trustworthy anymore.
You could selectively "restore" system binaries using tools like tripwire. OTOH, "restoring" the system for example by compiling a fresh system from source on the compromised system itself would be stupid since the compiler could be compromised. Every output you get from ps(1) or top(1) or netstat(1) could be compromised and so on.
So when you say Well, what would you do? it tells me that you aren't even aware of another way of coexisting with a computer. OK. Maybe you are, but it points out that this is the "ONLY" way to fix a Windows XP install. The thing is to blinking convoluted to repair.
Remember, this is not about fixing your average XP install that has become rotten over time. It's about a system that was maliciously modified to cover the tracks of the intruder and to possibly provide hidden entry points to the intruder later.
The point is, you don't run any code from a compromised system. You wipe the system, install (the same or another system) from fresh install media and restore your data (not programs, not scripts without review, nothing except non-executable files).
While the "format and reinstall" attitude in the perspective of just running a system over a long time is certainly wrong, it is crucial after a security breach.
I got $5 that says this translates to "formatted and reinstalled the OS..."
Well, what would you do?
For the low-level stuff Uli is talking about (glibc, GCC), supporting minority targets is troublesome even when the best of coding practices are put to use.
Granted, NetBSD uses GCC, but I don't see NetBSD's libc causing much trouble on the 48(?) archs it runs on. I'm sure if the NetBSD people were using their own compiler, it would be of equal quality.
I don't want to dismiss GCC here, I just don't buy the "supporting more targets slows down the project". In my uninformed opinion this is more a sign of bad design to begin with.
But what do I know, I just use code, I don't make it.
Very good point. Supporting minority platforms is only troublesome if your code is riddled with i386isms and lazy coding practices. If you do it right the first time with always portability in mind, not only will you get cleaner and more maintainable code, you also get the ability to run just anywhere as a bonus. My prime example as usual is NetBSD.
/x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(85): warning: pointer casts may be troublesome [247] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(94): warning: pointer casts may be troublesome [247] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: bitwise operation on signed value possibly nonportable [117] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: possible pointer alignment problem [135] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: pointer casts may be troublesome [247] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: possible pointer alignment problem [135] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: pointer casts may be troublesome [247] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: possible pointer alignment problem [135] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: pointer casts may be troublesome [247] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: possible pointer alignment problem [135] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: pointer casts may be troublesome [247] /x/s.NetBSD.netbsd-3/crypto/dist/openssl/crypto/de s/fcrypt_b.c(111): warning: bitwise operation on signed value possibly nonportable [117]
It's sad that whenever you build some GNU sources or the latest Linux app du jour you get tons of warnings. Some projects even compile their files with 2>&1 >/dev/null. How sad is that?
It's not just the Linux folks. OpenSSL is actually worrying me:
etc. etc.
And this in a project that's driving quite an amount of sites, authentication mechanism and what not?
Most if not all of the sources that are native to NetBSD, i.e. not imported like OpenSSL and GCC compile without any warning. You automatically get a good feeling about using it.
Something needs to change in coding land.
</rant>
Let me get this. All you did was saying:
1) IPv4 has a lot of addresses which don't suffice anymore
2) IPv6 has more
and you provided complete nonsense about how IPv6 addresses look like. Now you blame me for only correcting the technical aspect and not reaching out to explain the big picture which you didn't either. On top of that, 340282366920938463 sextillion are 340 undecillion.
NAT rewrites addresses, it is not a firewall and it does not provide decent security in itself.
Sorry, but that's just rubbish. IPv4 adresses are 32bit, IPv6 addresses are 128bit.
IPv6 addresses are represented by 8 blocks of 16bit numbers in hex: 1234:1234:1234:1234:1234:1234:1234:1234. Leading zeroes in a block can be omitted. The biggest continuous all-zero block can be omitted entirely: 0123:0000:0000:0000:0000:0123:0000:1234 is equal to 123::123:0:1234.
IPv6 is 340282366920938463 sextillion addresses, not just "275 trillion".
When IPv6 comes and I have my own address I may have to buy an IPv6 NAT box just for safety's sake.
WTF? See if you can make something out of the following two lines:
block in from any to any
pass out from any to any keep state
NAT for IPv6 is the most stupid thing I've seen today.
NAT is a "Good Thing"(tm) because most machines shouldn't have incoming access from outside their LAN.
That's what packet filters are for.
I don't talk about the danger during the upgrade, but when the modification you made causes to box not to boot.
In fact, there are special IPv6 multicast and anycast addresses which devices on a certain scope will reply to even if not addressed directly.
Actually you can have two serial ports on the wrt54g, and an SD card slot if you want.
After some googling I figure that's for people who like to get their hands dirty with soldering and hacking hardware instead of software, i.e. not for me. But thanks.