Archive for July, 2009

Mengganti Hostname pada Distro Berbasis Debian

EKSPERIMEN
- June 5, 2009
Mengganti Hostname pada Distro Berbasis Debian
Pernahkah ada keinginan dari anda untuk mengganti hostname dari sistem anda. Biasanya ketika kita menginstall misal distro ubuntu hostname kita akan menjadi username-laptop dsb. Nah bagaimana kita mengubahnya? Caranya sebenarnya cukup simple. Buka terminal anda klik Application » Accessories » Terminal

lug@username-laptop:~$ sudo gedit /etc/hostname
Nah disitu ada nama dari hostname lawas anda, ganti dengan yang baru misal stikom-surabaya. Sistem seharusnya mengupdate otomatis file /etc/hosts karena ada perubahan di /etc/hostname namun untuk memastikan buka saja file tersebut:

lug@username-laptop:~$ sudo gedit /etc/hosts
Cari string hostname lama anda jika ada lalu ganti ke hostname yang baru. Untuk mengecek kita dapat menggunakan perintah sysctl.

lug@username-laptop:~$ sysctl kernel.hostname
kernel.hostname = stikom-surabaya
lug@username-laptop:~$
Agar tampilan prompt bash juga berubah silahkan buka session bash baru dengan menekan kombinasi Ctrl-Shift-T. Seharusnya tampilan hostname pada bash akan berubah menjadi yang baru.

lug@stikom-surabaya:~$
Selamat Mencoba ;)

Comments

Struktur Kabel USB + DC 5 Volt power Supply

 Struktur Kabel USB

Rangkain Voltage Regulator 5 Volt

Comments

Download ttf font For Captcha

http://www.webpagepublicity.com/free-fonts.html

Comments

Managing Apache2 modules the Debian way

The Apache2 HTTP Server is a modular program, where we can choose its functionality by including in the server a set of modules. The modules can be statically compiled into the httpd binary when the server is built. Alternatively, modules can be compiled as Dynamic Shared Objects (DSOs) that exist separately from the main httpd binary file.

Normally enabling one particular apache DSO module will involve editing the main apache configuration file and adding a LoadModule line to enable the loading of the particular module. Depending from the module itself, we might need to add also some configuration directives. This will work fine on Debian also, but I am going to show you the Debian particular method of managing apache2 modules.

Regardless of the apache MPM (Multi-Processing Modules) you are using: apache2-mpm-prefork, apache2-mpm-worker or apache2-mpm-perchild after the installation you will end up with some default modules: some already enabled and some ready to be used. Opposed to a RedHat based system for example (where they will try to enable all the possible modules) the Debian package will enable by default only a very small amount of modules.
Here are the modules enabled by default:

Compiled statically inside the apache2 binary: core, http_core, prefork/worker/perchild, mod_access, mod_auth, mod_log_config, mod_logio, mod_env, mod_setenvif, mod_mime, mod_status, mod_autoindex, mod_negotiation, mod_dir, mod_alias, mod_so.

  • You can get the list of compiled in modules from the command line with, apache2 -l
  • These modules can’t be disabled without recompiling the apache package
  • For more details on the build-in modules you can check Appendix 1.

Standard apache2 modules installed and ready to be enabled: actions, asis, auth_anon, auth_dbm, auth_digest, auth_ldap, cache, cern_meta, cgi, cgid, dav, dav_fs, deflate, disk_cache, expires, ext_filter, file_cache, headers, imap, include, info, ldap, mem_cache, mime_magic, proxy, proxy_connect, proxy_ftp, proxy_http, rewrite, speling, ssl, suexec, unique_id, userdir, usertrack, vhost_alias.

  • only one module is enabled by default: mod_userdir
  • You can enable any of these modules at any time with as shown bellow.
  • For more details on the standard modules installed you can check Appendix 2.

Other apache2 modules available: you can install additional apache2 modules that are not standard if needed. Probably you will like to have php installed that way, but maybe some others based on the particular need. The installation uses the regular apt commands, for example:

aptitude install libapache2-mod-php4

The list of additional modules that can be installed includes: mod-geoip, mod-jk, mod-mono, mod-perl2,mod-php4, mod-php5, mod-python, mod-rpaf, mod-ruby, mod-suphp.

  • For the full list of extra modules available you can check Appendix 3.
  • Normally when you install one of the extra modules the debian package will automatically enable it. If needed, you can disable it as shown bellow (if you don’t want to completely remove it).

Managing apache2 modules in Debian:

The Debian apache2 package provides a unique mode of managing modules. All the loading and configuration related entries are found in individual files inside folder /etc/apache2/mods-available/. Here we will find files like module_name.load (and if needed module_name.conf). Also all additional installed modules will place their configuration files in the same place.

Inside the folder /etc/apache2/mods-enabled/ we will find all the enabled modules. Here we will find symlinks to the files from mods_available for all the enabled modules. Only the modules found in this folder will be enabled at run time.

For example the configuration file for mod_rewrite includes only one line to load the module:
cat /etc/apache2/mods-enabled/rewrite.load
LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

So in order to enable one additional module we will only have to create the proper symlinks from the mods-available to the mod-enabled files… But why not use the little tools Debian provides us for this:

  • a2enmod: enables an apache2 module (this does nothing else but creates the proper links to the module .load and .conf files). For example to enable the rewrite module:
    a2enmod rewrite
  • a2dismod: disables an apache2 module (removes the links from mod-enabled for the module). For example to disable the rewrite module: a2dismod rewrite

Running a2enmod without any parameter will show the possible choices:

a2enmod
Which module would you like to enable?
Your choices are: actions asis auth_anon auth_dbm auth_digest auth_ldap cache cern_meta cgi cgid dav dav_fs deflate disk_cache expires ext_filter file_cache geoip headers imap include info ldap mem_cache mime_magic php4 proxy proxy_connect proxy_ftp proxy_http rewrite rpaf ruby speling ssl suexec unique_id userdir usertrack vhost_alias
Module name?

Running a2dismod without any parameter again will show us the list of enabled modules and allow to choose one:

a2dismod
Which module would you like to disable?
Your choices are: actions cgi deflate geoip headers info php4 rewrite rpaf ruby
Module name?

Don’t forget to reload the apache daemon, after making any changes to the list of enabled modules:

/etc/init.d/apache2 reload

Comments

NOD 32 Versi 4

http://www.blogcatalog.com/topic/nod32+4/

Comments

apt-get install build-essential

SERVER#apt-get install build-essential

Comments

Transparant Proxy Script…

Comments

Protected: INV LAST MENANGGAL RT/RW

This post is password protected. To view it please enter your password below:


Enter your password to view comments.

Membuat Sertifikasi SSL Sendiri Tanpa Pihak Ke-3

How to create a self-signed SSL Certificate …

… which can be used for testing purposes or internal usage

Overview

The following is an extremely simplified view of how SSL is implemented and what part the certificate plays in the entire process.

Normal web traffic is sent unencrypted over the Internet. That is, anyone with access to the right tools can snoop all of that traffic. Obviously, this can lead to problems, especially where security and privacy is necessary, such as in credit card data and bank transactions. The Secure Socket Layer is used to encrypt the data stream between the web server and the web client (the browser).

SSL makes use of what is known as asymmetric cryptography, commonly referred to as public key cryptography (PKI). With public key cryptography, two keys are created, one public, one private. Anything encrypted with either key can only be decrypted with its corresponding key. Thus if a message or data stream were encrypted with the server’s private key, it can be decrypted only using its corresponding public key, ensuring that the data only could have come from the server.

If SSL utilizes public key cryptography to encrypt the data stream traveling over the Internet, why is a certificate necessary? The technical answer to that question is that a certificate is not really necessary – the data is secure and cannot easily be decrypted by a third party. However, certificates do serve a crucial role in the communication process. The certificate, signed by a trusted Certificate Authority (CA), ensures that the certificate holder is really who he claims to be. Without a trusted signed certificate, your data may be encrypted, however, the party you are communicating with may not be whom you think. Without certificates, impersonation attacks would be much more common.

Step 1: Generate a Private Key

The openssl toolkit is used to generate an RSA Private Key and CSR (Certificate Signing Request). It can also be used to generate self-signed certificates which can be used for testing purposes or internal usage.

The first step is to create your RSA Private Key. This key is a 1024 bit RSA key which is encrypted using Triple-DES and stored in a PEM format so that it is readable as ASCII text.

openssl genrsa -des3 -out server.key 1024

Generating RSA private key, 1024 bit long modulus
…………………………………………………++++++
……..++++++
e is 65537 (0×10001)
Enter PEM pass phrase:
Verifying password – Enter PEM pass phrase:

Step 2: Generate a CSR (Certificate Signing Request)

Once the private key is generated a Certificate Signing Request can be generated. The CSR is then used in one of two ways. Ideally, the CSR will be sent to a Certificate Authority, such as Thawte or Verisign who will verify the identity of the requestor and issue a signed certificate. The second option is to self-sign the CSR, which will be demonstrated in the next section.

During the generation of the CSR, you will be prompted for several pieces of information. These are the X.509 attributes of the certificate. One of the prompts will be for “Common Name (e.g., YOUR name)”. It is important that this field be filled in with the fully qualified domain name of the server to be protected by SSL. If the website to be protected will be https://public.akadia.com, then enter public.akadia.com at this prompt. The command to generate the CSR is as follows:

openssl req -new -key server.key -out server.csr

Country Name (2 letter code) [GB]:CH
State or Province Name (full name) [Berkshire]:Bern
Locality Name (eg, city) [Newbury]:Oberdiessbach
Organization Name (eg, company) [My Company Ltd]:Akadia AG
Organizational Unit Name (eg, section) []:Information Technology
Common Name (eg, your name or your server’s hostname) []:public.akadia.com
Email Address []:martin dot zahn at akadia dot ch
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Step 3: Remove Passphrase from Key

One unfortunate side-effect of the pass-phrased private key is that Apache will ask for the pass-phrase each time the web server is started. Obviously this is not necessarily convenient as someone will not always be around to type in the pass-phrase, such as after a reboot or crash. mod_ssl includes the ability to use an external program in place of the built-in pass-phrase dialog, however, this is not necessarily the most secure option either. It is possible to remove the Triple-DES encryption from the key, thereby no longer needing to type in a pass-phrase. If the private key is no longer encrypted, it is critical that this file only be readable by the root user! If your system is ever compromised and a third party obtains your unencrypted private key, the corresponding certificate will need to be revoked. With that being said, use the following command to remove the pass-phrase from the key:

cp server.key server.key.org
openssl rsa -in server.key.org -out server.key

The newly created server.key file has no more passphrase in it.

-rw-r–r– 1 root root 745 Jun 29 12:19 server.csr
-rw-r–r– 1 root root 891 Jun 29 13:22 server.key
-rw-r–r– 1 root root 963 Jun 29 13:22 server.key.org

Step 4: Generating a Self-Signed Certificate

At this point you will need to generate a self-signed certificate because you either don’t plan on having your certificate signed by a CA, or you wish to test your new SSL implementation while the CA is signing your certificate. This temporary certificate will generate an error in the client browser to the effect that the signing certificate authority is unknown and not trusted.

To generate a temporary certificate which is good for 365 days, issue the following command:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Signature ok
subject=/C=CH/ST=Bern/L=Oberdiessbach/O=Akadia AG/OU=Information
Technology/CN=public.akadia.com/Email=martin dot zahn at akadia dot ch
Getting Private key

Step 5: Installing the Private Key and Certificate

When Apache with mod_ssl is installed, it creates several directories in the Apache config directory. The location of this directory will differ depending on how Apache was compiled.

cp server.crt /usr/local/apache/conf/ssl.crt
cp server.key /usr/local/apache/conf/ssl.key

Step 6: Configuring SSL Enabled Virtual Hosts

SSLEngine on
SSLCertificateFile /usr/local/apache/conf/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/server.key
SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown
CustomLog logs/ssl_request_log \
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b” 

Step 7: Restart Apache and Test

/etc/init.d/httpd stop
/etc/init.d/httpd stop

https://public.akadia.com

Comments

Debian Etch – Apache configuration #2

Continuing from the first Apache configuration article, we’ll now look at some of the other settings in the main apache2.conf file and what they can do.

Concentrating on efficiency and security, this will end our apache2.conf journey (for now).


ServerName

Remember that pesky “Could not reliably determine the server’s fully qualified domain name” message when reloading Apache?

Let’s get rid of that by defining the ServerName.

The ServerName is usually a hostname or a FQDN (Fully Qualified Domain Name). In this case, I am going to use the Slice hostname. It can also be set as ‘localhost’.

So open the apache2.conf file:

sudo nano /etc/apache2/apache2.conf

and add this:

ServerName etch

Of course, change the hostname to your Slice hostname or a FQDN. Once done, save apache2.conf and gracefully restart Apache (this method of restarting won’t kill open connections):

sudo apache2ctl graceful

No warning. Nice.

HostnameLookups

Default:

HostnameLookups Off

If you want happy users and to save traffic, keep this at Off.

Setting this to ‘On’ will enable DNS lookups so host names can be logged (it performs a reverse DNS check), setting it to ‘Double’ will not only perform the reverse DNS check it will then check the resulting hostname.

All a bit much and if you desperately need hostname information from your visitors it is advised to use logresolve (located in /usr/sbin/logresolve) for this purpose. A small explanation can be found here.

ServerTokens

Default:

ServerTokens Full

The ServerTokens setting will dictate how much information is sent in the Headers with regard to Apache version and modules in use.

The default (Full) would send something like this:

Apache/2.2.3 (Debian) PHP/5.2.0-8+etch7

Does this make a difference? Well, yes. If we can suppress that information it will make it harder for someone to find an exploit.

It does not make the actual install any more secure but all someone has to do right now is look for an exploit in Debian Apache 2.2.3 and so on. Why make it easy for them?

The options are (with example outputs):

Full

Apache/2.2.3 (Debian) PHP/5.2.0-8+etch7

OS

Apache/2.2.3 (Debian)

Minimal

Apache/2.2.3

Minor

Apache/2.2

Major

Apache/2

Prod

Apache

It’s up to you what level of info you want to give out. I prefer setting ServerTokens to Prod.

ServerSignature

Default:

ServerSignature On

Server generated pages, such as 404 pages or directory listings, can contain a footer line which includes server information and can include the ServerAdmin email address.

If you navigate to your Slice IP address and a non-existent page:

http://123.45.67.890/blahblah

You will see a 404 Page not found page with the footer information:

Apache  ServerSignature

The options are:

Off: Produces no footer

On: Produces footer information (at a level defined by the ServerTokens setting)

Email: Adds an email link to the information (level defined by the ServerTokens setting)

It doesn’t work!

If you are experimenting with the settings in the main apache2.conf file and find that changing the ServerSignature setting does nothing then keep in mind that many settings can be overridden by the virtual host file.

In this case, the default virtual host file has:

ServerSignature On

So open the file:

sudo nano /etc/apache2/sites-available/default

Change the ServerSignature to On, Off or Email.

Reload Apache after any changes to the virtual host file and voilà! All is good.

Summary

Some simple steps in this article but ones which I believe are very useful and aid in increasing the efficiency of your Slice and assist in the overall security effort on your Slice.

PickledOnion.

Comments

« Previous entries Next Page » Next Page »