Example Ubuntu

Merhaba Arkadaşlar,

Iptables kuralı ile TCP/UDP log’ları yakalamak için aşağıdaki kural kullanılabilir.
Girilen chain altındaki tüm paketleri log’lar.

Aşağıdaki INPUT chain ismi oluyor. Farklı chain’ler kullanıyorsanız hepsine uygulamanız gerekmektedir.
Ben tüm TCP/UDP paketlerini log’luyorum. Aşağıdaki rule değiştirilerek farklı log’lar alınabilir. Örneğin DENY alınan paketler veya tcp 443 vb gibi.

Kural girildikten sonra /etc/rsyslog.d altında aşağıdaki tanımların yapılması gerekmektedir.

Bu işlem sonrasında /etc/rsyslog.conf dosyası içinde ent alt kısma aşağıdaki satırı ekleyerek rsyslog servisini restart etmeniz yeterli olacaktır.



Örnek log çıktısı;

Kolay Gelsin.

Linux sunucu üzerinde örnek olarak sdb diskini umount ettiğiniz zaman sunucu reboot sonrasında ekteki hatayı alabilirsiniz. Sunucu her reboot sonrasında dev-sdb1.device’ı başlatmaya çalışır. Bu işlemi yaparken 1:30 dakika kadar bekler. Sunucu açılmasınıda yavaşlatır.  Ben yaşadığım sorunda systemctl tarafında bozulmalar olmuştu. Sunucu açıldıktan sonra servisler başlamamaktaydı. Çözüm olarak /etc/fstab altında disk için “/dev/sdb1 /mnt/data xfs defaults 0 0” şeklinde bir tanım varsa problemin kaynağı bu demektir. Bu satırı silebilirsiniz yada # işareti ile disable duruma getirebilirsiniz. Bir sonraki reboot ile problem ortadan kalkacaktır. Belirtmiş olduğum işlemi aşağıdaki dizinde yapıyoruz.

Linux sunucu üzerinde NAT işlemi yapmak için aşağıdaki adımları sırasıyla izliyoruz.

Sunucumuzda 2 interface olduğunu düşünelim. ens160 olarak gördüğümüz public IP’nin olduğu interface,  yani dış bacak interface’i. ens192 olarak görmüş olduğunuz interface ise private block. NAT’lanacak olan interface. Yapacağımız işlem sonrasında 10.100.0.0 network’ü üzerinde olan bir client dış dünyaya 10.10.10.10 IP’si ile çıkış yapacak.

 

 

 

 

 

 

 

 

 

Sunucu üzerindeki interface’leri aktif ettikten sonra host dosyasını aşağıdaki gibi düzeltiyoruz. Aşağıyı sunucu hostname’ine göre düzenleyebilirsiniz. Ben örnek olarak ubnt1.localhost olarak düzenledim.

Bu işlem sonrasında makina üzerinde DNS ayarlarını yapıyoruz.

Bu işlemleri tamamladıktan sonra aşağıdaki iptables kurallarını girip sonrasında iptables servisini stop/start yapmamız yeterli.

Girmiş olduğumuz iptables kuralları sunucu restart sonrasında silinecektir. Kalıcı olması için aşağıdaki işlemleri yapmanız gerekiyor.

iptables-persistent’ı kurduktan sonra aşağıdaki komut ile birlikte girmiş olduğumuz iptables kurallarını kaydediyoruz. (bu komut girmiş olduğumuz kuralları kaydeder.)

Aşağıdaki komut ise mevcutta kaydedilmiş bir kural dizini var ise o dizin listesinden iptables’ı restore eder.

tüm bu işlemler sonrasında ens192 arkasında olan client üzerinden internet erişimi sağlıklı şekilde sağlanacaktır.

Kolay Gelsin.

1- İlk adım olarak sunucu üzerinde plugin dizinine gidiyoruz.

2 – Bu dizine geldikten sonra aşağıdaki komut ile plugini makinaya çekiyoruz.

 

3 – plugin dosyasını indirdikten sonra kontrol ediyoruz.

 

4 – Dosyanın sağlıklı şekilde indiğini gördükten sonra bu dosyayı bu dizin altına çıkarıyoruz.

 

5 – plugin dosyalarını buraya çıkardıktan sonra aşağıdaki komutlar yardımı ile kontrol edebilirsiniz.

6 – bu işlemlerden sonra yapmanız gereken tek işlem cacti web üzerinden kurmuş olduğumuz plugini aktif etmek.

 

 

 

7 – plugin aktif edildikten sonra aşağıdaki bölümden gerekli tanımları gerçekleştirebilirsiniz.

What is Squid?

Squid is a fully-featured HTTP/1.0 proxy which is almost (but not quite – we’re getting there!) a fully-featured HTTP/1.1 proxy. Squid offers a rich access control, authorization and logging environment to develop web proxy and content serving applications. Squid offers a rich set of traffic optimization options, most of which are enabled by default for simpler installation and high performance.

Where did Squid come from?

Squid is based on the Harvest Cache Daemon developed in the early 1990’s. It was one of two forks from the codebase after the Harvest project ran to completion. (The other fork being what became Netapp’s Netcache.)

The Squid project was funded by an NSF grant (NCR-9796082) which covered research into caching technologies. The ircache funding ran out a few years later and the Squid project continued through volunteer donations and the occasional commercial investment.

Squid is currently being developed by a handful of individuals donating their time and effort to building current and next generation content caching and delivery technologies. An ever-growing number of companies use Squid to save on their internet web traffic, improve performance, deliver faster browsing to their end-clients and provide static, dynamic and streaming content to millions of internet users worldwide.

Who uses Squid today?

A good question! Many of you are using Squid without even knowing it! Some companies have embedded Squid in their home or office firewall devices, others use Squid in large-scale web proxy installations to speed up broadband and dialup internet access. Squid is being increasingly used in content delivery architectures to deliver static and streaming video/audio to internet users worldwide.

 

Why should I deploy Squid?

(Or.. “Why should I bother with web caching? Can’t I just buy more bandwidth?”)

The developers of the HTTP protocol identified early on that there was going to be exponential growth in content and, concerned with distribution mechanisms, added powerful caching primitives.

These primitives allow content developers and distributors to hint to servers and end-user applications how content should be validated, revalidated and cached. This had the effect of dramatically reducing the amount of bandwidth required to serve content and improved user response times.

Squid is one of the projects which grew out of the initial content distribution and caching work in the mid-90s. It has grown to include extra features such as powerful access control, authorization, logging, content distribution/replication, traffic management and shaping and more. It has many, many work-arounds, new and old, to deal with incomplete and incorrect HTTP implementations.

For ISPs: Save on bandwidth, improve user experience

Squid allows Internet Providers to save on their bandwidth through content caching. Cached content means data is served locally and users will see this through faster download speeds with frequently-used content.

A well-tuned proxy server (even without caching!) can improve user speeds purely by optimising TCP flows. Its easy to tune servers to deal with the wide variety of latencies found on the internet – something that desktop environments just aren’t tuned for.

Squid allows ISPs to avoid needing to spend large amounts of money on upgrading core equipment and transit links to cope with ever-demanding content growth. It also allows ISPs to prioritise and control certain web content types where dictacted by technical or economic reasons.

For Websites: Scale your application without massive investment in hardware and development time

Squid is one of the oldest content accelerators, used by thousands of websites around the world to ease the load on their servers. Frequently-seen content is cached by Squid and served to the end-client with only a fraction of the application server load needed normally. Setting up an accelerator in front of an existing website is almost always a quick and simple task with immediate benefits.

For Content Delivery Providers: distribute your content worldwide

Squid makes it easy for content distributors and streaming media developers to distribute content worldwide. CDN providers can buy cheap PC hardware running Squid and deploy in strategic locations around the internet to serve enormous amounts of data cheaply and efficiently.

A large number of companies have deployed servers running Squid in the past in exactly this manner.

Reference

http://www.squid-cache.org/