Panel güvenliği
bipanel panel girişlerini iki aşamalı doğrulama (TOTP), süreli oturumlar, IP bazlı kaba kuvvet engeli ve CSRF korumasıyla korur. Tehlikeli sunucu işlemleri parolanın yeniden girilmesini ister, önemli işlemler işlem geçmişine yazılır; ekip rolleri, sınırlı yönetici rolleri ve harici kimlik doğrulama ile erişimi daraltabilirsiniz.
Bu sayfada
#Panel adresleri ve TLS
Sunucu (native) kurulumunda panel iki TLS portunda çalışır; düz HTTP portları yalnızca HTTPS'e yönlendirir.
| Port | Ne sunar |
|---|---|
| 2083 | Kullanıcı paneli (HTTPS) |
| 2087 | Sunucu Yönetimi, /admin (HTTPS) |
| 2082, 2086 | 2083 ve 2087'ye yönlendirme |
| 127.0.0.1:2080 | Yalnızca sunucunun içinden erişilen dahili port |
Sunucu adı için Let's Encrypt sertifikası alınana kadar panel kendinden imzalı bir sertifika kullanır. Sunucu Yönetimi → SSL ve AutoSSL ekranından sunucu adı sertifikasını aldığınızda yeni sertifika paneli yeniden başlatmadan dinleyicilere yüklenir. Tarayıcı uyarısını geçmeyi alışkanlık hâline getirmeyin; ayrıntılar için SSL sertifikaları.
Docker ve Railway kurulumlarında panel konteyner içinde yalnızca 127.0.0.1 üzerinde, konteynerin web sunucusunun arkasında dinler; TLS dış katmanda (Railway'in kenar sunucusu veya Docker kurulumundaki ters vekil) sonlanır. Bkz. Docker ve Railway.
#Giriş ve parolalar
- Parolalar 8–128 karakterdir; boşluk, tırnak ve ters eğik çizgi içeremez. Veritabanında yalnızca özetleri saklanır.
- Kullanıcı adı yoksa da panel aynı hatayla ve aynı sürede yanıt verir; giriş ekranından hangi hesapların var olduğu öğrenilemez.
- Askıya alınmış hesaplar giriş yapamaz, API tokenları da çalışmaz.
- Sunucu Yönetimi → Parola politikası ile parolalara en uzun kullanım süresi verebilirsiniz; süresi dolan kullanıcı sonraki girişte parolasını değiştirmek zorunda kalır.
- İlk yönetici parolasını kurulumdan hemen sonra Sunucu Yönetimi → Parola ve güvenlik sayfasından değiştirin.
#İki aşamalı doğrulama
Her kullanıcı TOTP tabanlı iki aşamalı doğrulamayı kendi sayfasından açar: Sunucu Yönetiminde Parola ve güvenlik, kullanıcı panelinde Parola ve Güvenlik. QR kodu bir doğrulayıcı uygulamayla okutulur ve 6 haneli kodla onaylanır. Uygulamada görünen ad hesabın hizmet sağlayıcısının markasıdır (bayi müşterisi bayinin adını görür). Kapatmak için hesabın parolası gerekir. Yanlış 2FA kodları da başarısız giriş sayılır ve kaba kuvvet sayacına eklenir.
Yedek kurtarma kodu üretilmez. Telefonunu kaybeden kullanıcı için:
- sunucu yöneticisi başka bir yöneticinin 2FA'sını yönetici hesapları ekranından sıfırlayabilir; hesap sahibi de ekip üyesininkini Ekip sayfasından sıfırlayabilir;
- sunucuda root olarak aşağıdaki komut parolayı sıfırlar ve 2FA'yı kapatır. Panel kapalıyken de çalışır, kullanıcının açık oturumlarını kapatır ve tüm IP engellerini kaldırır.
sudo bipanel admin reset-password admin --disable-2fa
#Yöneticiler için zorunlu 2FA
Sunucu Yönetimi → Güvenlik merkezi ekranındaki "Yöneticiler ve bayiler için iki aşamalı doğrulama zorunlu" seçeneği açıkken 2FA kurmamış yönetici ve bayiler Sunucu Yönetimini kullanamaz; yalnızca Parola ve güvenlik sayfasına girip 2FA'yı kurabilirler. Pro'daki süreli üretici destek erişimi bu kuraldan muaftır, çünkü o hesap tek kullanımlık bağlantıyla ve kısa süreliğine girer.
#Oturumlar
- Oturum çerezi
HttpOnlyveSameSite=Laxişaretlidir, HTTPS'teSecureolarak gönderilir. Sunucuda yalnızca oturum kimliğinin özeti saklanır. - Oturum 12 saat hareketsiz kalınca düşer; kullanıldıkça süresi uzar.
- Parola değiştiğinde aynı kullanıcının diğer tüm oturumları kapatılır.
- Parola ve güvenlik sayfasındaki Açık oturumlar listesi IP adresini, tarayıcıyı ve son etkinliği gösterir; oturumları tek tek kapatabilirsiniz.
#Kaba kuvvet koruması ve IP engelleri
Başarısız girişler IP ve kullanıcı adı bazında sayılır. Eşik aşılınca IP adresi süreli olarak engellenir ve panel API'sine erişemez. Ayarlar Sunucu Yönetimi → Güvenlik merkezi ekranındadır.
| Ayar | Varsayılan | Anlamı |
|---|---|---|
| Gözlem süresi (dk) | 15 | Başarısız denemelerin sayıldığı aralık |
| IP başına en fazla deneme | 10 | Farklı kullanıcı adlarıyla yapılan toplam deneme |
| Kullanıcı başına en fazla deneme | 5 | Aynı IP ve aynı kullanıcı adı için |
| Engel süresi (dk) | 30 | Otomatik engelin süresi |
Aynı ekranda elle IP adresi veya CIDR aralığı engelleyebilir, engelleri kaldırabilir ve son 7 günde en çok başarısız deneme yapan adresleri görebilirsiniz. Kendi IP adresinizi engelleyemezsiniz. Güvenilir IP adresleri listesine yazdığınız sabit IP adresleriniz kaba kuvvet sayacıyla engellenmez. Bunlara ek olarak panel API'sinde IP başına istek hızı sınırı vardır; ayrıntılar Ağ ve saldırı koruması sayfasında.
#İstek koruması (CSRF ve başlıklar)
Oturum çereziyle yapılan her değiştirici istek (GET, HEAD ve OPTIONS dışındakiler) panel arayüzünün eklediği özel bir başlığı taşımak zorundadır; başka bir siteden tetiklenen form veya istek bu başlığı ekleyemediği için reddedilir. Panel yanıtları ayrıca katı bir Content-Security-Policy, X-Frame-Options: DENY ve X-Content-Type-Options: nosniff başlıklarıyla gönderilir; panel başka bir sitenin çerçevesine gömülemez.
#Tehlikeli işlemlerde yeniden doğrulama
Bazı sunucu işlemleri açık oturumda da panel parolasını, 2FA açıksa doğrulama kodunu yeniden ister:
- sunucunun root parolasını değiştirme ve sunucuyu yeniden başlatma
- MySQL/MariaDB yönetici veya root parolasını değiştirme
- Disk yöneticisinde bir işlemi uygulama (ayrıca onay metni yazılır)
- Pro: MySQL sürüm yükseltme, uzak masaüstü ayarları ve oturumları, yedek şifreleme anahtarını dışa aktarma, OpenLiteSpeed konsol parolası
Bir yönetici 15 dakikada 5 kez hatalı doğrulama yaparsa bu işlemler 15 dakika kilitlenir; her hatalı deneme işlem geçmişine yazılır.
#İşlem geçmişi
Girişler, başarısız girişler, 2FA ve parola değişiklikleri, bir hesaba "olarak giriş", token oluşturma ve silme ile yönetim işlemleri kullanıcı adı, hedef ve IP adresiyle kaydedilir. Başka birinin hesabına girerek yapılan işlemlerde işlemi yapan kişi olarak giren yönetici veya bayi kaydedilir. Sunucu Yönetimi → İşlem geçmişi ekranı kullanıcıya, işlem türüne, tarih aralığına ve metne göre süzülebilir. Bayiler yalnızca kendi işlemlerini ve kendi hesaplarına ait kayıtları görür. Kayıtlar 180 gün, giriş denemeleri 30 gün saklanır.
#API tokenları
Tokenlar kullanıcı panelinde API Tokenları, Sunucu Yönetiminde API tokenları sayfasından oluşturulur. Token yalnızca oluşturulduğu anda gösterilir; sunucuda özeti saklanır. İsteğe bağlı olarak 1 ile 3650 gün arasında bir geçerlilik süresi verilebilir.
Tokenlarda ayrı yetki kapsamı yoktur: token, sahibi olan kullanıcının tüm yetkileriyle çalışır. Bu yüzden otomasyonlar için süreli token kullanın, kullanılmayanları silin; bir iş daha dar yetki gerektiriyorsa tokenı yalnızca o yetkiye sahip bir hesapta oluşturun. Paketlerde API tokenı özelliği kapatılabilir; ekip üyeleri ve bir hesaba destek amacıyla giren personel token oluşturamaz. Komut satırı aracının root tokenı yalnızca sunucunun kendisinden gelen yerel bağlantılarda geçerlidir. Ayrıntılar: API ve komut satırı.
#Ekip ve yönetici rolleri
- Ekip (kullanıcı paneli): hesap sahibi üyeleri Yönetici, Geliştirici, E-posta yöneticisi, İzleyici veya Özel rolüyle davet eder. Üyeler
üye@hesapbiçimindeki adla, kendi parolaları ve isterlerse kendi 2FA'larıyla girer; ekibi, API tokenlarını ve hesap parolasını yönetemez. Topluluk sürümünde hesap başına en fazla 3 üye eklenebilir, Pro'da sınır yoktur. - Yönetici rolleri (Sunucu Yönetimi): ek yöneticilere Denetçi (salt okunur), Destek (hesaplara giriş ve destek talepleri) veya Operatör (servisler, güncellemeler, bileşenler) rolü verilebilir. Sınırlı roller yedek indirme, parola ve kimlik bilgisi gibi hassas uçları okuyamaz.
- Hesaba giriş izni: bu ayar açıkken bayiler ve sınırlı yöneticiler bir hesaba ancak hesap sahibinin Destek Erişimi sayfasından verdiği süreli izinle girebilir.
- Pro: üretici desteğine en fazla 7 günlük, tek kullanımlık bağlantıyla açılan süreli yönetici erişimi; süre dolunca geçici hesap kendiliğinden kaldırılır.
Bayilik ve ekip ayrıntıları için Bayilik, ekip ve marka.
#Harici kimlik doğrulama
Sunucu Yönetimi → Harici kimlik doğrulama ekranından OpenID Connect sağlayıcıları eklenir; kullanıcılar kimliklerini Parola ve güvenlik → Bağlı hesaplar bölümünden bağlar. Genel OpenID Connect sağlayıcısı topluluk sürümündedir; Google, Microsoft Entra ID, GitHub, GitLab ve Keycloak hazır ayarları Pro'dadır.
Varsayılan olarak panelde 2FA'sı açık kullanıcı harici girişten sonra da kodu girer. Sağlayıcı "Sağlayıcının çok aşamalı doğrulamasına güven" kipindeyse ve çok aşamalı doğrulama yapıldığını bildirirse kod sorulmaz; Sunucu Yönetimi kullanıcıları için kodun her zaman sorulmasını ayrıca seçebilirsiniz.
#SSO zorunluluğu (Pro)
Pro'da yönetici ve bayi girişlerinde SSO zorunlu tutulabilir; bu durumda doğru parola da oturum açmaz. Zorunluluğu açmadan önce bir acil durum yöneticisi seçmeniz gerekir. Panel erişilemez hâle gelirse sunucuda şu komutlar kullanılır:
sudo bipanel admin sso-link
sudo bipanel admin sso-disable
İlki tek kullanımlık bir acil durum giriş bağlantısı üretir, ikincisi zorunluluğu kapatır.
#Kurulumdan sonra kontrol listesi
- İlk yönetici parolasını değiştirin ve 2FA'yı açın.
- Güvenlik merkezinde yöneticiler için 2FA zorunluluğunu açın, kendi sabit IP adreslerinizi güvenilir listeye ekleyin.
- Sunucu adı için Let's Encrypt sertifikası alın.
- Mümkünse 2087 portunu güvenlik duvarında yalnızca ofis veya VPN adreslerine açın.
- Kullanılmayan API tokenlarını silin, işlem geçmişini düzenli gözden geçirin.
Genel güvenlik yaklaşımı için Güvenlik sayfasına bakın.
Bu sayfada eksik ya da hatalı bir bilgi mi var? Bize yazın.