Oracle

Bu belgedeki kısıltmalar ve varsayılanlar
İS : İşletim Sistemi
VT : Veritabanı
VTY : Veritabanı Yöneticisi
VTYS : Veritabanı Yönetim Sistemi
$ : Unix komut satırı
SVRMGR> ardından gelen komutlar için öncelikle svrmgrl yazılıp enter’a basıldığı ve daha sonra da connect internal denerek vt’ye bağlanıldığı varsayılmaktadır.
Buradaki örnekler çoğunlukla Oracle 7.3.x ve 8.0.x’ler için geçerli olabilecek örneklerdir. Ama yeni sürümlerde de aynı yapının korunmuş olması olasıdır.
Oracle ve ilgili dosyaların sahibinin Unix düzeyinde oracle kullanıcısı olduğu varsayılmıştır.
1. Oracle’ın Bulunduğu İşletim Sisteminin Güvenliği
Bu belgeyi Unix ya da unix benzeri (linux gibi) bir işletim sisteminde çalıştığınızı düşünerek hazırladım. Eğer Windows gibi sorunlu sistemlerde çalışıyorsanız İşletim Sistemi (İS) güvenliği konusunda da ciddi adımlar atmanız gerekecek. İS güvenli olsa da en azından virüs bulaşarak sisteminizi çökertme riskine karşı önlem almalısınız.
Ama burada anlatılacaklar yalnızca Unix ve türevlerinde değil, tüm İS için geçerli bilgileri içereceklerinden tüm Oracle kullanıcılarına yarayacaktır.
1.1. Sisteme Erişimi Kısıtlama
Oracle’ın bulunduğu sunucuya, bilgisayara erişimi kısıtlayın.
Doğaldır ki bu her zaman olası değil. Ama İS’leri ve donanımlar kimin nereye bağlanacağını ayarlamanıza yardımcı olabiliyorlar. Eğer sizin sunucunuza belirli kişilerin ulaşmasını sağlayabilir, belirli kişilerin ulaşmasını engelleyebiliyorsanız en önemli güvenlik adımlarından birini atmış sayılırsınız.
Bu kısıtlamayı, sisteme belirli IP’lerin dışında ping bile çekemez duruma getirerek sağlayabilirsiniz.
“routing table” a bakarak sizin işletim sisteminize kimler bağlanabilir durumda görebilirsiniz:
netstat -rn
komutu ile bağlanabilir durumdaki IP’leri görebilirsiniz.
Bu sisteme bir şekilde erişebilir IP’leri göstermekte. Aynı zamanda başka ayarlamalarla
belirli IP’lerin sisteme bağlanabilmelerini (login) de kısıtlayabilir ya da engelleyebilirsiniz:
/etc altındaki hosts.allow ve hosts.deny dosyaları hangi IP’lerin neler yapabileceğini göstermektedir.
Örnek:
$ more /etc/hosts.allow
sshd2: 12.1.72.1
$ more /etc/hosts.deny
ALL: ALL
hosts.allow ve hosts.deny dosyasındaki satırlar bu sunucuya ssh ya da sftp ile 12.1.72.1 IP’si
dışında hiçbir yerden bağlanılamayacığını gösteriyor.
1.2. Sisteme Güvenli Erişimi Sağlama
Her zaman sisteme erişimi kısıtlamak yeterli olmayacaktır. Hatta bazı durumlarda sisteme erişimi kısıtlamak mümkün olmayacaktır. İşte bu tür durumlarda Sistem Yöneticilerine düşen farklı güvenlik önlemleri devreye girmektedir. Erişimlerin güvenli olmasının sağlanması gibi.
Sisteme telnet ya da ftp ile bağlanılması yerine ssh ya da sftp gibi şifreli veri alışverişi yapan programların kullanılması, İS’deki kullanıcıların basit şifreler seçmesini engelleyecek yapıların oluşturulması, İS açıklarının saptanarak gerekli yamaların yapılmasının sağlanması gerekmektedir. Aksi durumlarda oracle kullanıcısı, daha da kötüsü root kullanıcısının şifresi yaramaz çocukların eline geçtiğinde bundan sonra anlatılacak güvenlik önlemlerine hiç gerek bile kalmıyor olacaktır.
2. Oracle Veritabanı ve Verilerin Güvenliği
Eğer İS düzeyinde önlemlerinizi aldıysanız artık veritabanı ve verilerin güvenliğine bakabilirsiniz. Almadıysanız da bakın tabii 🙂
Güvenlik yalnızca sisteminize saldırılıp zarar verilmesini kapsamıyor.
2.1. Veritabanı Dosyaları Güvenliği
Tablespaceler’ın tutulduğu datafile’lar, loglar ve kontrol dosyaları gibi Oracle veritabanı için olmazsa olmaz dosyaların sağlıklı bir biçimde çalışması gerekmekte.
Bu nedenle bu dosyaların başka Unix kullanıcıları tarafından yazılamaz (silinemez) olmalarını kontrol edin.
Bu dosyalar veritabanı sahibi tarafından ve onun grubu tarafından sahiplenilmeli ve
başkaları tarafından yazılamamalıdır.
Peki bu dosyalar neler ve neredeler?
Bu dosyalar datafile’lar, loglar ve controlfile’lardır. Yerlerini öğrenmek için
sqlplus / ile ya da svrmgrl deyip connect internal diyerek veritabanına bağlanın:
$ svrmgrl
SVRMGR>connect internal
Connected.
SVRMGR>select * from v$datafile;
ya da
SVRMGR> select name from v$datafile;
NAME
——————————————————————————–
/d1/data/ORNEK/sysORNEK01.dbf
/d2/data/ORNEK/sysORNEK02.dbf
/d3/data/ORNEK/sysORNEK03.dbf
/d2/data/ORNEK/datORNEK01.dbf
/d3/data/ORNEK/datORNEK02.dbf
/d3/data/ORNEK/rbsORNEK01.dbf
6 rows selected.
Yukarıdan da anlaşılacağı üzere datafile’larımız /d1/data/ORNEK, /d2/data/ORNEK vb
yerlerde duruyor.
Aynı şekilde controlfile’ların yerini bulmak için:
SVRMGR> select * from v/$controlfile;
ve online redo logfile’ları bulmak içinse:
SVRMGR> select * from v/$logfile;
komutlarını verebiliriz.
Dosyaların yerlerini bulduktan sonra bunların kime ait olduğuna bakmamız gereklidir.
SVRMGR>exit
diyerek Server Manager’dan çıkıp komut satırına düştükten sonra
$ cd /d1/data/ORNEK diyerek bu dizine gidebiliriz (sizin dosyalarınız farklı yerlerde olacağı için ilgili dizini yazmalısınız)
$ ls -al *.dbf diyerek (controlfile ve logfile’ların uzantıları ve yerleri değişik olabilir)
-rw-r—– 1 oracle dba 1859584 Mar 17 16:34 ctlORNEK01.dbf
-rw-r—– 1 oracle dba 314580992 Mar 17 06:08 sysORNEK01.dbf
ilgili dosyaların kime ait olduğunu ve kimlere yazma yetkisi verildiğini görüyoruz.
Bu örneğimizde yalnızca oracle kullanıcısına yazma yetkisi verildiğine dikkat edin.
Eğer dba grubuna ya da tüm kullanıcılara yazma yetkisi verilmiş olsaydı şuna
benzer bir durumla karşılaşırdık.
-rw-rw-rw- 1 oracle dba 1859584 Mar 17 16:34 ctlORNEK01.dbf
-rw-rw-rw- 1 oracle dba 314580992 Mar 17 06:08 sysORNEK01.dbf
Bu ise ciddi bir güvenlik açığı oluşturmaktadır.
Sisteme bağlı farklı bir kullanıcı bilerek ya da bilmeyerek bu dosyalardan birini silebilir,
üzerine yazabilir. Bu durumda veritabanınız artık çalışmayacaktır.
Bu nedenle eğer yukarıdakine benzer bir durumla karşı karşıyaysanız vt’yi kapatın ve
dosya haklarını değiştirin:
$svrgrml
SVRMGR>connect internal
Connected.
SVRMGR>shutdown
….
SVRMGR>exit
$ chmod 600 *.dbf
2.2. Ya Veritabanı Çökerse? Yedek Almalı mıydım?
Yedek almalı mısınız? Size kalmış. Eğer verilerinizi yitirmek gibi bir kaygınız varsa, mutlaka yedek almalısınız. Ya da işinizi yitirmek gibi bir kaygınız varsa.
İS, donanımlarınız ve ağ bileşenleriniz mükemmel olsa da her zaman fiziksel ya da başka bir nedenle vt’nizin başına bir iş gelebilir. Fiziksel bir bozukluk ya da başka bir nedenle vt çökebilir, dosyalar bozulabilir.
Yaptığınız işleme uygun yedek alma ve bu yedekleri doğrulamayı sizin saptamanız gerekiyor.
Eğer vt üzerinde sürekli işlemler yapılıyor ve bunların hiçbirini yitirmek istemiyorsanız
vt’yi Archive Mode’a geçirmelisiniz. Öte yandan belirli aralıklarla da hot backup (online) ya da cold backup (offline) yedekler almanız gerekmektedir.
Offline backup, vt kapalıyken alınan yedek biçimidir. Veritabanının düzgün olarak
kapatılmış olması gereklidir; shutdown ya da shutdown immediate ile.
Daha sonra ilgili tüm dosyaların bir yedeğinin alınması gereklidir (datafile’lar, controlfile’lar, log dosyaları ve parametre dosyaları gibi). Bunu İS düzeyinde farklı bir yere alabileceğiniz gibi, tape gibi bir dış yedekleme aracına da alabilirsiniz.
Her zaman sistemi kapatarak yedek almanız mümkün olmayabilir. Bu nedenle de sistem açıkken de yedek almanız gerekebilir.
Bunun için de değişik yöntemler sözkonusu. İsterseniz vt açıkken tablespace’ler düzeyinde yedek alabilirsiniz. Bunun ayrıntılarına burada değinmeyeceğiz.
Bir de export ile de tablo ya da tüm tabloların ve ilişkili diğer yapıların bir yedeğini çıkarabilirsiniz.
$ exp help=y
komutu size başlangıç için bazı bilgiler verecektir.
Bunun için de ilgili belgelere bakmanızı, yanlış bir iş yapmamanız için önereceğim.
Bunlar yedek alma biçimlerine örneklerdi. Hepinizin bildiği gibi vt’na sürekli veriler eklenmekte, çıkarılmakta ve değişiklik yapılmaktadır. Bir çökme sırasında geri dönüş ve eksiksiz geri dönüş oldukça önem taşıyor. Bu nedenle de vt’yi Archive Mode’da çalıştırmalısınız dedik. Böylece sorun çıktığı noktaya deönüşünüz olasıdır.
Peki Archive Mode’a nasıl geçerim? Bunun için önceden yapmam gerekli işler nelerdir?
Vt’nin arşiv alarak çalıştırılması demek, bir döngü içinde üst üste yazılan online redo log dosyalarının, üzerine yazılmasına izin verilmeyecek biçimde başka bir yere yazılmasının sağlanması anlamına geliyor. Bu yüzden de online redo log’ların boyutu önem taşıyor. Öncelikle vt’nizde kaç gruptan oluşan log dosyası var buna bakalım.
2.3. Online Redo Log Dosyalarını Archive Mode İçin Hazırlama
Yedek Almalı mısınız? Size kalmış. Eğer verilerinizi yitirmek gibi bir kaygınız varsa, mutlaka yedek almalısınız. Ya da işinizi yitirmek gibi bir kaygınız varsa.
SVRMGR>select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHAN FIRST_TIME
———- ———- ———- ———- ———- — —————- ———- ——————–
1 1 3618 3145728 2 YES INACTIVE 98297105 03/19/02 16:28:30
2 1 3619 3145728 2 NO CURRENT 98322294 03/20/02 11:49:36
2 rows selected.
Yukarıda “2 rows selected” ya da group# sütunundaki en büyük sayı olan 2’den de anlaşılacağı gibi, bu vt iki grouplu bir yapı içeriyor.
Vt’de işlem yaptıkça, yapılan işlemler bu log dosyalarına yazılır ve biri dolunca sıradakine geçer. Eğer bu dosyaların boyutu küçükse, grup sayısı yukarıdaki örnekte olduğu gibi azsa ve logların değişim süreleri kısaysa; Archive Mode’daki bir vt’da log diske yazılmadan diğer log dosyasına geçemeyeceği için vt askıda (hang-up) kalır.
Online redo logların değişim sürelerini şu komutla görebilirsiniz:
SVRMGR>select * from v$loghist;
Ya da alert dosyasına bakabilirsiniz.
Alert dosyasının nerede olduğuna bakmak için:
SVRMGR> select value from v$parameter
2> where name=’background_dump_dest’;
VALUE
——————————–
/usr/oradata/ORNEK/log/bdump
1 row selected.
sonucunda çıkan dizine gidip orada alert_.log dosyasının içine bakın.
Yukarıdaki örnekte ORNEK adlı vt için /usr/oradata/ORNEK/log/bdump altındaki
alert_ORNEK.log dosyasıdır alert dosyam.
Bu aynı zamanda bir veritabanı yöneticisiniz sürekli izlemesi gereken bir dosyadır.
Burada vt üzerinde olan önemli işlerin ve hataların bilgileri yazar.
Eğer online redo logların sayısının az olduğunu düşünüyorsanız ya da sayısı az ama boyutu yetersizse ya yeni bir grup ekleyeceksiniz ya da logların boyutunu büyüteceksiniz.
Aşağıdaki örnek yeterli sayıda log’u olan bir vt için log’ların boyutunu büyültmeyi göstermektedir. Bu örnekte 3 tane log file olduğu ve boyutlarının küçük olduğu varsayıldı.
Bunun için önce bu dosyalar nerelerde ona bakıldı:
SVRMGR>select * from v$logfile;
GROUP# STATUS MEMBER
———- ——- ——————————————————————————–
1 /d1/data/ORNEK/redoORNEK01_a.log
1 /d2/data/ORNEK/redoORNEK01_b.log
2 /d1/data/ORNEK/redoORNEK02_a.log
2 /d2/data/ORNEK/redoORNEK02_b.log
3 /d1/data/ORNEK/redoORNEK03_a.log
3 /d2/data/ORNEK/redoORNEK03_b.log
6 rows selected.
Görüldüğü gibi 3 grup, her grupta iki üye ve tüm dosyalar /d1 ile /d2 altındalar.
$ svrmgrl
SVRMGR>connect internal
Connected.
SVRMGR>shutdown startup open restrict alter database add logfile group 4 (‘/d1/data/ORNEK/redoORNEK04_a.log’,
2>’/d2/data/ORNEK/redoORNEK04_b.log’) size 5M;
diyerek 1.grubun dosyalarının bulunduğu yerlerde (sırasıyla /d1/… ve /d2/… altında) 2 üyeli 4.grup log dosyalarını yeni adlar vererek oluşturdum.
Benzer işlemleri 2. ve 3. gruplar içinde yaparak 5. ve 6. grupları oluşturdum.
SVRMGR>select * from v$log;
dediğimde STATUS sütununda CURRENT olarak gördüğüm grup benim eski log dosyalarımdan biri olacaktır.
SVRMGR>alter system switch logfile;
diyerek bir sonraki gruba geçmesini sağlarım. v$log’da gördüğüm duruma göre yeterince bu komutu vererek yeni yarattığım gruplardan birinin CURRENT olmasını sağlarım.
Daha sonra ise,
SVRMGR>alter database drop logfile group 1;
ve 2. ve 3. gruplar için de aynı işlemleri yaparak artık gerek duymadığım eski log file’ları silerim.
Ancak bu İS düzeyinde bir silme değil, vt düzeyinde bir silmedir. Bu nedenle İS düzeyinde gidip eski dosyalarımı silmem gerekir.
İsterseniz şimdi vt’yi tam kullanıma açın, isterseniz shutdown ile kapatıp
bir yedek alın. Hatta ne olur olmaz diyerek bu işlemlere başlamadan önce de vt’yi kapatıp bir yedek almayı tercih edebilirsiniz.
Logları’da ayarladığımıza göre artık vt’yi Archive Mode’a geçirebiliriz.
2.4. Archive Mode’a Geçiş
Belki de veritabanınız Archive Mode’ta çalışıyordur.Bunu anlamak için
SVRMGR>select name,log_mode from v$database;
NAME LOG_MODE
——— ————
ORNEK NOARCHIVELOG
1 row selected.
ile de görüldüğü gibi vt’nizin henüzArchive Mode’da çalışmadığını görebilirsiniz. Eğer Archive Mode’da olsaydı ARCHIVELOG görecektiniz.
Veritabanınızı Archive Mode’a geçirmeden önce mutlaka kapatmalı ve uygun bir yedek almalısınız. Eğer işlemler sırasında bir sorunla kerşı karşıya kalırsanız bu sizin geri dönüşünüzü kolaylaştıracaktır.
SVRMGR>shutdown
Database Closed’u görüp
$ ps -fe|grep -i oracle
ile oracle’a ait çalışan bir iş var mı diye de kontrol edin. Eğer ora_ ile başlayan bilgiler geliyorsa ve içerisinde vt adını da taşıyorsa, vt’niz kapanmamış demektir.
Şimdi Unix düzeyinde yedeklerinizi alın.
Artık vt’yi Archive Mode’a geçirebiliriz.
İlk önce init.ora dosyasına (buradaki ornekte initORNEK.ora) bazı eklemeler yapmalıyız.
init.ora dosyası 8.x ve sonrasında ORACLE_HOME altındaki dbs dizininde bulunuyor çoğunlukla. Daha önceki sürümlerde farklı yerlerde olabilir.
oracle kullanıcısı ile
$ echo $ORACLE_HOME
dediğinizde bir değer çıkıyor olmalı. Öyleyse
$ cd $ORACLE_HOME/dbs
yazıp enter’a basarak ilgili dizine gidin ve önce bunun bir yedeğini alın:
$ cp initORNEK.ora initORNEK.ora.17032002
yazarak örneğin. Sonra da initORNEK.ora içerisine girerek en altına şu satırları yazın:
log_archive_dest=/archive
log_archive_start = true
log_archive_format=%s.arc
ve dosyayı saklayın.
İlk satır arşivlenecek dosyaların nereye yazılacağını gösterir.
2. satır otomatik arşivlemenin doğrudan yapılıp yapılmayacağını gösterir. Buna true demezseniz zaman zaman svrmgrl’ye bağlanarak log archive start diyerek, arşiv dosyalarını yazma işlemini elle kontrol etmeniz gerekir ki bunu önermiyorum. Ama tape gibi farklı bir yere zaman zaman arşivlemek için bu yöntemi kullanabilirsiniz.
3.satır ise üretilecek arşiv dosyalarının yazılma biçimini gösteriyor. %s ile Log’ların sıra numarasını (Sequence #) .arc ile de uzantısını belirlemiş oldum.
$ svrmgrl
SVRMGR> startup mount ORNEK
SVRMGR> alter database ORNEK archivelog;
SVRMGR> alter database ORNEK open;
diyerek artık vt’yi Archive Mode’a geçirmiş olduk.
SVRMGR>alter system switch log file;
ile log dosyasını 1 atlatarak arşivin yazılacağı yere yazmasını sağlayabiliriz.
Şimdi ister
SVRMGR> select name,log_mode from v$database;
ile isterseniz de
SVRMGR> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /archive/
Oldest online log sequence 1315
Next log sequence to archive 1316
Current log sequence 1316
ile vt’nin Archive Mode’ta olup olmadığını görebiliriz.
Şimdi yine vt’yi normal yöntemle (shutdown ile) kapatıp yedek almalıyız.
Bu yedek Archive Mode’a geçiş sonrası yedeği olduğu için önem taşıyor. Bunu temel alarak üretilmiş arşiv dosyalarını kullanabilir ve ileride çıkacak bir sorunda çözüm üretmiş olabiliriz. Ama yoğun kullanılan veritabanlarında çok fazla arşiv dosyası oluşacağından, bunları sırasıyla uygulayıp son hale gelmek günler sürebilir. Bunu önlemek için belirli aralıklarla vt kapalıyken yedekler (cold backup) alınmalıdır.
$ ls -al /archive diyerek oluşan dosyalara bakabilirsiniz. Yukarıdaki örnek nedeniyle oluşan dosyalar 1315.arc, 1316.arc şeklinde olacaktır.
Arşiv dosyalarının yazıldığı dizin bir süre dolabilir ve vt yeni bir arşiv dosyası yazacak yer bulamazsa askıda (hang-up) kalır. Bu nedenle arşiv dizinini zaman zaman başka bir ortama atarak ya da gerek kalmayanlarını silerek izlemelesiniz. Bu dosyaların sıkıştırılması da yer sorununuzu aza indirecektir. Aşağıdaki betik (script) arşiv dizinindeki dosyaları sıkıştırmak için yazılmış ve crontab’tan belirli aralıklarda çalıştırılan bir betikdir:
#!/usr/local/bin/bash
cd /archive
/usr/local/bin/gzip `ls|sort -rn|tail +2 |grep -v gz`
gzip ve bash’ın farklı yerlerde olabileceğini gözardı etmeyin lütfen.
$ which gzip
ile nerede olduğunu bulabilirsiniz.
3. Oracle’ı Daha Güvenli Hale Getirme
Şu ana kadar İS düzeyinde alınacak önlemlerle veri güvenliğini gördük. Bir de Oracle’ın güvenliği var. Hem gerekli yamalarla açıkların giderilmesi, hem de VTYS (Veri Tabanı Yönetim Sistemi) düzeyinde alınacak önlemlerle olası sorunların önüne geçilmesi mümkündür.
3.1. Kurulumla Gelen Kullanıcılar
Oracle VTYS kurulduğunda iki kullanıcı ve bunların şifreleri de yaratılmış olur. Bunlar system ve sys kullanıcıları ve sırasıyla manager ve change_on_install şifreleridir.
Bir veritabanı yöneticisi olarak yapmanız gereken ilk iş bu şifreleri değiştirmek olmalıdır.
Eğer VTYS’siyi siz kurmadıysanız ve kurulmuş bir vt’deki şifreleri kontrol etmek isterseniz şu yöntemi deneyebilirsiniz:
$ svrmgrl
SVRMGR>connect system/manager;
eğer “Connected.” gibi bir bilgi yazıyorsa ekrana system kullanıcısının şifresi hala manager kalmış demektir.
$ sqlplus system/manager
ile de deneyebilirsiniz aynı işlemi.
Bir de connect sys/change_on_install diyerek deneyin.
Buna da bağlıysa Connected, bağlanamazsa “invalid username/password; logon denied” gibi bir bilgi göreceksiniz.
Şimdi bu kullanıcıların şifrelerini değiştirelim.
alter user identified by ;
komutu kullanıcı_adı adlı kullanıcının şifresini verdiğiniz sifre olarak değiştirir.
Diyelim ki system kullanıcısının şifresini değiştirmek istiyorum, o zaman;
$ svrmgrl
SVRMGR>connect internal
Connected.
SVRMGR>alter user system identified by dene12;
Statement processed.
derim ve system kullanıcısının şifresi dene12 olur. Unutmayın ki vereceğiniz şifre,
burada yaptığım gibi, kolayca bulunabilecek bir şifre olmamalıdır.
Aynı işlemi sys kullanıcısı için de yapın.
Oracle’ın yeni sürümleriyle ve özellikle de Application (9iAS vb) gibi ürünleriyle de birçok varsayılan kullanıcı/şifreler geldi. Bunları da değiştirmeniz iyi olacaktır. Ancak Oracle Uygulama Yazılımı’nın bazı yerlerinde bu kullanıcı ve şifreler gömülü olarak tutulduğu için onları da değiştirmeniz gerekebilir.
Yine vt yöneticiliğine başladığınız kurumdaki programlarda bir yerlerde gömülü olarak kullanıcı/şifre varsa bunları değiştirmek sorun olabilir. Ama iyi programcıların bu şekilde yazmadıklarını varsayın ve en azından system, sys kullanıcılarının şifrelerini değiştirin. Olmazsa eski şifreleri verebilirsiniz.
3.2. Oracle Araçlarını Çalıştırırken Şifreleri Kullanma, Şifreleri Dosyadan Okutma
Oracle araçlarından sqlpus,exp,imp gibi programlar kullanıcı adı ve şifre isterler. Diyelim ki bir programı çalıştırıp daha sonra connect kullanıcı_adı diyerek şifreyi girmek yerine şunu yapıyorsunuz:
$ sqlplus system/manager
Bu durumda, sistemdeki bir başka kullanıcı ps -fe|grep oracle dediyse sizin yazdığın kullanıcı adı ve şifreyi görebilir. Ya da .sh_history ya da .bash_history’i görme yetkisi varsa, yazdığınız şifreyi görebilir ve oldukça yetkili bir kullanıcı olarak vt’ye bağlanabilir.
Bu nedenle doğrudan komut satırından, ya da bir dosyaya yazıp oradan okutarak kullanıcı adı /şifre kullanmayın. Ya da böyle birşey yaptıysanız ve bunun görüldüğünü düşünüyorsanız 3.1’de anlatıldığı gibi kullanıcı şifresini değiştirin.
3.3. Kurulumla Gelen Servislerin Çalışma Portları
Oracle veritabanı kurulduğunda, VTYS dosyaları dışında bağlanmaları sağlayan/kontrol eden listener gibi bazı servisler de kurulabiliyor. Ya da özellikle Oracle Uygulama yazılımları ile gelen Oracle Web, Oracle Forms gibi başka programlar da olabiliyor ve bunlar İS’nin kapılarını (portlarını) kullanarak çalışıyorlar.
Kurulum sırasında da bu kapılar varsayılan değerleriyle kurulduğu için dışarıdan bir kullanıcının sizin sunucunuzda ne çalışıyor, nerede çalışıyor gibi sorularına kolayca yanıt vermiş oluyorsunuz.
Kurulum sırasında ya da sonrasında sisteminizde hangi servislerin çalışması gerektiğini saptayarak, gerekli olanları kurun ve bunları, varsayılan kapıların dışında kurun. Böylece en azından, amacı doğrudan Oracle’ın bir parçasında çıkan bir açığa yönelik bir saldırı yapmak isteyen kişinin işini zorlaştırmış olursunuz. Zorlaştırmış olursunuz diyorum çünkü, saldıran işini bilen birisiyse, sizin İS’nizde neyin açlıştığını ve nereden hizmet verdiğini bulabilecek yazılımlara sahiptir. Ama en azından uğraşması gerektiği için, yaptığı işlemlerin farkına varılabilir, ya da uğraşmaktan vazgeçebilir.
Unutmayın saldırılarda birincil amaç, kolayca saldırılabilecek alanları bulmaktır.
8.1.x’lerle gelen Oracle Universal Installer aracılığı ile Oracle ve araçlarını kurduğunuzda bir aşamasında kurulacak servisleri ve bunların hangi kapılarda çalışacağını size soracaktır. Buradaki varsayılan değerleri değiştirin. Ama yeni seçtiğiniz değerin başka bir servisçe kullanılmaması gerekir. Her ne kadar, kurulum yazılımı, seçtiğiniz değerlerin olabilirliğini kontrol etse de, /etc/services altındaki
değerlerle ya da netstat -a ile kullanılır durumdaki kapıları görebilirsiniz.
Oracle için kullandığınız değerleri daha sonra /etc/services altına yazarak daha sonra kurulacak yazılımlar için ipucu verebilirsiniz.
3.4. Listener’a Şifre Koyma
Oracle’ı kurdunuz ve listener’ı da çalıştırdınız. Listener’ıza da genellikle vt’nizin adı verilmiş oluyor. Bunu da değiştirmenizi öneriyorum.
Listener’ınızı şifrelemezseniz, izinsiz bir kullanıcı başka bir Oracle VTYS’yi kullanarak, sanki kendi listener’ını kapatıyormuşçasına sizinkini kapatabilir. Bunu bir 8.0.5 veritabanında yapmıştım. Çalışan bir veritabanının listener’ının sizden habersiz kapatılmış olması ise pek hoş sonuçlar doğurmayacaktır. Bu nedenler listener’ınıza bir şifre koyun. Parolalanmış (encryted) şifre koyabileceğiniz gibi doğrudan bir metin şifre de koyabilirsiniz. Size burada ikincisini göstereceğim.
Önce listener’ınızı bulun:
$ cd $ORACLE_HOME/network/admin
diyerek listener’ınızın yapılandırma dosyası listener.ora’nın olduğu yere gidersiniz.
listener.ora’yı açtığınızda en alt satırına passwords_= satırını ekleyin.
Diyelim ki listener adı LISTENER ve şifreniz denemesifre olsun. Bu durumda
passwords_LISTENER=denemesifre
satırını eklemelisiniz.
Bunu ekledikten sonra listener.ora dosyasının haklarının dosya sahibine read-write olmasına dikkat edin.
$ chmod 600 listener.ora
komutu bunu sağlayacaktır:
$ ls -al listener.ora
-rw——- 1 oracle dba 1919 May 30 1999 listener.ora
Bunu başka kişiler metin olarak yazdığımız şifreyi görmesinler diye yaptık.
Listener’ı lsnrctl aracını kullanarak açıp kapatıyorsanız, şunları yapmalısınız:
$ lsnrctl
Welcome to LSNRCTL, type “help” for information.
LSNRCTL> set current_listener LISTENER
Current Listener is LISTENER
LSNRCTL>set password denemesifre
The command completed successfully
LSNRCTL>stop
diyerek kapatabilir ya da aynı işlemleri uygulayarak ama stop yerine start diyerek başlatabilirsiniz.
Listener’a verilen metin şifre listener’ın loguna da yazılıyor ne yazık ki. Bu nedenle listener.log dosyasını da bularak chmod 600 listener.log diyerek yalnızca kendiniz okur-yazar duruma getirmelisiniz.
listener.log dosyası
$ lsnrctl status
komutunu verdiğinizde gördüğünüz Listener Log File değişkeninin olduğu dizindedir.
Eğer bir betik aracılığı ile vt’yi ve listener’ı açıp kapatıyorsanız, lsnrctl’ye yukarıda verilen komutları sırasıyla verdirmelisiniz. Bunun için listener.ora’nın olduğu dizine bir dosya yaratın (yalnız sizin okuyup yazacağınız olsun yine).
Diyelim ki yap.txt adında bir dosya olsun bu ve içine şu 3 satırı ekleyin:
set current_listener LISTENER
set password denemesifre
stop
Artık yazacağınız scripte listener’ı kapatmak için şu komutu verebilirsiniz.
lsnrctl belgesi-261