Data Center is our focus

We help to build, access and manage your datacenter and server rooms

Structure Cabling

We help structure your cabling, Fiber Optic, UTP, STP and Electrical.

Get ready to the #Cloud

Start your Hyper Converged Infrastructure.

Monitor your infrastructures

Monitor your hardware, software, network (ITOM), maintain your ITSM service .

Our Great People

Great team to support happy customers.

Friday, October 15, 2010

Three common IT consultant security blunders

Posted in:


IT consultants cannot afford to make a mistake when it comes to security. Erik Eckel offers a refresher on basic security fundamentals. ---------------------------------------------------------------------------------------------------- Humility is an important quality in IT consultants. The industry has a way of knocking consultants down a peg and reminding professionals to mind their fundamentals when overconfidence sets in. Security, however, is an area in which consultants can't afford lapses, especially since Sarbanes-Oxley, HIPAA, and data sensitivity have become critical issues. When I inherit systems, servers, workstations, and networks developed and administered by others, I see other IT consultants' mistakes. I've also seen security failures at the companies where I've worked. Some security errors are simple brain-dead mistakes, such as affixing administrative usernames and passwords to a server via a Post-it note; other security offenses are less subtle, such as using the same password structure for each client. (Because of one competitor's administrative password naming scheme, I can now log on to any of their clients' systems replicating a simple password pattern.) Of all the security failures that I've seen, there are three common ones that stand out. Review your consultancy's practices to ensure clients are protected from these blunders.

1: Permitting simple passwords

I'm truly shocked at how many so-called IT professionals permit users and colleagues to set simple passwords that consist of just letters and even words found in common dictionaries. Simple passwords are easily hacked, which can lead to identity theft, unauthorized use of proprietary data, embarrassing leaks, and federal data standard violations. In racing, when newbies complain of the cost of a good helmet, the seasoned veteran answers, "If you have a ten-dollar head, wear a ten-dollar helmet." If a client has gone to the trouble of investing heavily in firewalls, encryption applications, and additional security parameters, they should invest in requiring complex passwords. Whether the client is protecting a router, a user account, an email address, or another system, you need to insist that employees use eight character or longer passwords that use all of the following: uppercase letters, lowercase letters, numbers, and special characters. Sure, such passwords are inconvenient, but that's the point. Passwords are a critical component of typically multiple-tiered security systems that are all too often negated as a result of nonchalance. If I can memorize the 26 phonetic alphabet codes, and coworkers can commit to memory the 486 tongue-twisting words to the I Am The Very Model Of A Modern Major General song from The Pirates of Penzance, users can memorize eight to 10 or more characters. Also, be sure your passwords don't follow the same naming patterns because that's too simple, even if you use complex characters. For example, if one discovers that Acme's server administrative password is Acme*123, it's not going to be too difficult to determine that the Smith company's administrative password is Smith*123, is it?

2: Deploying equipment using default passwords

IT consultants who deploy business-class equipment using default passwords should return whatever service fees they collect to their clients. Exhaustive lists of default passwords are a simple Google search away. This is exponentially more important when deploying routers, firewalls, and other systems that are accessible from the Internet. As I explain to clients, your data or company doesn't need to be all that sexy to be of interest -- far from it. Hackers write robotic programs that scour the Internet for nodes that respond. Once a node responds, the device becomes a target for attack. This is true whether the device is stationed inside a plumber's office or a bank. When organizations need to ensure remote administration of devices is possible, your office can work to restrict authorized connections via originating IP addresses to tighten security. But whenever a security device or any node is connected to the Internet, default passwords should be changed. By using tough-to-crack passwords on equipment, you make it difficult for unauthorized users to gain access, whether those unauthorized users are bored internal employees, angry and disgruntled ex-workers, or black hat criminals.

3: Sharing passwords via unencrypted email

It never fails. Organizations invest in enterprise-class firewalls, deploy disk encrypting software, and institute multiple-tiered logins -- which each require different usernames and passwords that must regularly be reset and cannot match previously used passwords -- and then someone emails the keys to the kingdom via unencrypted email. Forwarding administrative passwords via unprotected email, even to authorized users or colleagues, is a practice all IT consultants should eliminate. Email is inherently insecure. Messages pass not only through the sender's email server but to the recipient's server and through an inestimable number of systems in between. Each step in the chain offers the potential for unauthorized users. I used to be more cavalier regarding security, but years of IT consulting and experiencing the myriad and shocking ways in which businesses battle competitors, disgruntled staff, and others, I place a much greater emphasis on following security fundamentals. One excellent security fundamental that will help keep systems safe is avoiding sending passwords via clear text email. Just don't do it
Infrastructure-Application-ManagedServices.Visit for details..

IT consultants, document your work!

A client called on me to add a new feature to their software: nothing too fancy, just a search function with multiple criteria. Given the nature of their application, I had to wonder how they had gotten along without it for so long. We spec'd out their requirements, and I implemented it at an hourly rate in less time than they expected, including documentation and testing. Everybody was happy. A week or so later, the same client asked me to research an unrelated problem they were having. While looking through the code that had evolved from the sculpting of numerous hands over the years, I discovered a routine named LKPMCD. Perusing the all-uppercase comment-free code, the meaning of this cryptic name began to emerge. It was a LooKuP routine for Multiple ConDitions -- almost identical in its function to the project I had just completed, though of course my code was better (it always is, isn't it?). The client didn't even know they possessed this routine, because everyone in the organization who ever knew about it had moved on, and the documentation existed nowhere, not even in comments. Rediscovering the routine required a code archaeologist like myself to have the good fortune to stumble upon it and the curiosity to decypher it. I bet you're wondering whether I told the client that they wasted money on the job. Well, I did. First of all, I'd rather bring it to their attention than have someone in their organization discover it later and accuse me of fabricating the work. Better yet, though, I used the opportunity to make a point about the usefulness of good documentation. "Had anyone documented this routine anywhere," I said, "you could have not only saved the cost of implementing it again, but you could have been using it all this time." They concurred, blamed the former employees, and posed no objections to my bill.

Document these sorts of things

Requirements (features): Early on in the project, you should define what the client wants the product to do in specific terms. You can generate some requirements initially from brainstorming, but you should also engage your client in nailing down specific use cases to ferret out more detailed requirements. Also, explore all of the edge cases and exceptions that you can. This document should evolve with the project, because you can never know everything up front. Make sure you keep it up to date, because it should serve as the basis for testing and user documentation. The requirements doc can usually become the system documentation at the end of the project.

Constraints: Make sure to express the limits imposed upon the project. What won't it do? What minimum versions of other software does it need? What features that similar systems might provide are being intentionally excluded from this one? You can often include these constraints as part of the requirements doc.

Commitments: The project schedule needs more than a verbal OK, and so does the allocation of resources. Write it down, whether it's your commitment or theirs. You don't necessarily need a formal document -- email can work, as long as you can verify receipt and keep it organized for quick retrieval.

Implementation: You should comment code, but only comment the non-obvious. You should assume that the person reading the comments is capable of reading the code, and avoid explaining commonly used algorithms or features of the language (unless they're esoteric). You should explain "tricks" that might deceive the reader, and algorithms that may be difficult to understand. Most importantly, you should document your intentions -- the "why" instead of the "what" or "how".

Documentation: Yes, you should document your documentation. Provide a map, so when the next person comes looking for something, they'll know where to look. This can be as simple as a single web page that links to all of the project's related documents.

To facilitate updating and sharing, you should consider using a wiki for this documentation. Passing PDF or DOC files back and forth is so last millennium -- it requires unenforceable, exclusive locking of each document, wastes a lot of time emailing and saving attachments, and exposes that documentation to the security risks of email. For tips on writing good documentation, read the TechRepublic column 10 things you can do to create better documentation by Alan Norton.

What thorough documentation provides you and your client

You know what you've got and what you don't have.

You've set clear expectations, so you reduce or eliminate unpleasant surprises.

When someone comes along later to add a new feature, they can tell what's going on (even when that someone is you).

Include documentation in your contract

Documentation doesn't magically appear by itself, and I've never seen any evidence of the rumored Documentation Elves. So you need to allocate time in the project for writing documentation at all stages. Your client needs to be on board with that resource commitment, so include documentation as one of your deliverables in your contract. It's a vital part of the product.
Infrastructure-Application-ManagedServices.Visit for details..

Wednesday, October 13, 2010

3 Tahap Membuka Password Windows dengan Ubuntu

Tips Windows
3 Tahap Membuka Password Windows dengan Ubuntu
Wicak Hidayat - detikinet

ilustrasi (ist.)

Jakarta - Lupa memang masalah yang biasa dihadapi manusia. Jika lupa password login Windows, ada cara untuk memulihkannya dengan menggunakan sistem operasi Ubuntu Linux.

Hal pertama yang perlu dilakukan adalah membuat Live CD atau Live USB Flashdisk Ubuntu Linux. Ubuntu Live ini akan digunakan untuk booting ke sistem dan melakukan prosedur yang dibutuhkan untuk membongkar password Windows tadi.

Cara paling mudah untuk melakukan itu adalah dengan men-download UNetBootin dan menjalankannya. Aplikasi sederhana ini akan men-download versi Ubuntu yang dipilih dan melakukan instalasi pada flashdisk yang Anda siapkan.

Tahap kedua adalah menginstall utility Open Source bernama chntpw. Hal ini dilakukan dari Ubuntu dengan menjalankan Synaptic Package Manager.

Untuk bisa mendapatkan chntpw, Synaptic Package Manager harus diarahkan untuk melihat pada penyimpanan aplikasi Universe. Hal itu bisa dilakukan dengan mengklik menu Settings > Repositories pada jendela Synaptic. Kemudian, centang pilihan 'Community-maintained Open Source software (universe)' dan klik Close.

Setelah itu, klik tombol Reload dan Synaptic akan men-download informasi paket terbaru dari Universe. Setelah selesai, ketikkan chntpw pada kotak Quick Search.

Jika sudah muncul, centang kotak di sisi tulisan chnptw, pilih 'Mark for Installation'. Lalu klik Apply untuk menginstalnya.

Tahap ketiga adalah mengubah password Windows dengan chntpw.

1. Mount hardisk / drive yang berisi instalasi Windows Anda
2. Buka hardisk itu (klik Places) dan catat label drive yang muncul pada menu bar jendela file browser
3. Buka jendela Terminal (Applications > Accessories > Terminal)
4. Ketik perintah berikut pada Terminal:
cd / media
5. Ketik: cd [label hardisk yang tadi Anda catat]
6. ketik: cd WINDOWS/system32/config
7. Untuk mengubah password Administrator, ketikkan perintah: sudo chntpw SAM
8. Akan muncul beberapa perintah yang bisa Anda pilih, perintah paling aman adalah membuat password jadi kosong. Lakukan ini dengan menekan angka '1', lalu tekan 'y' untuk konfirmasi
9. Pilih '2' untuk mengubah password ke kata tertentu, namun hal ini memiliki risiko error lebih besar
10. Untuk mengubah password user lain (non-administrator), ketikkan perintah berikut (dari Terminal): sudo chntpw –u [nama user] SAM

Sunday, October 10, 2010

Selamat kepada Plasa Telkom Yos Sudarso

Selamat kepada Plasa Telkom Yos Sudarso, Jakarta yg baru saja selesai mengimplementasikan sistem antrian multimedia finosSQM. Kami bangga melayani Anda.

Infrastructure-Application-ManagedServices.Visit for details..