M. Fahrizal Rahman Blog

“Older men declare war. But it is the youth that must fight and die..” -Herbert Hoover

About

Proin accumsan urna in mi. Aenean elementum egestas tortor. Donec neque magna, auctor a, dapibus sit amet, facilisis sit amet, ligula..

UGM, at the final moment…

December 28th, 2007

rasanya sedih juga meninggalkan tempat ini, setelah lebih dari setahun bekerja bersama orang-orang yang menurut saya hebat. tapi apa lacur, show must go on, saya harus pergi untuk menuntaskan sesuatu yang sangat mengganjal dalam hidup saya, ini harus segera saya tuntaskan.

mungkin hal ini bakal jadi salah satu resolusi di tahun 2008, manusia khan hanya wajib berusaha, gak wajib hasil, yah, at least saya harus perform dengan apa yang saya miliki, bila itu tidak cukup, maka belajar adalah jawaban yang pasti, tapi.. apa sih yang cukup didunia ini??

terus terang banyak sekali hasil yang saya dapat dari bekerja dengan orang-orang hebat tersebut, tidak hanya pengalaman bagaimana bermain dengan mesin-mesin skala besar, tapi juga trik bermain dengan orang-orang berskala besar, sungguh loh, saya terkesima sekali, bagaimana tidak? sebuah institusi sebesar UGM masih memikirkan nasib nya(yang mereka bilang semakin tidak jelas?) dimasa mendatang.. bayangkan,,

ditempat ini juga saya belajar tentang arti kebersamaan, tidak hanya gotong-royong secara harfiah, ia punya nilai lebih dari itu, kadang personifikasi, alegori, ironi, bahkan hiperbola, ini bukan pelajaran bahasa indonesia, tapi memang begitulah adanya, saya juga baru menyadari bahwa dunia ini tidak bisa dipandang hanya dengan sebuah lensa, atau menatapnya dengan kacamata kuda? how come? semua orang ingin punya peran, dan karenanya kita butuh lensa lain untuk memahami perubahan lingkungan.. intinya kebersamaan.

bagaimana soal alih teknologi? sebagai “orang luar “, saya boleh dibilang dapat mencicipi berbagai macam trend yang ada pada mereka, apa yang sudah, sedang dan akan dikembangkan pernah juga saya cicipi, tidak banyak, tapi cukup, namanya juga nyicip :D

akhirnya, saya cuma bisa bilang, selamat bagi UGM, sebuah institusi luar biasa dengan orang luar biasa didalamnya. Slamat tinggal…

Popularity: 36% [?]

Sepanjang sejarah saya beli buku, apalagi yang non IT related, Starbucks Experience ini yang paling asik untuk dibaca, benar-benar hot, saking hotnya saya gak bisa begitu saja melewati setiap baris yang ada, rasanya, ini seperti buku cerita yang menuntut sipembaca untuk menjadi subjek dari apa yang diceritakan.

Lakukan dengan cara anda! - Itu adalah langkah awal pertama yang diceritakan dalam buku itu, susah juga buat saya, bukunya menceritakan tentang orang lain sambil “memaksa” saya memikirkan apa yang saya harus lakukan bila menjadi orang tersebut??

Membuat sebuah konsep baru yang buat sebagian orang tidak masuk akal namun akhirnya sukses besar, begitulah kebanyakan bisnis yang berjalan sukses, tapi Starbucks, ia punya cara sendiri, sebuah pendekatan personal yang seringkali dilewati(karena dianggap remeh).. dan cita2 pun terlampaui.

so HOT!

Popularity: 36% [?]

Who is using your Network?

October 22nd, 2007

By Kapil Hari Paranjape

Taken from LinuxGazette.com

 

1  The Evil That Lurks Within

Securing a local network (LAN) usually means creating firewall rules, host access rules and proper configuration of Mail, DNS and web servers. All these methods are primarily based on the assumption that the threat to your network is from the big bad internet. In this article I will take a reverse point of view—that is, users of the local network who are (possibly) the bad guys.

Such an assumption may be justified in the following contexts:

  • The network is large one, like a campus-wide network. The network administrator has no knowledge of or control over all the different computers that are connected to the LAN.
  • A typical wireless network where everyone in your neighbourhood can use your internet link.
  • You are in a cut-throat corporate office (perhaps this applies to some academic departments as well) where you do not really trust your colleagues—and all of them wear black-hats.

Although I spoke about “users” above, the real actors in a computer network are computers. By making the (often false!) assumption that each computer is doing exactly what its user wants it to do, I will reduce the question to the following:

How can computer Abdul that wants to talk to computer Chin be reasonably confident that computer Betaal is not able to intercept the conversation and/or impersonate Chin?

2  Not a telephone network

In order to understand why a slightly sophisticated solution is required, we need to realise that a LAN is a not like a telephone network and an IP address is not an identifying label in the same sense that a telephone number is.

The more sophisticated reader will know about “hardware” addresses (also known as Ethernet or MAC addresses) which are built into the hardware unlike IP addresses. However, the description of the network given in the paragraph below is equally appropriate if you replace “IP address” with “MAC address”.

A typical LAN is a packet based network. Each computer is always “connected” to all other computers. Conversations are based on packets which are sent “via the wire” and are “heard” by all the computers on the network. Each packet is labelled by the recipient’s IP address so that the relevant party can “listen to it” (in other words, copy it to its memory). The packet also contains sender’s IP address so that the recipient knows where to send replies.

Computer Betaal (as the ghost in the machine) can collect (copies of) packets meant for any destination and can also inject packets with any label(s) desired.

So, Abdul must (digitally) sign every packet sent out and encrypt it so that only Chin can read it. If Abdul only signed the packets, then Betaal (still) could collect them. Since there are a lot of packets that make up any conversation, Betaal could re-send the packets later in a more profitable order—thus delivering a blow to Chin. If Abdul only encrypted the packets then Betaal could inject his own encrypted packets of gobble-de-gook (illegible/undecipherable data) and disrupt the conversation between Abdul and Chin.

Let me re-state this in jargon. “In a packet based network, secrecy and authenticity go hand in hand.”

3  Secure Shell

When Tatu Ylonen originally wrote ssh it was thought of as a replacement for telnet and rsh which are programs/protocols for remote logins (for remote shell access). However, ssh is a network protocol, so it can be used to create secure conversations between computers.

Each SSH server has a private key—usually located at /etc/ssh/ssh_host_rsa_key. Often, there is a second private key in /etc/ssh/ssh_host_dsa_key. Network administrator’s job is to collect public keys associated to each of these private keys (in the same place, with a .pub extension) and distribute them to all computers on the network.

The simplest way to do this is to go to each computer and copy these files to a USB stick:

   cp /etc/ssh/ssh_host_rsa_key.pub /media/usb/<ip_addr>.rsa.pub
   cp /etc/ssh/ssh_host_dsa_key.pub /media/usb/<ip_addr>.dsa.pub

Admin then creates a “known hosts” file:

   for type in rsa dsa
   do
       for i in /media/usb/*.$type.pub
       do
         addr=$(basename $i .$type.pub)
         (echo -n "$addr "; cut -f1-2 -d' '< $i)>> known_hosts
       done
   done

This known_hosts file is then copied to /etc/ssh/ssh_known_hosts on each computer. Finally, we set configuration parameters

   echo "StrictHostKeyChecking yes" >> /etc/ssh/ssh_config

on each computer. (Users on each computer may also need to modify the configuration file $HOME/.ssh/config if it exists and remove/edit $HOME/.ssh/known_hosts if it exists).

After this (admittedly) long-winded (but not difficult) procedure, Abdul and Chin have each other’s public keys. So, Abdul can encrypt packets which only Chin can read and Chin can verify signatures made by Abdul. (The actual SSH protocol is more complex and doesn’t concern us here).

So, now, on Abdul one can do ssh Chin and be confident that it is Chin who is answering. Chin will still ask for the password unless all servers enable HostBasedAuthentication in /etc/ssh/sshd_config. This procedure might be risky for Chin, unless the root user on Abdul is to be considered equivalent to the root user on Chin.

What about other (than SSH) types of data exchange? Luckily, this too has been thought of. If Abdul wants to open TCP port (say) 80 on Chin now, then Abdul runs

   ssh -q -f -N -L 8080:localhost:80 Chin

Now, opening http://localhost:8080 on Abdul gives Chin’s web server.

What about securing all of data exchange? This has been thought of as well. In fact, SSH provides at least two ways:

  1. Applications that can use the SOCKS protocol (like Mozilla and Thunderbird) can use a tunnel created by this command:
             ssh -q -f -N -D 1080 Chin

    There are also wrapper libraries like tsocks that can “teach” any TCP application to use SOCKS.

  2. One can also create a TCP host in the LAN which supports encrypted traffic. This allows one to enable this configuration on all hosts in LAN one host at the time without disrupting the existing network in the process. Once all hosts are configured for IPsec, this can be replaced with

       spdadd $IP_ADDR $NETMASK any -P out ipsec
          esp/transport//require
          ah/transport//require;
    
       spdadd $NETMASK $IP_ADDR any -P in ipsec
          esp/transport//require
          ah/transport//require;

    6  Conclusion and Acknowledgements

    Now, it is relatively easy to configure machines to use encryption and authentication in a local area network. Today, computers and networks are fast enough, so extra calculations and extra network packets, that are required for this, do not cause noticeable delays. Also, it is quite easy to implement such a solution without bringing down the entire network until all machines are reconfigured.

    So! What are you waiting for? Choose a solution that is appropriate for your use and put it into use!

    In the IMSc network we have tested and implemented the openvpn solution. A number of my colleagues here helped debug various aspects of this. I thank them all for their help. The documentation of ssh and openvpn is also very good. There is a number of great articles on IPsec including those from LG that have been mentioned above. I thank the authors of these documents for their assistance.

    Popularity: 18% [?]