Archive for the ‘archlinux’ Category

Forward root mail from localhost to your gmail or whatever …

*nix server always sent email about cron or anything than you have to read it. but how …

ssh and issued this command

bsd# mail

than you can read your email. but if you wanna forward your email to gmail or yahoo or whatever.

bsd# cd /etc

bsd# pico aliases

put you email on..

# Pretty much everything else in this file points to “root”, so
# you would do well in either reading root’s mailbox or forwarding
# root’s email from here.
# root:
than issued this command
bsd# /usr/bin/newaliases
* than you will get your copy of root email.

TmNet DNS servers

Jaring DNS servers

TimeNet DNS servers

Open DNS  Server (overseas)

add from

Apa Itu Botnet?

Posted: April 24, 2010 in archlinux, Debian, Freebsd, Slackware

Botnet merupakan perkataan yang digunakan bagi koleksi perisian robot atau bot yang dijana secara automatik. Ia bergerak dalam komputer ‘zombie‘ yang dikawal secara mudah alih oleh penggodam. Proses mencuri sumber perkomputeran sebagai hasil sistem digabungkan menjadi botnet juga dikenali sebagai scrumping.

Perkataan botnet boleh digunakan untuk merujuk kepada satu kumpulan bot seperti IRC bot, iaitu perkataan yang biasa digunakan bagi merujuk kepada sekumpulan compromised computer (dinamakan komputer ‘zombie’), yang mana ia menjalankan program cecacing, kuda Trojan, atau backdoor (lubang) di bawah kawalan satu infrastruktur. Botnetoriginator (bot herder) boleh mengawal kumpulan berkenaan secara mudah alih dan biasanya atas sebab-sebab yang mencurigakan.

Bot biasanya bergerak secara sembunyi dan sukar dikenalpasti kerana ia mampu melindungi pergerakannya dengan menjadi sebahagian daripada internet. Bot baru boleh menyaring persekitaran mereka secara automatik serta mengembangkan fungsinya dengan menggunakan kelemahan pengguna. Apa yang lebih menakutkan, ia boleh menjadi botnet yang mengawal sesuatu komuniti.

Biasanya botnet akan melibatkan pelbagai medium perhubungan seperti dial-upADSL dan kabel serta pelbagai jenis rangkaian seperti pendidikan, korporat, kerajaan dan kadang-kala ketenteraan.

Kajian mendapati, satu perempat daripada semua komputer peribadi yang berhubung dengan internet mempunyai botnet.


Diletakkan disini slide dan bahan semasa Seminar berkenaan Botnet yang diadakan di ibu pejabat IMPACT Cyberjaya pada 14/4/2010 dianjurkan oleh TrenMicro.

Seminar ini bertajuk “”The Botnet Storm: Challenges & Global Cooperation”

This is how you secure your linux box.

1. Account Locking

Account locking for multiple failed tries puts extra burden on the system administrators but it also puts some responsibility on the user to remember his passwords. Additionally, locking allows the administrator to track the accounts that have potential hack attempts against them and to notify those users to use very strong passwords.

Typically, a system will drop your connection after three unsuccessful attempts to login but you may reconnect and try again. By allowing an infinite number of failed attempts, you’re compromising your system’s security. Smart system administrators can take the following measure to stop this threat: Account lockout after a set number of attempts. My preference is to set that limit to three.

Add the following lines to your system’s /etc/pam.d/system-auth file. 

auth required /lib/security/$ISA/ onerr=fail no_magic_root

account required /lib/security/$ISA/ per_user deny=3 no_magic_root reset

Your distribution might not include the system-auth file but instead uses the /etc/pam.d/login file for these entries.

2. Cron Restriction

On multiuser systems, you should restrict cron and at to root only. If other users must have access to scheduling, add them individually to the /etc/cron.allow and /etc/at.allow files. If you choose to create these files and add user accounts into them, you also need to create /etc/cron.deny and /etc/at.deny files. You can leave them empty but they need to exist. Don’t create an empty /etc/cron.deny unless you add entries to the /etc/cron.allow because doing so allows global access to cron. Same goes for at.

To use the allow files, create them in the /etc directory and add one user per line to the file. The root user should have an entry in both allow files. Doing this restricts cron to the root user only.

As the system administrator, you can allow or deny cron and at usage based upon the user’s knowledge and responsibility levels.

3. Deny, Deny, Deny

“Deny everything” sounds eerily Presidential doesn’t it? But for system security and certain political indiscretions, it’s the right answer. System security experts recommend denying all services for all hosts using an all encompassing deny rule in the /etc/hosts.deny file. The following simple entry (ALL: ALL) gives you the security blanket you need.


# hosts.deny This file describes the names of the hosts which are

# *not* allowed to use the local INET services, as decided

# by the ‘/usr/sbin/tcpd’ server.


# The portmap line is redundant, but it is left to remind you that

# the new secure portmap uses hosts.deny and hosts.allow. In particular

# you should know that NFS uses portmap!


Edit the /etc/hosts.allow file and insert your network addresses (192.168.1., for example) where you and your users connect from before you logout or you’ll have to login via the console to correct the problem. Insert entries similar to the following to allow access for an entire network, single host or domain. You can add as many exceptions as you need. The /etc/hosts.allow file takes precedence over the /etc/hosts.deny to process your exceptions.

4. Deny SSH by Root

Removing the root user’s ability to SSH provides indirect system security. Logging in as root to a system removes your ability to see who ran privileged commands on your systems. All users should SSH to a system using their standard user accounts and then issue su or sudocommands for proper tracking via system logs.

Open the /etc/ssh/sshd_config file with your favorite editor and change PermitRootLogin yes to PermitRootLogin no and restart the ssh service to accept the change.

5. Change the Default Port 

While changing the default SSH port (22) will have limited effectiveness in a full port sweep, it will thwart those who focus on specific or traditional service ports. Some sources suggest changing the default port to a number greater than 1024, for example: 2022, 9922 or something more random, such as 2345. If you’re going to use this method as one of your strategies, I suggest that you use a port that doesn’t include the number 22.

Edit your /etc/ssh/sshd_config and change the “Port” parameter to your preferred port number. Uncomment the Port line too. Restart the sshd service when you’re finished and inform your users of the change. Update any applicable firewall rules to reflect the change too.

System security is important and is a constant battle. You have to maintain patch levels, updates and constantly plug newly discovered security holes in system services. As long as there are black hat wearing malcontents lurking the Net looking for victims, you’ll have a job keeping those wannabe perpetrators at bay.

Nikto is a free, open source, command line scanning script used for testing your web server’s security. It checks for thousands of vulnerabilities and potential security weaknesses such as default files and programs, outdated servers, insecure files, server and software misconfigurations. Nikto uses a configuration file, three dozen plugins for testing and a handful of templates for reporting.

Nikto is not a weapon nor is it a remedy for damage that’s already occurred. It is an assessment tool that, when used properly, may prevent a host of potential security threats from becoming reality.

Download Nikto here.

Use nikto with the following guide.

$ ./ -h

- Nikto v2.1.1
+ Target IP:
+ Target Hostname:
+ Target Port:        80
+ Start Time:         2010-03-01 13:42:23
+ Server: Apache/2.2.3 (CentOS)
+ Number of sections in the version string differ from those in the database, the server reports: apache/2.2.3 while the database has: 2.2.14. This may cause false positives.
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-3268: /icons/: Directory indexing is enabled: /icons
+ OSVDB-3233: /icons/README: Apache default file found.
+ 3818 items checked: 5 item(s) reported on remote host
+ End Time:           2010-03-01 13:42:54 (31 seconds)
+ 1 host(s) tested

$ ./ -h -port 443,8080

+ No web server found on
+ No web server found on

I have test and running nuxeo for pkink data managemant

and i get this error..

GadgetException: Unable to retrieve gadget xml. HTTP error 504

This is the solutions

locate this file

or you will fine it here


chnage all localhost to your ip / change to / change to / change to

tips and trick for nuxeo!!

How to hidden apache full detect that will expose you server os and apache version.

use this

rania:/etc/apache2# pico apache2.conf


ServerTokens Full


ServerTokens Prod

/etc/init.d/apache2 restart

test your server using this url

web server detections