Belum lama ini saya habis mendeploy sebuah situs intranet sederhana yang berbasis drupal CMS. Situsnya sederhana aja, ada download file, shoutbox, comment dan beberapa fasilitas lainnya yang standar web jaman sekarang. Masalahnya saya ingin menambahkan RSS Aggregator untuk menampilkan berita terbaru dari detik.com dan okezone.com di situs tersebut seperti halnya pada blog ini.

Jawabannya gampang aja, langsung masuk menu pengaturan RSS, copy-paste alamat RSS dari kedua situs tersebut lalu aktifkan. Kan uda pernah buat di wordpress ini..lalu dimana masalahnya? Saya baru tau kemudian siang harinya... Ternyata isi RSSnya ga pernah diupdate, padahal udah diset otomatis 1 jam sekali update RSS. Ternyata plugin drupal yang saya pake blm bisa mengupdate RSS secara otomatis (ga tau kalo yang laen pada bisa, kn saya newbie bgt di drupal), akibatnya isi berita detik.com dan okezone.com di situs saya tidak up-to-date.

Oke deh, nyari-nyari mekanisme update di drupal, ternyata dilakukan dengan mengakses kode php di alamat http://localhost/drupal/cron.php. Berarti ada di root direktori drupal yang diinstall. Setiap saya membuka page ini secara manual di browser, dan kebetulan pada saat itu sudah ada berita baru di detik.com, langsung RSS Aggregatornya terupdate. Berarti satu jam sekali harus buka alamat ini donk... Dari alamat cron.php saya jadi teringat si cron yg baru dibahas di blog ini. Kita bisa minta tolong ga sama cron untuk bukain page ini setiap jam, daripada saya yang capek buka-bukaan ?

Ga masalah, cron emang diciptakan untuk penjadwalan. Masalahnya sekarang yang mo dijadwalin apa? Kan servernya non GUI, text based. Mana ada firefox didalamnya, untuk buka halaman web. Untung inget sama paket dasarnya CentOS, yang ada text-based web browser. Jadi di linux itu ada program yang namanya Lynx, yang bisa digunakan untuk mengakses web dari terminal. Gunanya untuk mengecek kompabilitas situs dengan browser lama, maupun untuk mengakses situs pada komputer yg 'amat-sangat-lemot' atau bandwidthnya yang 'amat-sangat-lemot' sampe ga kuat buat nampilin gambar. Dari definisinya yg text-based aja uda bisa ketauan klo browser ini ga bisa nampilin gambar. Tapi ga masalah, orang butuhnya cuma panggil halaman cron.php yang itupun ga ada isinya. Cuma mengaktifkan fungsi update RSS.

Langsung aja daftarkan si Lynx di crontab, kayak gini nih:

0 * * * * lynx -dump http://localhost/drupal/cron.php

Artinya adalah menjalankan program lynx setiap jam untuk membuka halaman http://localhost/drupal/cron.php. parameter dump dari lynx digunakan untuk mengabaikan hasil teks yang dikembalikan server saat diminta untuk mengakses cron.php. Toh kita hanya perlu memastikan bahwa fungsi update RSS sudah berjalan, tanpa perlu tau hasil updatenya seperti apa. Mengenai arti 0 * * * * adalah yang menetukan bahwa proses eksekusi dijadwalkan setiap jam. Untuk parameter yang dikenali oleh cron dapat dibaca di posting sebelumnya tentang cron.

Сервис Cron
Иногда требуется через регулярные интервалы времени выполнять какие-то действия, к примеру удаление временных данных или обновление значений счетчиков. Этот сервис является простой надстройкой над утилитой wget, которая обращается по заданному URL в определенное время.

• Черновая документация по сервису Cron
  

Сервис Comet
А это, как говорится, мой любимый. Представьте, что необходимо создать приложение-чат на Google App Engine. Самый простейший способ, который вспомнят ветераны веб-строения - использование долгоиграющих HTTP запросов и потоковая выдача данных от сервера, который будет сообщать об новых событиях. Однако на платформе App Engine такой вариант неприменим по ряду архитектурных ограничений. Имеются другие варианты оперативного взаимодействия с сервером, один из которых можно взять на вооружение - использование на клиентской части
XMLHttpRequest запросов. В английском языке существует даже неологизм, связанный с набором таких технологий - Comet.

Теперь давайте подсчитаем: Google выделяет квоту 650 тысяч HTTP запросов в день. Допустим, что мы будем опрашивать сервер каждую секунду.

650k запросов в день / 86k секунд в день = 7 пользователей могут быть в чате целый день

Согласитесь, что 7 пользователей для масштабируемого приложения не являются достойным показателем. Описываемый сервис Comet позволяет преодолеть эти ограничения и не иметь проблем с дополнительным сервером.

Главным ограничением его использования является то, что вы должны иметь собственный домен для работы приложения. К сожалению, сервис не поддерживает работу сайтов в зоне *.appspot.com.

• Пример чата (опубликован на GAE)
• Простой пример интерактивного подсчета посетителей
  
• Черновая документация по сервису Comet
  

Итог
Ну и конечно все примеры можно загрузить в исходных кодах.

The perl script run well when it is directly accessed in terminal using current user. But when I tried to execute it from crontab, it fails.

Firstly I thought it failed because the file access error (my script tried to write to a file), but after some investigation it was caused by the missing module. I wonder why..... The DBI module cannot be found in one of the path specified in @INC variables.

Here are my investigation.
1. I tried to access the perl script from a bash script (/bin/sh). It still failed.
Here is the bash script.
#updateDB.sh
#!/bin/sh
cd /home/me/
./updateDB.pl

2. I need to know what is the crontab log.
The crontab log must have the necessary information about the failure. But I found the crontab does not have the log. I must create log for each cron jobs. So I call the cron job this way
0 * * * * /home/me/updateDB.sh >> /home/me/cronlog/log.txt > /dev/null > 2>&1
/home/me/cronlog/log.txt is the log file.
I found out that some modules I used in the perl script cannot be found when the perl script is scheduled as cron jobs. I wonder why...
Note: the /dev/null > 2>&1 is used to avoid the cron to send email after executing the cron job

3. So why cron cannot find the module, while in normal execution (through terminal), it run well?
I want to know the @INC in cron execution environment and compared it to normal execution.
I add 1 cron job to print the perl @INC.
0 * * * * perl -e "print join(\"\n\", @INC);" >> /home/me/cronlog/log.txt > /dev/null > 2>&1
It shows the @INC is different compared to the normal execution. Then I found that the shell environment variables must be loaded prior to perl execution in cron job schedule.
I finally modified the updateDB.sh like this:

#!/bin/csh
cd /home/me/
source ./.cshrc
perl /home/me/updateDB.pl

I run the cshell script in the cron schedule, and my perl script works fine.

My system happens to use cshell as it's shell environment. In that case, we use .cshrc instead of .bashrc.

I wanted my newly installed Ubuntu server to check for updates every day and then automatically update itself if there were any new updates found. I search the web trying to find an existing solution that would work out of the box for me. But I am of course very picky of what I want, so I could not found anything that met all my needs:

• Automatically check for updates every day.
• Automatically download and install any updates that were found.
• Report both success and failures to my e-mail and show me in the subject if the update failed or succeeded.
• Use an external smtp-server with authentication.

As I am also trying to learn the Ruby programming language, besides from Linux, I decided to use it to create my update script.

Installing Ruby

Ruby is not installed by default on Hardy Heron but can easily be installed from the Ubuntu repositories:

sudo apt-get install ruby

The Script

#!/usr/bin/ruby
##### Information ##############################################
# DESC:	This is an update script for Ubuntu Hardy Heron 8.04.
#	It will fetch any availible updates with aptitude and
#	install them. An e-mail with the result is then sent
#	using the configured smtp-server.
# AUTH:	Niklas "Lani" Lagergren
# REV.:	1.0 2008-08-06
#	* Initial release.
#
# COPY: No copyright claimed. No rights reserved. No warranty
#       given.
################################################################

##### Configurable mail server options: ########################
# These parameters needs to be changed to match your enviorment
################################################################
@mail_server = 'your.mail-server.com'
@mail_port   = 25
@mail_domain = 'your.mail-domain.com'
@mail_user   = 'username'
@mail_pass   = 'password'
@mail_from   = 'from@your.mail-domain.com'
@mail_to     = 'to@somewhere.nil'

require 'net/smtp'

# Format date according to rfc 2822, example:
# Fri, 11 Jul 2008 09:13:20 +0200
def time_to_rfc2822(time)
  time.strftime('%a, %d %b %Y %H:%M:%S ') +
    if time.utc?
      '-0000'
    else
      off = time.utc_offset
    sign = off < 0 ? '-' : '+'
    format('%s%02d%02d', sign, *(off.abs / 60).divmod(60))
  end
end

# Send e-mail according to the configuration in the instance variables.
def send_mail(subject, body)
  msg = "From: Ubuntu Server <#{@mail_from}>\r\n" +
    "To: Server Administrator <#{@mail_to}>\r\n" +
    "Subject: #{subject}\r\n" +
    "Date: #{time_to_rfc2822(Time.new)}\r\n" +
    "Message-Id: <#{Time.new}@#{@mail_domain}>\r\n" +
    "\r\n#{body}\r\n"

    Net::SMTP.start(@mail_server, @mail_port, @mail_domain, @mail_user,
      @mail_pass) do |smtp|
      smtp.send_message msg, @mail_from, @mail_to
    end
end

# Run aptitude commands to update the system and capture it's output.
puts 'Running aptitude...'
body = `aptitude update 2>&1`
body << `aptitude dist-upgrade -y 2>&1` if $? == 0
body << `aptitude clean 2>&1` if $? == 0

subject = "#{@mail_domain} update #{$? == 0 ? 'succeded' : 'FAILED'} #{Time.new}"

puts 'Sending mail...'
send_mail subject, body
puts 'Mail sent.'

Set the script to run every day
Obviously you need to change the mail settings in the script as the comment suggest. Then save the script, I named it "autoupdate". To run the script on a daily basis copy it to "/etc/cron.daily". And don't forget to set execute permissions on the script (and as I have the password stored in the file I also removed all permissions from "others":

sudo chmod 770 autoupdate


Test the script
The easiest way to test the script is of course to just execute it:
sudo ./autoupdate

If you really want to make sure that it will execute when executed in the same way as when execute by the cron job you could run:

sudo run-parts /etc/cron.daily

Note that this will execute all scripts in the cron.daily folder. Another side note is that it probably won't run with the same permissions as when executed from the cron job, and it will probably take a long time to execute.

Now check your mailbox or the log files for the result:

cat /var/log/aptitude

Hopefully someone out there can benefit from this script as it is, or if you're like me; tweak it to suite your own needs ;)

There’s one issue that needs to be watched - Zap2it.com (the website that provides the schedule data) sometimes changes its layout which in turn breaks zap2xml script. If you end up with issues on your TV schedule, pay a visit to zap2xml website to see if a script update is available

I built a script that automatically downloads the schedule and run mythfilldatabase to update the listing. I failed trying to add the script to a cron job (the script will start but will never finish for some reason) (I strongly suggest you make a separate folder for zap2xml and this script, in this exemple it’ll be called /zap2xml

#!/bin/bash
#updatelisting.sh
cd /zap2xml
rm ./xmltv.xml
rm -rf ./cache/
./zap2xml.pl -u username -p password -d 14 -e
mythfilldatabase –refresh-all –file 1 xmltv.xml

I happened to understand that for some reason this script was generating to much output for cron. I just modified it to make it a silent script. There's been two other modifications, one is to run zap2xml and mythfilldatabase with a nice value of 15 (ok, it takes forever to run but since it's in the background and helps not to get glitches during my recordings... those of you with good hardware can remove that part) and it now downloads four days of data 10 days from now to release some of the workload on the machine since I'll be running it everyday from now on.

#!/bin/bash
#quietupdate.sh
cd /home/dom/bin/xmltv
rm ./xmltv.xml
rm -rf ./cache/
nice -n +15 ./zap2xml.pl -d 4 -s 10 -q -u username -p password -e
nice -n +15 mythfilldatabase --refresh-all --file 1 xmltv.xml >> /dev/null

Now all that's left is to add it to your crontab by running

crontab -e

and type in

# m h  dom mon dow   command
0 0 * * * /path/to/your/quietupdate.sh

Now save and exit the text editor and you should be on your way. By the way, it is mandatory to run the first script at least once in order for the second one to run properly (just once, not everytime)

/usr/bin/cron-config : 자동으로 Windows Service에 등록해주는 명령이다.
/usr/bin/cygrunsrv : Windows Service 관련 된 Cygwin 명령이다.
/usr/bin/cronevents : Cron 관련 event log 보는 프로그램이다.

[그림 1] cron-config 실행 화면

빨간 네모는 이미 설치가 되있으면 나오는 메시지이다.

[그림 2] cronevents 실행 화면

[참고] cron 실행계정 만들어 보안 높이기
(여기서는 cron_server 로 하겠음)

1. cron_server 계정 만들기
   $ net user cron_server <passwd> /add /yes
$ net localgroup <administrators group name> cron_server /add
   <passwd> : cron_server 계정에 쓸 비밀번호.
   <administrators group name> : 보통 Administrators 임.
2. cron_server 계정 권한 설정
   $ editrights -a SeAssignPrimaryTokenPrivilege -u cron_server
$ editrights -a SeCreateTokenPrivilege -u cron_server
$ editrights -a SeIncreaseQuotaPrivilege -u cron_server
$ editrights -a SeServiceLogonRight -u cron_server
$ mkpasswd -l -u cron_server >> /etc/passwd
3. 보안 높이기
   cron_server계정은 로그인 못하도록 설정
   $ editrights -a SeDenyInteractiveLogonRight -u cron_server
$ editrights -a SeDenyNetworkLogonRight -u cron_server
$ editrights -a SeDenyRemoteInteractiveLogonRight -u cron_server
4. 윈도즈 서비스에 등록
   $ cygrunsrv -I cron -p /usr/sbin/cron -a -D -u cron_server -w <passwd>
   만약, cron 이 이미 등록돼 있으면 다음 명령으로 기존 cron 서비스를 지우고 서비스를 등록함.
   $ cygrunsrv -E cron
$ cygrunsrv -R cron

참고사이트 :
http://www.mail-archive.com/cygwin@cygwin.com/msg31538.html

自動バックアップ運用(tar+GnuPG+rsync/ftp) - CentOSで自宅サーバー構築
http://centossrv.com/backup.shtml

バックアップ対象にしたデータは以下の通りです。

• Wordpress関係のファイルすべて
• httpd.conf
• MySQLのデータベースをダンプしたもの

データベースのダンプも自動です。これらをFTP経由でWindowsのサーバーにコピります。

システムのバックアップは本番運用前にGhost取っときます。

バックアップしたならリストアもせねばということで、VM上で復旧テストしました。FQDNをあちこちで使ってるので、本番サーバーにリダイレクトされてしまって復旧したかどうか分かりにくかったんですが、VM環境でネットワーク閉じてVM上のクライアントにhosts書いてテストして確認しました。

今回は丸パクリで出来ましたが、自分でスクリプト書いてcronに登録とかって自分でするのは中々遠き道のりになりそうです。

cd /etc/cron.daily

sudo mv slocate ../cron.monthly/

Това е :)

I mentioned that you'd need to write a script to prevent this problem from happening to you. The script would delete old, unneeded mySQL bin-log files. In the spirit of stopping this bug from affecting others, I've released a generic version of the script... you just have to set up a few variables in the "configuration" section at the top of the script and you should be good to go. For the code and info on how to make it run daily, see the "update" section of the post on my blog. It is, of course, free and open source.

Hope that helps someone!

Siendo capaz de detectar los siguientes RootKits:
Solaris rootkit, FreeBSD rootkit, lrk3, lrk4, lrk5, lrk6, t0rn (and t0rn v8), some lrk variants, Ambient's Rootkit for Linux (ARK), Ramen Worm, rh[67]-shaper, RSHA, Romanian rootkit, RK17, Lion Worm, Adore Worm, LPD Worm, kenny-rk, Adore LKM, ShitC Worm, Omega Worm, Wormkit Worm, dsc-rootkit.

Una vez compilados los programas (chkwtmp, chklastlog, chkproc, chkwtmp, ifpromisc) que utiliza el chkrootkit para realizar parte de sus trabajo (chkrootkit en sí mismo es un shell script), la utilización del mismo es bastante trivial.

# ./chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not infected
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `date'... not infected
Checking `du'... not infected
Checking `dirname'... not infected
Checking `echo'... not infected
Checking `egrep'... not infected
Checking `env'... not infected
Checking `find'... not infected
Checking `fingerd'... not found
Checking `gpm'... not infected
Checking `grep'... not infected
Checking `hdparm'... not infected
Checking `su'... not infected
Checking `ifconfig'... not infected
Checking `inetd'... 

....

Solo puede darse un problema (de muy facil solución como vamos a ver), y que consiste en que chkrootkit, al ser un shell script, se basa en las siguientes herramientas:
awk, cut, echo, egrep, find, head, id, ls, netstat, ps, strings, sed, uname.
que puede contener algun troyano, la solución nos la da el propio programa, por medio de un simple parametro, le indicaremos donde debe de buscar y ejecutar esos programas que necesita:
Si los tenemos un CD-ROM:

./chkrootkit -p /cdrom/bin

En caso de tener los binarios originales de la distribución en un diskette:

./chkrootkit -p /floppy

En el caso que solo nos interese verificar algun determinado fichero lo indicaremos directamente, en este caso "ps", "login" y "sendmail".

# ./chkrootkit ps login sendmail
ROOTDIR is /'
Checking 's'... not infected
Checking 'login'... not infected
Checking 'sendmail'... not infected

Aqui tenemos todas las opciones disponibles en este interesante programa:

# ./chkrootkit --help
Usage: ./chkrootkit [options] [test ...]
Options:
        -h                show this help and exit
        -V                show version information and exit
        -l                show available tests and exit
        -d                debug
        -q                quiet mode
        -x                expert mode
        -r dir            use dir as the root directory
        -p dir1:dir2:dirN path for the external commands used by chkrootkit

Para verificar la alteración de los logs, usaremos los programas chkwtmp y chklastlog:

# ./chkwtmp

# ./chklastlog

Pudiendo testear incluso si la interfaz esta en modo promiscuo, lo que indicaria que tenemos algun sniffer funcionando:

./ifpromisc
ppp0 is not promisc

Links y Referencias:

• How to tell if your Linux box has been cracked: http://www.linuxworld.com/site-stories/2001/1012.cracked.html
• Unix Incident Guide: How to Detect an Intrusion. http://www.ciac.org/ciac/documents/CIAC-2305_UNIX_Incident_Guide_How_to_Detect_an_Intrusion.pdf
• Detección de Intrusos 1.0 (por J.J.F Team): http://www.aebius.com/b_datos_doc/archivos/deteccion_intrusos.htm
• CERT's Detecting Signs of Intrusion: http://www.cert.org/security-improvement/modules/m09.html
• CERT's http://www.cert.org/tech_tips/unix_configuration_guidelines.html
• CERT's http://www.cert.org/tech_tips/intruder_detection_checklist.html
• CERT's http://www.cert.org/tech_tips/root_compromise.html
• FAQ: Network Intrusion Detection System. http://www.robertgraham.com/pubs/network-intrusion-detection.html
• Help when broken into: http://www.fish.com/tct/help-when-broken-into
• Computer Forensics Analysis Class Handouts: http://www.fish.com/forensics/class.html
• Intrusion Detection FAQ: http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm
• chkrootkit (locally checks for signs of a rootkit): http://www.chkrootkit.org/
• RID (remote intrusion detector): http://www.theorygroup.com/Software/RID/
• Know Your Enemy: A Forensic Analysis. http://project.honeynet.org/papers/forensics/
• The DoS Project's "trinoo" distributed denial of service attack tool: http://staff.washington.edu/dittrich/misc/trinoo.analysis
• Know Your Enemy: Passive Fingerprinting. http://project.honeynet.org/papers/finger/
• "Root Kits" and hiding files/directories/processes after a break it: http://staff.washington.edu/dittrich/misc/faqs/rootkits.faq
• Charla "Network Intrusion Detection Systems. Snort based NIDS": http://umeet.uninet.edu/conferencias/05-12-2000/0512.html
• Preparing to Detect Signs of Intrusion: http://www.arcert.gov.ar/webs/textos/intrusion.pdf
• Intrusion Detection Methodologies: http://www.arcert.gov.ar/webs/textos/idmethods.pdf

Linux es un sistema que potencialmente es muy seguro, pero necesita estar bien administrado, porque de otra forma puede ser la causa de númerosos problemas relacionados con la seguridad.

Lo peor que puede pasar es que hayan entrado en tu máquina y que ni te enteres, intentaré desmenuzar algunos consejos a seguir, para averiguar si nuestra máquina sigue siendo segura o no, al mismo tiempo que proporciono interesantes enlaces a documentación relacionada con este tema.

Recomendaciones de Seguridad:

1. Utilizar buenas contraseñas, para evitar los ataques a contraseña.
2. Utilizar encriptación en las comunicaciones: ssh, pgp, SSL, Ipsec ...
3. Habilitar únicamente los servicios necesarios.
4. Detectar puntos vulnerables del sistema: scanners.
5. Registro de sistema: logs.
6. Integridad del sistema: Tripwire, md5sum ...
7. Actualización del sistema debido a problemas de seguridad.
8. Utilización de Firewall.
9. Sistemas de detección de Instrusos (IDS): snort, LIDS, ...
10. Utilización de un sistema de archivos encriptado.

Aún siguiendo todas estas recomendaciones, no podremos estar seguros al 100% de que nuestro sistema no ha sido crackeado, y que cuando ejecutamos, por ejemplo, ps -aux, no estemos realmente ejecutando un troyano que recoge información sensible de nuestro sistema.
Lo que tendremos que hacer es descubrir indicios de la presencia de los crackers en nuestra máquina:

Verificar tamaños de archivos: ps suele medir 80 Kb, aunque podemos encontrar troyanos del comando ps de apenas 10Kb:

$ type ps
ps is /bin/ps
$ l /bin/ps
-r-xr-xr-x    1 root     root        83096 Dec  5 23:11 /bin/ps

Una precaución adicional, es tener el almacenado el resultado del comando md5sum de los archivos más importantes/vulnerables, de forma que podemos comprobar si estos han sido fraudulentamente modificados, esto se debería de hacer, después de terminar la primera instalación del sistema.

$ md5sum /bin/ps
3fb65605d59a7c89206926c1a600d220  /bin/ps

Precisamente esta es la función principal del programa Tripwire (http://www.tripwire.org/), asegurar la integridad de los archivos, de una forma más flexible y potente que lo que tendríamos que montar a través de scripts y md5sum. Tripwire se distribuye con licencia GPL desde hace algun tiempo, siendo anteriormente comercial, este es el motivo por el que encontrareís varios proyectos, que se autodenominan una alternativa al comercial tripwire. como aide ( http://www.cs.tut.fi/~rammer/aide.html)

Otro truco habitual de los script kiddie es enlazar el comando history de la shell, para que apunte a /dev/null, de forma que no registre en el historico los comandos ejecutados:

$ l /home/carlos/.bash_history
-rw-------    1 carlos   users        9434 Dec  8 19:44 .bash_history

Tendriamos que preocuparnos, si no topamos con algo como:

$ l /home/carlos/.bash_history
lrwxrwxrwx    1 carlos   users           9 Dec  8 19:44 .bash_history ->
/dev/null

Suelen usar otro tipo de shells mucho mas simplistas, que no registren los comandos ejecutados, de forma que se evitan el preocuparse de borrarlos. Por eso siempre es recomendable tener instalado únicamente lo que realmente se utiliza.

También suelen manipular los registros del sistema, quitando sus entradas, para que no quede constancia de sus actos en sitios/programas como utmp, wtmp, lastlog, /var/log/messages ...
Más información en Anonymizing UNIX Systems : http://www.pimmel.com/articles/anonymous-unix.html.
Para evitarlo:

• Mandar la parte más sensible del registro a un impresora, de forma que al cracker le seria imposible borrar estas entradas. Aunque si se da cuenta del truco, puede colapsar la impresora mandandole imprimir basura.
• Utilizar otra máquina como registro, necesitará crackear esta otro máquina para eliminar todas sus huellas.
• Mandar los logs por correo electrónico.
• Cualquier otra posibilidad que se os ocurra. Existen varios sistemas de registro de log, mucho más potentes y seguros que el syslog típico de Linux, como por ejemplo Modular Syslog de la empresa Core ( http://sourceforge.net/projects/msyslog/), con licencia BSD.

Podemos usar varios programas que detectan el borrado de estos log, algunos de los más populares son el Antizap y el Antizap2 (alguien sabe donde encontrarlos). (También podemos usar el chkrootkit, tal y como veremos más adelante)

Es interesante examinar si aparecen misteriosamente cuentas de usuarios desconidas en el sistema, para lo cual examinaremos el fichero /etc/passwd: Sólo debería aparecer el usuario root, con todos los privilegios.

$ grep :x:0: /etc/passwd
root:x:0:0:root:/root:/bin/bash

Aqui tenemos la lista de todos los usuarios del sistema, si aparece alguno extraño, podemos empezar a sospechar:

$ cat /etc/passwd | awk -F':' '{print $1}'

Buscaremos en el sistema ficheros ocultos o raros, que puede ser usados para ocultar troyanos, directorios, comandos, etc...
Muchos piratas suelen crear directorios ocultos utilizando nombres como '...' (punto-punto-punto), '..' (punto-punto), '..^g' (punto-punto control+G), '\ ' (espacio en blanco), '.\ ' (punto-espacio en blanco). En algunos casos un pirata ha utilizado nombres como '.x' o '.hacker' o incluso '.mail' .

Normalmente el script kiddie, habrá conseguido acceso como un usuario normal y explotando algún error/bug consigue privilegios de root, los comandos/programas setuidados son los principales objetivos de los crackers, por lo que no es mala idea tenerlos controlados.

find / -perm +4000 -print
o
find / -user root -perm -4000 -print

Revisar la configuración de programas como cron y at, de forma que el posible pirata, no haya añadido ninguna entrada que le permita volver a entrar en el sistema posteriormente. Es interesante el averiguar realmente como ha entrado el cracker en el sistema, porque es la única forma de evitar que pueda volver a entrar de la misma forma.

Examinar el fichero /etc/inetd.conf en busca de cambios o entradas extrañas, en especial la ejecuten un shell (por ejemplo: /bin/sh o /bin/csh)

Revisar cuidadosamente ficheros relacionados con el acceso o ejecución remota de comandos, tales como, /etc/hosts.equiv, /etc/hosts.lpd y todos los .rhost del sistema.

Examinar detalladamente los ficheros de logs, analizado especialmente los logs de ftp, samba, servidor http, telnet, messages ... Nos fijaremos en entradas desde lugares extraños, verificaremos la fecha de los ficheros (es muy importante tener correctamente configurada la hora y fecha en todos los servidores).

Autor: Carlos Cortes Cortes

crond este daemonul care ruleaza in fundal in sistemele UNIX si asemanatoare, si verifica in continuu lista de procese care trebuie rulate la o anumita data/ora. Principalul fisier de configurare este /etc/crontab in care sunt specificate programele care trebuie executate la o anumita ora, intr-o anumita data. De exemplu, daca deschideti /etc/crontab cu un editor de texte simplu veti gasi probabil mai multe linii printre care si cateva asemanatoare cu cele de mai jos:
Click pentru a citi articolul complet-Rularea programata a aplicatiilor cu cron

we can change this by executing the following  command:

i.e. sudo update-alternatives –config editor

After executing  this command we can see like this

There are 4 alternatives which provide `editor'.

Selection    Alternative
-----------------------------------------------
1    /usr/bin/vim.tiny
2    /bin/ed
*+        3    /bin/nano
4    /usr/bin/vim.basic

Press enter to keep the default[*], or type selection number: 1

Now we can select the editor by just typing the corresponding number.

But maybe you don't know that MAILTO is interpreted sequencially, when it's found, so you can have different recipients in the same crontab, like in this example:


MAILTO="user1@domain.tld"
* * * * * echo "abc"
MAILTO="user2@domain.tld"
* * * * * echo "dfe"

so user1 will get mailed with "abc" and user2 with "dfe".
It works in the standard "cron" program, so for example you can use this tip in Debian or FreeBSD (and in other Unices to, I guess)

Let's add /etc/periodic/hourly as the example:

#> mkdir /etc/periodic/hourly
#> # creating the crontab entry to run scripts at 25 minutes every hour
#> echo "25	*	*	*	*	root	periodic hourly" >> /etc/crontab

into /etc/periodic.conf:

hourly_output="root"				# user or /file
weekly_show_success="NO"			# scripts returning 0
weekly_show_info="YES"				# scripts returning 1
weekly_show_badconfig="NO"			# scripts returning 2

That's all. We are done! Now you can place executable scripts into /etc/periodic/hourly and they will run every hour under root account.

Algunas referencias que podemos seguir para aprender a manejarlo son:

• http://www.linuxtotal.com.mx/index.php?cont=info_admon_006
• http://www.gentoo.org/doc/es/cron-guide.xml
• http://www.estrellateyarde.es/equiv/cron
• http://es.wikipedia.org/wiki/Cron_(unix)

No obstantes, si no nos gusta la consola, podemos utilizar alguno de los entorno gráficos que tenemos disponibles, entre ellos, los más actualizados son:

• http://gnome-schedule.sourceforge.net/
• http://docs.kde.org/kde3/en/kdeadmin/kcron/index.html

One of the things I was wondering about, and had never really done in linux, was backing up my files. Working as a Programmer and Web Developer, I have issues arising all of the time with bits of code that have gone missing as a result of accidents. I decided I needed a better backup system, and what better way than to make one which simply backs everything up without your input!

I decided that I would back my sourcecode files "/home/ajc/src" and my documents "/home/ajc/doc" every week. That way a loss could not be too catastrophic.

The tool which I chose to use was rsync. Many modern distributions come with this built in (I use ubuntu) and if they don't this will certainly be in the repositories.

First things first. Set up the destination folder for your files:

#mkdir /media/vince/data_Backup in my case.

Once that is done you are ready to learn rsync.

The command which I use for my backups is as follows (it has a few extra options which I will explain)

#sudo rsync -av --progress --delete --log-file=/home/ajc/doc/$(date +%Y%m%d)_rsync.log /home/ajc/src /media/vince/data_Backup

As you can see this line of code deals with my source folder. The options are: "-a" for archive "v" means verbose so you will see detailed output "--progress" gives a progress update in terminal "--delete" will delete any items in the destination which you have removed from the source "--log-file" specifies the location for a log file to be kept. Other than that for those of you unfamiliar with bash script "$(date +%Y%m%d)" is used to inject the current date. So the filename for today would be 20080515_rsync.log

Go ahead and change the source file and destination file (last two sections of the command) and run it on your system. You will see that for a reasonable amount of data this is a quick process!

Now you know the command thats all well and good, it means that you can backup things when you want. However, we all know that this is easy to forget! So how about scheduling this task through a cron job?

You must begin by converting this command into a bash script. This is easier than it may sound. Just create the following (with your paths) in a text editor and save it to your home directory.


#! /bin/bash
sudo rsync -av --progress --delete --log-file=/home/ajc/doc/$(date +%Y%m%d)_rsync.log /home/ajc/src /media/vince/data_Backup


Next we must make the file executable

#sudo chmod +x /home/ajc/rsync-demo.sh

And then you have a file which you can click to run. However, we want automation, so here comes the cron bit

move the file to the root directory. (So that cron doesn't ask you for a password when it runs)

#sudo mv /home/ajc/rsync-demo.sh /root/rsync-demo.sh

Then we want to open the crontab so we can schedule a job

#sudo crontab -e

here you should have several headings: m (minute of the hour) h (hour) dom (date of month) mon (month) dow (day of week) command. Now as you can see from this we have quite a wide range of choice as to when this script will be run. I chose 10pm every friday as the one I wanted. So the sequence was:

0 22 * * 5 /root/rsync-demo.sh

So 0 minutes, 22 hours, any date of the month, any month of the year, day 5 (friday) and the path to my script.

Simple. Now crontab will have opened in your default text editor so issue the command to save and exit (mines nano so Ctl + O then Ctl + X) and you will see a line confirming that the job has been added.

Done. Next time I will show you how to automate a backup to dvd!