Captive portal da farklı dns kullanan bilgisayarlarda login gelmemesi (çözüldü)
-
captive portal settings sayfasında allowed ip addresses var oraya dnsleri tek tek girmen lazım.
direction lari da both olmalı.
örnek benim bildiğim dnsler
any 8.8.8.8 dns1 any 156.154.70.1 dns27 any 156.154.71.1 dns26 any 195.175.39.39 dns25 any 198.153.192.1 dns24 any 198.153.194.1 dns23 any 199.5.157.131 dns22 any 207.225.209.66 dns21 any 208.67.222.220 dns20 any 208.67.222.222 dns19 any 208.71.35.137 dns18 any 209.244.0.3 dns17 any 209.244.0.4 dns16 any 216.87.84.211 dns15 any 4.2.2.1 dns14 any 4.2.2.2 dns13 any 4.2.2.3 dns12 any 4.2.2.4 dns11 any 4.2.2.5 dns10 any 4.2.2.6 dns9 any 67.138.54.100 dns8 any 69.164.208.50 dns7 any 74.118.212.1 dns6 any 74.118.212.2 dns5 any 8.20.247.20 dns4 any 8.26.56.26 dns3 any 8.8.4.4 dns2henüz deneme fırsatım olmadı. aklıma şöyle bir şey geldi. merakımdan dillendirdim. madem dns lerin ip adreslerine captive portaldan izin verince login ekranı illaki karşımıza çıkıyorsa (dns olarak pf kullanmayan bilgisayarlarda bile) neden 53 nolu portu açmıyoruz?
-
elbette açabilirsin. ama arayüzden normal kural şekline olmaz malesef.
shellcmd paketini yükleyip ipfw kuralları ekleyeceksin.
örnek
ipfw add allow udp from any to any dst-port 53 keep-state
ipfw add allow tcp from any to any dst-port 53 keep-statenot: gibi test edilmedi!
-
elbette açabilirsin. ama arayüzden normal kural şekline olmaz malesef.
shellcmd paketini yükleyip ipfw kuralları ekleyeceksin.
örnek
ipfw add allow udp from any to any dst-port 53 keep-state
ipfw add allow tcp from any to any dst-port 53 keep-statenot: gibi test edilmedi!
şimd bunu uyguladığımda; farklı dns adresleri kullanan bilgisayarlarda da captive portal işe yarayacak mı? login ekranı sorunsuzca karşımıza gelecek mi? uygulama fırsatım şuan olmadığı için soruyorum. uygulayınca sonucu paylaşıcam.
-
elbette açabilirsin. ama arayüzden normal kural şekline olmaz malesef.
shellcmd paketini yükleyip ipfw kuralları ekleyeceksin.
örnek
ipfw add allow udp from any to any dst-port 53 keep-state
ipfw add allow tcp from any to any dst-port 53 keep-statenot: gibi test edilmedi!
bu şekilde olmadı. bende şöyle denedim oldu. ((-;<
ipfw add 65000 allow udp from any to any dst-port 53 keep-state ipfw add allow 65001 tcp from any to any dst-port 53 keep-stateşimdi shellcmd yi ayarlıyacağım. type olarak shellcmd yeterli değil mi?
teşekkürler asbirim. -
captive portal settings sayfasında allowed ip addresses var oraya dnsleri tek tek girmen lazım.
direction lari da both olmalı.
örnek benim bildiğim dnsler
any 8.8.8.8 dns1 any 156.154.70.1 dns27 any 156.154.71.1 dns26 any 195.175.39.39 dns25 any 198.153.192.1 dns24 any 198.153.194.1 dns23 any 199.5.157.131 dns22 any 207.225.209.66 dns21 any 208.67.222.220 dns20 any 208.67.222.222 dns19 any 208.71.35.137 dns18 any 209.244.0.3 dns17 any 209.244.0.4 dns16 any 216.87.84.211 dns15 any 4.2.2.1 dns14 any 4.2.2.2 dns13 any 4.2.2.3 dns12 any 4.2.2.4 dns11 any 4.2.2.5 dns10 any 4.2.2.6 dns9 any 67.138.54.100 dns8 any 69.164.208.50 dns7 any 74.118.212.1 dns6 any 74.118.212.2 dns5 any 8.20.247.20 dns4 any 8.26.56.26 dns3 any 8.8.4.4 dns2bunu da denedim. gayette güzel çalıştı ama sürekli bir dns avcılığı gerekiyor bunda. bir yukardaki çözüm biraz daha uygun. en azından ayarla unut.
-
bu şekilde olmadı. bende şöyle denedim oldu. ((-;<
ipfw add 65000 allow udp from any to any dst-port 53 keep-state ipfw add allow 65001 tcp from any to any dst-port 53 keep-stateşimdi shellcmd yi ayarlıyacağım. type olarak shellcmd yeterli değil mi?
teşekkürler asbirim.bu şekilde shellcmd olunca çalışır ama her captive portal restart ettiğinde veya save ettiğinde kurallar silinir. o yüzden /etc/inc/captiveportal.inc dosyasındaki kuralların oluşturulduğu yerde eklesrsen daha garanri olur.
-
bu şekilde olmadı. bende şöyle denedim oldu. ((-;<
ipfw add 65000 allow udp from any to any dst-port 53 keep-state ipfw add allow 65001 tcp from any to any dst-port 53 keep-stateşimdi shellcmd yi ayarlıyacağım. type olarak shellcmd yeterli değil mi?
teşekkürler asbirim.bu şekilde shellcmd olunca çalışır ama her captive portal restart ettiğinde veya save ettiğinde kurallar silinir. o yüzden /etc/inc/captiveportal.inc dosyasındaki kuralların oluşturulduğu yerde eklesrsen daha garanri olur.
tavsiyeniz üzerine dediğiniz dosyayı inceledim. zannediyorum $cprules ile başlayan 489. satırdan evvel uygun şekilde bu komutları girmem yetecektir. ama nasıl ekleyeceğimi kestiremedim. ipfw ye biraz yabancıyım.
$cprules = "add 65001 allow tcp from any to any 53 keep-state\n"; $cprules .= "add 65002 allow udp from any to any 53 keep-state\n"; $cprules .= "add 65291 set 1 allow pfsync from any to any\n"; $cprules .= "add 65292 set 1 allow carp from any to any\n";olarak düzenlemem doğru mudur? ipfw kural yazmışlığım yok.
yardımların için teşekkürler asbirim.
-
# redirect non-authenticated clients to captive portal add 65531 set 1 fwd 127.0.0.1,8000 tcp from any to any inbu satırın ustune ekleyebilrsiniz. ama unutmayın eklediniz kuraldan sonra kural numaralarını yeniden sıralayın.
örnek
#dns pass #dns pass add 65531 allow udp from any to any dst-port 53 keep-state add 65532 allow tcp from any to any dst-port 53 keep-state # redirect non-authenticated clients to captive portal add 65533 set 1 fwd 127.0.0.1,8000 tcp from any to any in # let the responses from the captive portal web server back out add 65534 set 1 pass tcp from any to any out # block everything else add 65535 set 1 deny all from any to any # pass everything else on layer2 add 65536 set 1 pass all from any to any layer2gibi. bu işlemi yönlendirme kuralanın üzerinde yapmanız en az değişiklik gerektiren yöntem gibi gözüküyor.
-
# redirect non-authenticated clients to captive portal add 65531 set 1 fwd 127.0.0.1,8000 tcp from any to any inbu satırın ustune ekleyebilrsiniz. ama unutmayın eklediniz kuraldan sonra kural numaralarını yeniden sıralayın.
örnek
#dns pass #dns pass add 65531 allow udp from any to any dst-port 53 keep-state add 65532 allow tcp from any to any dst-port 53 keep-state # redirect non-authenticated clients to captive portal add 65533 set 1 fwd 127.0.0.1,8000 tcp from any to any in # let the responses from the captive portal web server back out add 65534 set 1 pass tcp from any to any out # block everything else add 65535 set 1 deny all from any to any # pass everything else on layer2 add 65536 set 1 pass all from any to any layer2gibi. bu işlemi yönlendirme kuralanın üzerinde yapmanız en az değişiklik gerektiren yöntem gibi gözüküyor.
kural numalarında daha az değişiklik yapmak için geriye doğru verdim. sonuç olarak kod:
#dns pass add 65529 allow udp from any to any dst-port 53 keep-state add 65530 allow tcp from any to any dst-port 53 keep-state # redirect non-authenticated clients to captive portal add 65531 set 1 fwd 127.0.0.1,8000 tcp from any to any in # let the responses from the captive portal web server back out add 65532 set 1 pass tcp from any to any out # block everything else add 65533 set 1 deny all from any to any # pass everything else on layer2 add 65534 set 1 pass all from any to any layer2oldu ve sıkı bir teste tabi tutacağım. yerinde iken yaptığım testlerden geçmişti. umarım yakında çözüldü ibaresini asarız başlığımıza.
bu değişiklikten sonra shellcmd ile girdiğim kurallarada gerek kalmadı artık, değil mi?
tekrar teşekkürler asbirim.
-
test sonucu başarılı olursa, bu post forumun international kısmında bile baya insanın faydasına dokunacaktır.
-
kesinlikle tuzsuzdeli kardeşim. kıt ingilizcemle ingilizce kısmını didik didik incelemiştim. ama birşey çıkaramadım. hakeza monowall forumlarında da araştırmıştım. sonra bu captive portal nedir onu araştırdım. captive portal ile alakalı sorular sordum ama aldığım cevaplar işime yaramamıştı. burda asbirim kardeşimin önerdiği dns iplerini captive portala izinli olarak girmekten bu fikir çıktı. kendi blgisayarımda yaptığım testlerden geçti ama esas kullananların sonucu önemli. ben bir kaç notebook ile deneyeceğim gene en kısa zamanda.
ekleme: bugün 3 adet notebook ile denedim. windows 8 pro, windows 7 pro, kubuntu 13.04, kubuntu 12.10 denemelerimde başarılı oldum. 2 yukardaki eklemeyi yapınca captive portalın login sorunları büyük ölçüde ortadan kalkıyor. bence çözüldü ekleyip, sticky yapıp international foruma eklenebilir.
-
denedim. gayet başarılı çalıştı. Sabri Beye (asbirim) bu konudaki çözüm önerisi için , forum üyelerimiz adına tekrar teşekkür ediyorum
-
elbette açabilirsin. ama arayüzden normal kural şekline olmaz malesef.
shellcmd paketini yükleyip ipfw kuralları ekleyeceksin.
örnek
ipfw add allow udp from any to any dst-port 53 keep-state
ipfw add allow tcp from any to any dst-port 53 keep-statenot: gibi test edilmedi!
Bu şekilde tcp 53 ve udp 53 portlarına izin vermek dışarıdaki DNS sunuculara ulaşmayı muhakkak kolaylaştırır. Ancak kullanıcıların bu portlar üzerinden tüneleme yaparak kimlik doğrulama vs yapmaksızın özgürce internete çıkması mümkündür. Bu kurallar kendi elinizle captiveportalın aşılmasını sağlayacak bir delik açmak anlamına gelir… Güvenlik sizin için önemliyse bu şekilde bir firewall kuralı girmeniz iyi bir fikir olmayabilir... Dikkatli kullanmak gerekir... :)
Saygılarımla...
-
Bu şekilde tcp 53 ve udp 53 portlarına izin vermek dışarıdaki DNS sunuculara ulaşmayı muhakkak kolaylaştırır. Ancak kullanıcıların bu portlar üzerinden tüneleme yaparak kimlik doğrulama vs yapmaksızın özgürce internete çıkması mümkündür. Bu kurallar kendi elinizle captiveportalın aşılmasını sağlayacak bir delik açmak anlamına gelir… Güvenlik sizin için önemliyse bu şekilde bir firewall kuralı girmeniz iyi bir fikir olmayabilir... Dikkatli kullanmak gerekir... :)
Saygılarımla...
muhakkak haklısın şeker kardeş. fakat bunu kullanacağım yerlerde bu çok sorun olmayacaktır. söyleyebilirmisin kendi çevrende böyle bir sistem kullanan işyerlerinde çalışan kaç kişi 53 nolu porttan tünelleme yaparak özgürce internete çıkmayı düşünecek kadar network bilgisine sahip? benim çevremde ancak sistem yönetcileri biliyor bunları. dediğim gibi kendi çevremde sorun olmayak. yoksa bunu keşfettiğimden bu yana neden böyle bir çözümü vardıda yapılmadı diye düşünüyordum. güvenlik nedeni ile olduğunu farkettim.
bu bilgilendirmeniz için teşekkürler şeker kardeş. kullanacak olanlar bunu dikkate almalıdır. zira herkesin hitap ettği kullanıcılar farklı. belki başkasının kullanıcısı bunu değerlendirebilir.
-
Bu şekilde tcp 53 ve udp 53 portlarına izin vermek dışarıdaki DNS sunuculara ulaşmayı muhakkak kolaylaştırır. Ancak kullanıcıların bu portlar üzerinden tüneleme yaparak kimlik doğrulama vs yapmaksızın özgürce internete çıkması mümkündür. Bu kurallar kendi elinizle captiveportalın aşılmasını sağlayacak bir delik açmak anlamına gelir… Güvenlik sizin için önemliyse bu şekilde bir firewall kuralı girmeniz iyi bir fikir olmayabilir... Dikkatli kullanmak gerekir... :)
Saygılarımla...
muhakkak haklısın şeker kardeş. fakat bunu kullanacağım yerlerde bu çok sorun olmayacaktır. söyleyebilirmisin kendi çevrende böyle bir sistem kullanan işyerlerinde çalışan kaç kişi 53 nolu porttan tünelleme yaparak özgürce internete çıkmayı düşünecek kadar network bilgisine sahip? benim çevremde ancak sistem yönetcileri biliyor bunları. dediğim gibi kendi çevremde sorun olmayak. yoksa bunu keşfettiğimden bu yana neden böyle bir çözümü vardıda yapılmadı diye düşünüyordum. güvenlik nedeni ile olduğunu farkettim.
bu bilgilendirmeniz için teşekkürler şeker kardeş. kullanacak olanlar bunu dikkate almalıdır. zira herkesin hitap ettği kullanıcılar farklı. belki başkasının kullanıcısı bunu değerlendirebilir.
Dediğim gibi güvenlik politikanız bu noktada önemli. Eğer sorun olmayacağını düşünüyorsanız kullanmanızda bir sakınca yok. Ancak şahsi fikrimce kamuya açık bir ağda kullanacaksanız "nasılsa bunları kimse bilmiyor" diyerek riske girmeyin derim :) Tünelleme işlemleri basit şeyler ve pek çok insan tarafından artık biliniyor. Kullanıcı kitleniz öğrencilerden falan oluşuyorsa aklınıza gelmeyecek bir bir şeytanlığı deneyeceklerini tecrübe ile sabitleyebilirsiniz :)
Ağınız kamuya açıksa, misafirlerinizin kim olduğunu ve niyetlerini bilmiyorsanız hepsinin "kötü adam" olduğunu var saymak gerekir diye düşünüyorum :)
Saygılarımla…
-
Dediğim gibi güvenlik politikanız bu noktada önemli. Eğer sorun olmayacağını düşünüyorsanız kullanmanızda bir sakınca yok. Ancak şahsi fikrimce kamuya açık bir ağda kullanacaksanız "nasılsa bunları kimse bilmiyor" diyerek riske girmeyin derim :) Tünelleme işlemleri basit şeyler ve pek çok insan tarafından artık biliniyor. Kullanıcı kitleniz öğrencilerden falan oluşuyorsa aklınıza gelmeyecek bir bir şeytanlığı deneyeceklerini tecrübe ile sabitleyebilirsiniz :)
Ağınız kamuya açıksa, misafirlerinizin kim olduğunu ve niyetlerini bilmiyorsanız hepsinin "kötü adam" olduğunu var saymak gerekir diye düşünüyorum :)
Saygılarımla…
pek sorması ayıp değil (ayıp olsa sormam, edepsizliğin gerek yok değil mi?) sizin bu soruna bir çözüm öneriniz var mı?
-
Dediğim gibi güvenlik politikanız bu noktada önemli. Eğer sorun olmayacağını düşünüyorsanız kullanmanızda bir sakınca yok. Ancak şahsi fikrimce kamuya açık bir ağda kullanacaksanız "nasılsa bunları kimse bilmiyor" diyerek riske girmeyin derim :) Tünelleme işlemleri basit şeyler ve pek çok insan tarafından artık biliniyor. Kullanıcı kitleniz öğrencilerden falan oluşuyorsa aklınıza gelmeyecek bir bir şeytanlığı deneyeceklerini tecrübe ile sabitleyebilirsiniz :)
Ağınız kamuya açıksa, misafirlerinizin kim olduğunu ve niyetlerini bilmiyorsanız hepsinin "kötü adam" olduğunu var saymak gerekir diye düşünüyorum :)
Saygılarımla…
pek sorması ayıp değil (ayıp olsa sormam, edepsizliğin gerek yok değil mi?) sizin bu soruna bir çözüm öneriniz var mı?
Eğer sizin için güvenlik, kullanılabilirlikten önemliyse çözüm kolay. Hali hazırda olduğu gibi herkes sizin DNS sunucunuzu girecek :) Nasıl ki siz servis sağlayıcının size verdiği ağ ayarları dışında keyfinize göre ayar yapamıyorsanız misafirlerinizde kullanamayacak…
Yok misafirlerim canlarının istediği gibi kullansın diyorsanız izin verilebilir. Hem izin vereyim hem kontrol edeyim derseniz trafiğin normal dns trafiği olup olmadığını kontrol eden snort kuralları yazmak gerekir. Çok sancılı bir süreç olacaktır :)
-
@seker'e katılıyorum.
Kendi network kullanıcılarınız için zaten "istedikleri dns sunucusunu kullanırlar" gibi bir durum sözkonusu değil.
Dışarıdan gelenleri mutlaka başka bir interface üzerinden internete bağlamakta fayda var.
En basitinden bir tane ethernet bir tane de kablosuz acces pointten geçer çözüm. -
Eğer sizin için güvenlik, kullanılabilirlikten önemliyse çözüm kolay. Hali hazırda olduğu gibi herkes sizin DNS sunucunuzu girecek :) Nasıl ki siz servis sağlayıcının size verdiği ağ ayarları dışında keyfinize göre ayar yapamıyorsanız misafirlerinizde kullanamayacak…
Yok misafirlerim canlarının istediği gibi kullansın diyorsanız izin verilebilir. Hem izin vereyim hem kontrol edeyim derseniz trafiğin normal dns trafiği olup olmadığını kontrol eden snort kuralları yazmak gerekir. Çok sancılı bir süreç olacaktır :)
@seker'e katılıyorum.
Kendi network kullanıcılarınız için zaten "istedikleri dns sunucusunu kullanırlar" gibi bir durum sözkonusu değil.
Dışarıdan gelenleri mutlaka başka bir interface üzerinden internete bağlamakta fayda var.
En basitinden bir tane ethernet bir tane de kablosuz acces pointten geçer çözüm.ben 93 den beri adanadayım. değişik amaçlar için bir çok firmaya linux çözümleri sundum. kabul edenleri gerçekleştirdim. bu sırada da gördüm ki firmalarda çalışaların basit network ayarlarını bırakın bilgisayardan haberi yok. sadece kullanması gereken programı kullanmayı biliyorlar. örneğin bir otel düşünün. hotspot ile müşterilerine internet hizmeti verecek aynı zamanda çevreden interneti koruyacak. hotspot çözümleri şimdilerde biraz daha makul denilebilecek seviyelerde, ama 5 yıl evvel iyi para idi. nix çözümleri ile hala da şuanki hotspotların yarı fiyatına yapılabilinir. bu otele 5 sene evvel gelen müşteriler farklı dns kullanıyorlarsa bunu nasıl düzelteceklerini bilmiyorlardı. şimdilerde saolsun değişik yasaklar sebebi ile herkes öğrendi. bende google ve tübitak dns adreslerini kullanıyorum, kullandırıyorum. gelgelelim bu sorunun dns çözümlemesinden kaynaklandığını asbirim söyleyene kadar çokda düşünmemiştim. hem örnek otelimize gelen müşterilerin kaçı farklı dns kullanıyor olacak ki? ama kullanan geldiğinde de ne biçim sisteminiz var? beş para etmez bilgisayarcını var derse buda herkesin canını sıkıyor.
hülasa; örnek otelimizde zaten captiveportal sadece müşterilere şifre ile kullandırılıyor çevreninde girmesi engelleniyor. diyelim ve zurnanın zırt dediği yere gelelim. diğer ticari çözümlerde bu durum nasıl acaba? onlar bunu aşmışlarsa nasıl aşmışlar? bilen var mı?
-
Eğer sizin için güvenlik, kullanılabilirlikten önemliyse çözüm kolay. Hali hazırda olduğu gibi herkes sizin DNS sunucunuzu girecek :) Nasıl ki siz servis sağlayıcının size verdiği ağ ayarları dışında keyfinize göre ayar yapamıyorsanız misafirlerinizde kullanamayacak…
Yok misafirlerim canlarının istediği gibi kullansın diyorsanız izin verilebilir. Hem izin vereyim hem kontrol edeyim derseniz trafiğin normal dns trafiği olup olmadığını kontrol eden snort kuralları yazmak gerekir. Çok sancılı bir süreç olacaktır :)
@seker'e katılıyorum.
Kendi network kullanıcılarınız için zaten "istedikleri dns sunucusunu kullanırlar" gibi bir durum sözkonusu değil.
Dışarıdan gelenleri mutlaka başka bir interface üzerinden internete bağlamakta fayda var.
En basitinden bir tane ethernet bir tane de kablosuz acces pointten geçer çözüm.ben 93 den beri adanadayım. değişik amaçlar için bir çok firmaya linux çözümleri sundum. kabul edenleri gerçekleştirdim. bu sırada da gördüm ki firmalarda çalışaların basit network ayarlarını bırakın bilgisayardan haberi yok. sadece kullanması gereken programı kullanmayı biliyorlar. örneğin bir otel düşünün. hotspot ile müşterilerine internet hizmeti verecek aynı zamanda çevreden interneti koruyacak. hotspot çözümleri şimdilerde biraz daha makul denilebilecek seviyelerde, ama 5 yıl evvel iyi para idi. nix çözümleri ile hala da şuanki hotspotların yarı fiyatına yapılabilinir. bu otele 5 sene evvel gelen müşteriler farklı dns kullanıyorlarsa bunu nasıl düzelteceklerini bilmiyorlardı. şimdilerde saolsun değişik yasaklar sebebi ile herkes öğrendi. bende google ve tübitak dns adreslerini kullanıyorum, kullandırıyorum. gelgelelim bu sorunun dns çözümlemesinden kaynaklandığını asbirim söyleyene kadar çokda düşünmemiştim. hem örnek otelimize gelen müşterilerin kaçı farklı dns kullanıyor olacak ki? ama kullanan geldiğinde de ne biçim sisteminiz var? beş para etmez bilgisayarcını var derse buda herkesin canını sıkıyor.
hülasa; örnek otelimizde zaten captiveportal sadece müşterilere şifre ile kullandırılıyor çevreninde girmesi engelleniyor. diyelim ve zurnanın zırt dediği yere gelelim. diğer ticari çözümlerde bu durum nasıl acaba? onlar bunu aşmışlarsa nasıl aşmışlar? bilen var mı?
İlk olarak tüm müşterilerinizin bilgisayardan anlamadığı varsayımındasınız. Genel olarak haklı olabilirsiniz ama zaten bilgisayardan anlamayan müşteri sizin için risk taşımıyor. Mesele risk taşıyan "yaramaz" kullanıcının otele gelmesi. Bu durumda tcp 53 ve udp 53'ün her yere açık olması sıkıntı çıkartır ki biz zaten güvenlik önlemlerini uslu duran kullanıcılar için değil yaramaz kullanıcılar için alıyoruz… Yaramazlık yapmak isteyecek bir kullanıcının ilk deneyeceği -hadi bilemediniz ikinci deneyeceği- bağlantı noktası 53 olacaktır...
Belirli DNS sunucularını izinli eklemenizde bir sakınca yok. Ama "any to any" şeklinde her hangi bir porta izin verirseniz bu size güvenlik açığı olarak döner... Bu ise "ürün" temelli bir sorun değildir "politika" temelli bir sorundur... pfSense veya ticari bir firewall kullanmanız sonucu değiştirmez. Milyon dolar değerinde bir firewall'u da her yerden her yere tcp/udp 53 erişimine izin ver diyerek yapılandırırsanız yine tünel kazılmasına izin verecek bir güvenlik açığı oluşturmuş olursunuz...
Neresi olduğu çok önemli olmayan, ama "önemli" bir kuruma yapılan güvenlik testinde benzer bir tcp/udp 53 portu yapılandırma hatası nedeniyle atm makinelerinin (hani şu para çekmek için kullandığımız cihazlar) olduğu ağa erişim sağlanmıştı.
Benzer şekilde Captiveportal ile Squid'i bir arada kullanıyor ve özel bir firewall kuralı yazmıyorsanız yine kullanıcıların kimlik doğrulama yapmadan internete çıkmasına neden oluyor... Yine bir güvenlik denetiminde, benzer şekilde yanlış yapılandırılan bir squid yüzünden dışarıdan iç networke sızılmıştı... :)
Daha önce de dediğim gibi bu kurallar tamamen güvenlik politkanızla alakalıdır. Güvenlik politikanız bu durumu hoş görüyorsa veya bunun bir risk olmadığını düşünüyorsanız kullanabilirsiniz. Size kullanmayın veya bunu kullanın demiyoruz. Sadece böyle bir risk olduğunun farkında olun diyoruz... Farkındaysanız ve riski kabulleniyorsanız, erişilebilirlik güvenlikten daha önemliyse (ki olabilir) kullanmanızda bir sakınca yoktur... :)
Saygılarımla...