Done. Node will now be removed automatically from the site if it is down for more than a week.
Thank you very much, my friend. It is a great relief to my eyes when the search of your site no longer shows the record of my stupidity when I was testing my IPv6 network overlay. Hopefully it also lowered the load on your scanner. |
|
|
|
This is called security by obscurity. It works until it doesn't, and the guy happens to know how to work that system. Does it make you safer? Maybe. Is it worth your time doing this compared to other measures? Probably not.
It's probably safer to know how to secure Linux than to use a system you are not familiar with.
You are actually completely wrong. Those systems are significantly safer for two reasons: 1) they are (AIX & Solaris) or support (HP/UX with their PA/RISC emulation) big-endian binaries which for some strange but reproducible reasons seem to confound the vast majority of hackers/crackers and other mediocre programmers. 2) they are targeted for psychologically mature customers with stable requirements and not beholden to chasing most recent advance, change, regression, marketing trick of Microsoft, Google, and many others. Definitely there's a component of obscurity in their safety, but it is a good obscurity, not a marketing euphemism for weak secrecy. The true, large scale, hacking statistics are hard to come by. I believe the F5 Networks has the best statistics gathered through their application delivery appliances. But their keep it secret besides disclosing a little in their configuration examples how to remap the HTTP server names & fingerprints to trip up automated & scripted hacking tools. |
|
|
|
Excellent. Another one to suggest for the list. Ad hominem anyone?
I'm not taking advice; I've read it. I've asked for elaboration and sources nothing else. You failed to provide any.
I'll actually change "smartass" to "dumbass" if you are unable to find a source on the Internet that SPARC in a native big-endian architecture. Edit: I'm going to actually quote today's post by gmaxwell in another thread. It isn't ad-hominem, it is more like ad-chimpanzeem. No one is advocating "just ignoring"; but the fact that we're not yet able to completely mitigate the risk of harm due to chimpanzees with firearms does not mean that it would be wise to start handing out uzis at the zoo or, especially, that we're somehow obligated to arm those primates who have failed find any firearms on their own.
|
|
|
|
We are discussing the feasibility of creating our own hosting location, having our own facilities, not giving another random 3rd party access to the server. I thought you were aware that the hosting company staff were the weak link in this hack. The way to get around that, is to change to a facility operated by an employee of the Bitcointalk. That would involve building our own infrastructure, hiring staff to monitor its physical location, etc. That would also involve owning property to build on.
If we just rent server space from an already established company, we face the same issues. Not having complete trust of the people who have access to the server. So if we are talking about just changing hosts to something that isn't a large operation in a giant datacenter to a shared location with a couple of other people, we still have to worry about the human factor.
Man, you really have comprehension problems. I'll repeat: colocation a privately owned server solves nearly all the avenues of "social engineering" attack. By "privately owned" I mean server not leased from the hosting company but a server owned outright or leased independently from the server manufacturer or distributor. The colocation staff will then only have as much access as you decide to provide them, typically limited to pushing buttons, inserting media into tray and connecting cables. The hacking risk is limited to intentional damage or physical theft. And please quit your "large operation" "giant datacenter" bullshit. Colocation space can be bough in 1U units (1.75 inch height, 19" wide, varying depth around 1meter). Employee time can be bought in quarter-hour increments. The "human factors" are limited to physical theft that is extremely rare and easier caught and prosecuted. |
|
|
|
Are you by any chance trying to say that I falsified data? I pulled it from a source that should be much more credible than your words. Saying that they have different security profiles doesn't make them secure. Now, why did someone even mention this?
You are just another smartass who probably couldn't recognize a big-endian box even if it dropped on your head. There's no point of taking security advice from such "credible sources". |
|
|
|
OpenVMS is considered a highly secure and reliable operating system relied upon by large enterprises around the globe such as Stock Exchanges, Governments and Infrastructure for critical operations.
It is supposedly the most secure system in the world.
As well as many small & medium businesses that continue to run it on HP Integrity/Itanium boxes. You've got to be kidding. Check the graph.
I'm not kidding. This graphs is a classical example of data falsification. Solaris is actually a pair of quite distinct OS-es: the classic big-endian SPARC one and the newfangled little-endian on x86/x64. They have significantly different security profiles. |
|
|
|
I'm sure that one of the bigger hack groups like Anonymous would be able to hack that.
How "sure" you are? Wanna bet? They'll just DDoS them out of anger and claim success. |
|
|
|
It's the Internet; it's practically impossible for anything to be completely hack-proof.
Yeah, go hack OpenVMS, there are several freely accessible installations under the "enthusiast" license now offered by HP. |
|
|
|
uhh...what is advantage of running System P with AIX over System X with RHEL in terms of security? I really don't get this.)
1) System P is big-endian. Apparently big-endian-ness completely confuses weakly-skilled programmers to the point that their brains go "tilt". 2) Practice shows that unfamiliar environment of AIX greatly confuses the attackers, again to the point that they just do some damage and leave instead of stealing the data or wreaking some skillful havoc. I have years of practice in this field. Originally when young, I thought that it shouldn't be the case either, any person who is intelligent enough to program should be understand how to number bytes in a multi-byte integer. But the practice shows otherwise. For the confirmation of this fact go lookup various discussions of endian-ness on this forum and the source code for "getwork" in the Satoshi's client. |
|
|
|
There really isn't a whole lot we can do about attacks like that,
I see the time-share salesmen are spewing their bullshit in another thread. I'll repost here what I posted nearby: https://bitcointalk.org/index.php?topic=1068157.0Easily preventable on two levels: 1) collocate your own equipment in a remote data center. The customer service staff will simply have no access to it besides being able to press buttons on the box. 2) use non-commodity hardware like Oracle SPARC or IBM POWER or HP Integrity/Itanium. Then even if they manage to steal it they most likely will not be able to get the data off of it without specialized assistance. Also, don't run Linux on those machines, but their native OS: Solaris, AIX, HP/UX respectively. |
|
|
|
Are we really in 2015 ?!  No, we are in a time-loop. We went back to about 1970 when the sales of "time-shared" computer services were at their highest. "Time-share" term was later appropriated by the vacation real-estate salesmen, so the computer salesmen renamed their "time-shares" to "cloud computing". But the bullshit stayed the same. |
|
|
|
I wasn't asking for something that you spent 20 minutes or more figuring out, I meant a rough figure, because for someone who knows what they are doing, you are either grossly overestimating the forum's budget or underestimating the cost of setting up multiple datacenters in various countries and the unpleasantness that would come with that. The forum could support a single full time employee perhaps, not multiple + building expenses + interesting tax implications for owning physical property, and more tax issues for having physical property in multiple countries. I'm no expert on the matter, but even with absurdly and unreasonably low cost assumptions, we are still vast sums of money apart. I could set up a datacenter in a shed in my backyard for $5k. If Theymos wants to take me up on that offer, I'd be happy to oblige.
Dude, what can I say? You are not only a compulsive bullshit artist, but you've also mostly lost touch with reality. What buildings? What full time employees? What tax implications? One is true: I'm no expert on the matter . I am an expert, but I'm not really interested in learning the finances of this forum. It is up to theymos to scan his tax returns for bitcointalk and call Dell Small Business (or any other large reseller of electronics) financial department and ask them how much credit he's going to get for his non-profit organization. Literally millions of small business' owners done that before him. I could then discuss various technical details and options, but I'm too ethical to even joke about $5k hosting in a shed. All I have to say is my school had lots of wisdom retaining and maintaining the old mainframe. It allowed us to learn not only the technical details of virtualization (it was called VM/370 then, not KVM or whatever) but also experience first hand the bullshit from the time-share salesmen. The "cloud" terminology was not invented then, everyone used "time-share". Nowadays the "time-share" is a dirty word related to the vacation package sales. But the infectious anti-technical sales bullshit permeating the business is the same as it was through the 1960-1980 when it was popular. But before he's going to even scan the tax returns for the forum he'll need to ask himself a question "Do I give a flying fuck on a rolling donut about the information security of the members of this forum?" Maybe the true answer really is "I like to have a convenient 'scapegoat in the cloud'. I can always point to the sky and say 'It was their fault, not mine!'". |
|
|
|
Tell me then, how much would it cost to set up a datacenter in a couple of countries, buy the equipment, and hire employees? I think you are vastly overestimating how much the advertising revenue brought in could support.
I'm not going to give you a quote just to prove myself, I charge for such services and I'm positive that you are neither serious nor authorized to purchase anything. But one thing is worth mentioning: "hire employees". For a physical collocation "remote hands" services are usually available in increments of 15 minutes. What I'm positive is that after buying and paying for "remote hands" a couple of times, which normally involves a telephone/facetime/skype conversation with the remote contractor, the possibility "social engineering" essentially disappears. The worst "hack"s that did happen on my watch was nothing more than an equipment destruction or theft (for wipe & resale). |
|
|
|
I suppose its not entirely out of the question, but collocating our own equipment probably isn't the best idea either. It would be less than cost effective, and forum up time and reliability would be far less than it is with professional datacenters. What country to place the datacenter would be another issue, and hiring employees to manage it doesn't sound too appealing. It sounds like a complete mess, and something unnecessary for a forum. This is a website, a large one at that, but the Bitcoin forum isn't Google.
You are just bullshitting. I've been doing exactly that professionally (mostly as a consultant) for many years. Yeah, it is somewhat more expensive, especially in the upfront capital cost, but the operating expenses are frequently actually lower. It is a perfect solution for "a website" even with much less traffic than this one. In particular the reliability is better if the owner of the equipment is conscientious and willing to learn, because there is no blaming "somebody else". Also, the customer service staff for the physical collocation customers is typically way more responsible and conscientious. The "professional datacenters" that have equipment leasing included in their rental fees are the dreck of the datacenter business, because they by necessity serve mostly fly-by-nights. It seem to me like you've never owned the equipment in any datacenter so you don't really have a base to make a real judgment. |
|
|
|
For example, this recent hack, there is no reasonable solution that Theymos could have done to prevent this. If you know the solution, let us know  I posted the simple solutions elsewhere, I'll repost it here: https://bitcointalk.org/index.php?topic=1069837.msg11453289#msg11453289Easily preventable on two levels: 1) collocate your own equipment in a remote data center. The customer service staff will simply have no access to it besides being able to press buttons on the box. 2) use non-commodity hardware like Oracle SPARC or IBM POWER or HP Integrity/Itanium. Then even if they manage to steal it they most likely will not be able to get the data off of it without specialized assistance. Also, don't run Linux on those machines, but their native OS: Solaris, AIX, HP/UX respectively. |
|
|
|
|
Easily preventable on two levels:
1) collocate your own equipment in a remote data center. The customer service staff will simply have no access to it besides being able to press buttons on the box.
2) use non-commodity hardware like Oracle SPARC or IBM POWER or HP Integrity/Itanium. Then even if they manage to steal it they most likely will not be able to get the data off of it without specialized assistance.
Edit: Also, don't run Linux on those machines, but their native OS: Solaris, AIX, HP/UX respectively.
|
|
|
|
This is interesting, I think peercoin does that already since I've seen those files. Anyway, where can I get more information about trying this suggestion.
Actually, after checking, there is a command line/*coin.conf for this in the recent code: -privdb=0 . But no matter what you do you will have to read the Berkeyley DB documentation anyway. While I didn't run the most recent Bitcoin clients over NFS, I did quite a bit of load testing in times of version 0.6.3 (and thereabouts) and did not have anything like your problems. My professional opinion is that you are suffering from some sort of hardware problem or misconfiguration. NFS is quite fragile and tends to stress the infrastructure, especially if run over UDP. Check your port mapper RPC error statistics, verify the network switches for correct configuration of flow control, verify the correct operation of checksum offload in the drivers, etc. I didn't do anything serious then, the coin daemons were simply the second thing that popped into my mind when I had to think for a load test for our revamped/reinstalled NAS & SAN hardware running under Solaris 9 and 10. The first tests were actually "cp -rpv" of a terabytes-sized collection of Linux ISOs followed by "md5sum". There were some errors, but in particular all my wallet.dat-s survived without any damage. |
|
|
|
|
Hey "disclosure" a.k.a. Addy Yeow!
Could you please add deregistration to your site? Or maybe some form of automatic decay, so that nodes inaccessible for over a month get dropped from your scanner?
I rather thoughtlessly registered several of my test nodes and I wanted to move them to a better, more permanent addresses. It was easy to press "ADD" before thinking it through. Some sort of verification similar to your incentive registration should be a good and safe deregistration.
Thanks.
Edit: Fixed spelling of the first name.
|
|
|
|
|
I think you are doing things wrong. I understand that your problems are actually with BerkeleyDB.
1) always hard mount the NFS directories with the initial mount done in background if the server is not available (NFS mount options "hard,bg")
2) do the backups from the client side, not from the server. This way the backup program sees the most recent data. The backups done on the server are only consistent when the
3) change the initialization options of BerkeleyDB to make the memory mapped files visible in the file system (I think the files have names like "_db.000"). I don't remember if that can be done with simply adding flags to the "DB_CONFIG" or if it requires recompilation. With those files visible you can run the db_utils on the client while coins clients are running and make fully consistent backups using db_backup and do live consistency checks with db_verify. Just remember to add "set_lg_dir database" to the DB_CONFIG so the BerkeleyDB utilities can find the live logs.
With those caveats I've successfully run the BerkeleyDB-based programs over NFS for very many years with the central storage & build server, longer than the Bitcoin was in existence.
|
|
|
|
|
Show Posts
