Năm 2010 công ty có 50 máy chủ và một mô hình mạng đơn giản: phụ trợ, giao diện người dùng và tường lửa. Số lượng máy chủ tăng lên, mô hình trở nên phức tạp hơn: dàn dựng, VLAN biệt lập với ACL, rồi đến VPN với VRF, VLAN với ACL trên L2, VRF với ACL trên L3. Đầu đang quay cuồng? Về sau sẽ vui hơn.
Khi có 16 máy chủ, việc hoạt động không thể thiếu nước mắt với quá nhiều phân khúc không đồng nhất như vậy. Vì vậy chúng tôi đã nghĩ ra một giải pháp khác. Chúng tôi đã sử dụng ngăn xếp Netfilter, thêm Consul vào đó làm nguồn dữ liệu và chúng tôi có được tường lửa được phân phối nhanh chóng. Họ đã thay thế ACL trên bộ định tuyến và sử dụng chúng làm tường lửa bên ngoài và bên trong. Để quản lý công cụ một cách linh hoạt, chúng tôi đã phát triển hệ thống BEFW, hệ thống này được sử dụng ở mọi nơi: từ quản lý quyền truy cập của người dùng vào mạng sản phẩm đến cách ly các phân đoạn mạng với nhau.
Anh ấy sẽ cho bạn biết nó hoạt động như thế nào và tại sao bạn nên xem xét kỹ hơn hệ thống này. Ivan Agarkov () là người đứng đầu nhóm an ninh cơ sở hạ tầng của bộ phận Bảo trì tại trung tâm phát triển Minsk của công ty. Ivan là một người hâm mộ SELinux, yêu thích Perl và viết mã. Với tư cách là người đứng đầu nhóm bảo mật thông tin, anh thường xuyên làm việc với nhật ký, bản sao lưu và R&D để bảo vệ Wargaming khỏi tin tặc và đảm bảo hoạt động của tất cả các máy chủ trò chơi trong công ty.
Thông tin lịch sử
Trước khi kể cho bạn biết chúng tôi đã làm như thế nào, tôi sẽ cho bạn biết chúng tôi đã đạt được điều này như thế nào ngay từ đầu và tại sao nó lại cần thiết. Để làm được điều này, chúng ta hãy quay ngược lại 9 năm: 2010, World of Tanks mới xuất hiện. Wargaming có khoảng 50 máy chủ.
Biểu đồ tăng trưởng máy chủ của công ty.
Chúng tôi đã có một mô hình mạng. Vào thời điểm đó nó là tối ưu.
Mô hình mạng năm 2010
Có những kẻ xấu ở phía trước muốn phá vỡ chúng tôi, nhưng nó có tường lửa. Không có tường lửa ở phần phụ trợ, nhưng có 50 máy chủ ở đó, chúng tôi biết tất cả. Mọi thứ đều hoạt động tốt.
Trong 4 năm, đội máy chủ đã tăng gấp 100 lần, lên tới 5000. Các mạng biệt lập đầu tiên xuất hiện - dàn dựng: chúng không thể đi vào sản xuất và thường có những thứ chạy ở đó có thể gây nguy hiểm.
Mô hình mạng năm 2014
Theo quán tính, chúng tôi đã sử dụng cùng một phần cứng và tất cả công việc được thực hiện trên các Vlan riêng biệt: ACL được ghi vào các Vlan, cho phép hoặc từ chối một số loại kết nối.
Năm 2016, số lượng máy chủ lên tới 8000. Wargaming tiếp thu các studio khác và các mạng lưới liên kết bổ sung xuất hiện. Chúng có vẻ là của chúng ta, nhưng không hẳn: VLAN thường không hoạt động với đối tác, bạn phải sử dụng VPN với VRF, việc cách ly trở nên phức tạp hơn. Hỗn hợp cách nhiệt ACL tăng lên.
Mô hình mạng năm 2016
Đến đầu năm 2018, đội máy đã tăng lên 16 chiếc, có 000 phân khúc, phần còn lại chúng tôi không tính, bao gồm cả những phân khúc đã đóng trong đó lưu trữ dữ liệu tài chính. Mạng container (Kubernetes), DevOps, mạng đám mây được kết nối qua VPN, chẳng hạn như từ IVS, đã xuất hiện. Có rất nhiều quy tắc - thật đau đớn.
Mô hình mạng và các phương pháp cách ly năm 2018.
Để cách ly, chúng tôi đã sử dụng: Vlan với ACL trên L2, VRF với ACL trên L3, VPN và nhiều hơn nữa. Quá nhiều.
Vấn đề
Mọi người đều sống với ACL và Vlan. Chuyện gì vậy? Câu hỏi này sẽ được Harold trả lời, giấu đi nỗi đau.
Có rất nhiều vấn đề, nhưng có năm vấn đề lớn.
- Tăng giá hình học cho các quy tắc mới. Mỗi quy tắc mới mất nhiều thời gian hơn để thêm vào so với quy tắc trước đó vì trước tiên cần phải xem liệu đã có quy tắc như vậy chưa.
- Không có tường lửa bên trong phân đoạn. Các phân đoạn bằng cách nào đó đã bị tách biệt khỏi nhau và bên trong không có đủ tài nguyên.
- Các quy tắc đã được áp dụng trong một thời gian dài. Người vận hành có thể viết một quy tắc địa phương bằng tay trong một giờ. Toàn cầu mất vài ngày.
- Khó khăn về quy định kiểm toán. Chính xác hơn thì điều đó là không thể. Các quy tắc đầu tiên được viết lại vào năm 2010 và hầu hết các tác giả của chúng không còn làm việc cho công ty nữa.
- Mức độ kiểm soát cơ sở hạ tầng thấp. Đây là vấn đề chính - chúng tôi không biết rõ chuyện gì đang xảy ra ở đất nước mình.
Đây là diện mạo của một kỹ sư mạng vào năm 2018 khi anh ấy nghe thấy: “Cần thêm một số ACL”.
Giải pháp
Vào đầu năm 2018, người ta đã quyết định phải làm điều gì đó về vấn đề này.
Giá của sự tích hợp không ngừng tăng lên. Điểm khởi đầu là các trung tâm dữ liệu lớn đã ngừng hỗ trợ các Vlan và ACL bị cô lập do các thiết bị hết bộ nhớ.
Giải pháp: chúng tôi loại bỏ yếu tố con người và tự động hóa việc cung cấp quyền truy cập ở mức tối đa.
Các quy định mới phải mất một thời gian dài để áp dụng. Giải pháp: tăng tốc độ áp dụng các quy tắc, làm cho nó phân tán và song song. Điều này đòi hỏi một hệ thống phân tán để các quy tắc được tự phân phối mà không cần rsync hoặc SFTP tới hàng nghìn hệ thống.
Không có tường lửa bên trong các phân đoạn. Tường lửa trong các phân đoạn bắt đầu đến với chúng tôi khi các dịch vụ khác nhau xuất hiện trong cùng một mạng. Giải pháp: sử dụng tường lửa ở cấp máy chủ - tường lửa dựa trên máy chủ. Hầu như mọi nơi chúng tôi có Linux và mọi nơi chúng tôi có iptables, đây không phải là vấn đề.
Khó khăn về quy định kiểm toán Giải pháp: Giữ tất cả các quy tắc ở một nơi để xem xét và quản lý, nhờ đó chúng tôi có thể kiểm tra mọi thứ.
Mức độ kiểm soát cơ sở hạ tầng thấp. Giải pháp: kiểm kê tất cả các dịch vụ và quyền truy cập giữa chúng.
Đây là một quy trình hành chính hơn là một quy trình kỹ thuật. Đôi khi chúng tôi có 200-300 bản phát hành mới mỗi tuần, đặc biệt là trong các đợt khuyến mãi và ngày lễ. Hơn nữa, điều này chỉ dành cho một nhóm DevOps của chúng tôi. Với rất nhiều bản phát hành, không thể biết được những cổng, IP và tích hợp nào là cần thiết. Do đó, chúng tôi cần những người quản lý dịch vụ được đào tạo đặc biệt, những người đã hỏi các nhóm: “Dù sao thì có gì và tại sao các bạn lại nhắc đến nó?”
Sau mọi thứ chúng tôi tung ra, một kỹ sư mạng vào năm 2019 bắt đầu trông như thế này.
Lãnh sự
Chúng tôi quyết định rằng chúng tôi sẽ đưa mọi thứ mà chúng tôi tìm thấy với sự trợ giúp của người quản lý dịch vụ vào Consul và từ đó chúng tôi sẽ viết các quy tắc iptables.
Làm thế nào chúng tôi quyết định làm điều này?
- Chúng tôi sẽ thu thập tất cả các dịch vụ, mạng và người dùng.
- Hãy tạo các quy tắc iptables dựa trên chúng.
- Chúng tôi tự động hóa việc kiểm soát.
- ....
- LỢI NHUẬN.
Consul không phải là một API từ xa, nó có thể chạy trên mọi nút và ghi vào iptables. Tất cả những gì còn lại là đưa ra những điều khiển tự động sẽ loại bỏ những thứ không cần thiết và hầu hết các vấn đề sẽ được giải quyết! Chúng tôi sẽ giải quyết phần còn lại khi chúng tôi đi.
Tại sao lãnh sự?
Đã chứng minh bản thân tốt. Trong năm 2014-15, chúng tôi đã sử dụng nó làm phần phụ trợ cho Vault, nơi chúng tôi lưu trữ mật khẩu.
Không mất dữ liệu. Trong suốt thời gian sử dụng, Consul không hề bị mất dữ liệu dù một tai nạn nào. Đây là một điểm cộng rất lớn cho một hệ thống quản lý tường lửa.
Kết nối P2P đẩy nhanh sự lan truyền của thay đổi. Với P2P, mọi thay đổi đều diễn ra nhanh chóng, không cần phải chờ đợi hàng giờ.
API REST tiện lợi. Chúng tôi cũng đã xem xét Apache ZooKeeper, nhưng nó không có API REST, vì vậy bạn sẽ phải cài đặt nạng.
Hoạt động như cả Key Vault (KV) và Thư mục (Khám phá dịch vụ). Bạn có thể lưu trữ các dịch vụ, danh mục và trung tâm dữ liệu cùng một lúc. Điều này thuận tiện không chỉ cho chúng tôi mà còn cho các nhóm lân cận, bởi vì khi xây dựng một dịch vụ toàn cầu, chúng tôi nghĩ lớn.
Được viết bằng cờ vây, một phần của Wargaming. Chúng tôi yêu thích ngôn ngữ này, chúng tôi có nhiều nhà phát triển Go.
Hệ thống ACL mạnh mẽ. Trong Consul, bạn có thể sử dụng ACL để kiểm soát ai viết gì. Chúng tôi đảm bảo rằng các quy tắc tường lửa sẽ không trùng lặp với bất kỳ quy tắc nào khác và chúng tôi sẽ không gặp vấn đề gì với điều này.
Nhưng Lãnh sự cũng có nhược điểm của nó.
- Không mở rộng quy mô trong trung tâm dữ liệu trừ khi bạn có phiên bản dành cho doanh nghiệp. Nó chỉ có thể mở rộng theo liên đoàn.
- Phụ thuộc rất nhiều vào chất lượng mạng và tải máy chủ. Lãnh sự sẽ không hoạt động bình thường như một máy chủ trên một máy chủ bận rộn nếu có bất kỳ độ trễ nào trên mạng, chẳng hạn như tốc độ không đồng đều. Điều này là do các kết nối P2P và mô hình phân phối cập nhật.
- Khó khăn trong việc giám sát tính khả dụng. Với tư cách Lãnh sự, anh ấy có thể nói rằng mọi thứ đều ổn, nhưng anh ấy đã chết từ lâu rồi.
Chúng tôi đã giải quyết được hầu hết những vấn đề này khi sử dụng Consul, đó là lý do tại sao chúng tôi chọn nó. Công ty có kế hoạch cho một chương trình phụ trợ thay thế, nhưng chúng tôi đã học được cách giải quyết các vấn đề và hiện đang sống với Lãnh sự.
Lãnh sự hoạt động như thế nào
Chúng tôi sẽ cài đặt ba đến năm máy chủ trong một trung tâm dữ liệu có điều kiện. Một hoặc hai máy chủ sẽ không hoạt động: chúng sẽ không thể tổ chức đại biểu và quyết định ai đúng ai sai khi dữ liệu không khớp. Nhiều hơn năm không có ý nghĩa gì, năng suất sẽ giảm.
Máy khách kết nối với máy chủ theo thứ tự bất kỳ: cùng một tác nhân, chỉ có cờ server = false.
Sau đó, khách hàng nhận được danh sách các kết nối P2P và xây dựng kết nối với nhau.
Ở cấp độ toàn cầu, chúng tôi kết nối một số trung tâm dữ liệu. Họ cũng kết nối P2P và liên lạc.
Khi chúng tôi muốn lấy dữ liệu từ một trung tâm dữ liệu khác, yêu cầu sẽ chuyển từ máy chủ này sang máy chủ khác. Sơ đồ này được gọi là Giao thức Serf. Giao thức Serf, giống như Consul, được phát triển bởi HashiCorp.
Một số thông tin quan trọng về Lãnh sự
Lãnh sự có tài liệu mô tả cách thức hoạt động. Tôi sẽ chỉ đưa ra những sự thật được chọn lọc đáng để biết.
Máy chủ lãnh sự chọn một bậc thầy trong số các cử tri. Lãnh sự chọn một máy chủ chính từ danh sách máy chủ cho mỗi trung tâm dữ liệu và tất cả các yêu cầu chỉ được gửi đến máy chủ đó, bất kể số lượng máy chủ. Việc đóng băng chính không dẫn đến bầu cử lại. Nếu chủ không được chọn, các yêu cầu sẽ không được phục vụ bởi bất kỳ ai.
Bạn có muốn chia tỷ lệ theo chiều ngang không? Xin lỗi, không.
Yêu cầu tới một trung tâm dữ liệu khác sẽ đi từ chủ này sang chủ khác, bất kể nó đến máy chủ nào. Bản gốc đã chọn sẽ nhận được 100% tải, ngoại trừ tải đối với các yêu cầu chuyển tiếp. Tất cả các máy chủ trong trung tâm dữ liệu đều có bản sao dữ liệu cập nhật nhưng chỉ có một máy chủ phản hồi.
Cách duy nhất để mở rộng quy mô là bật chế độ cũ trên máy khách.
Ở chế độ cũ, bạn có thể phản hồi mà không cần số đại biểu. Đây là chế độ trong đó chúng tôi từ bỏ tính nhất quán của dữ liệu nhưng đọc nhanh hơn bình thường một chút và bất kỳ máy chủ nào cũng phản hồi. Đương nhiên, chỉ ghi âm thông qua master.
Lãnh sự không sao chép dữ liệu giữa các trung tâm dữ liệu. Khi một liên đoàn được tập hợp, mỗi máy chủ sẽ chỉ có dữ liệu riêng. Đối với những người khác, anh ấy luôn hướng về người khác.
Tính nguyên tử của hoạt động không được đảm bảo bên ngoài giao dịch. Hãy nhớ rằng bạn không phải là người duy nhất có thể thay đổi mọi thứ. Nếu bạn muốn nó khác đi, hãy thực hiện giao dịch bằng khóa.
Hoạt động chặn không đảm bảo khóa. Yêu cầu đi từ chủ này sang chủ khác chứ không phải trực tiếp, vì vậy không có gì đảm bảo rằng việc chặn sẽ hoạt động khi bạn chặn, chẳng hạn như ở một trung tâm dữ liệu khác.
ACL cũng không đảm bảo quyền truy cập (trong nhiều trường hợp). ACL có thể không hoạt động vì nó được lưu trữ trong một trung tâm dữ liệu liên kết - trong trung tâm dữ liệu ACL (DC chính). Nếu DC không trả lời bạn thì ACL sẽ không hoạt động.
Một bậc thầy bị đóng băng sẽ khiến toàn bộ liên đoàn đóng băng. Ví dụ: có 10 trung tâm dữ liệu trong một liên đoàn, một trung tâm có mạng kém và một trung tâm chính bị lỗi. Mọi người giao tiếp với anh ta sẽ đóng băng trong một vòng tròn: có một yêu cầu, không có câu trả lời cho nó, sợi dây bị treo. Không có cách nào để biết khi nào điều này sẽ xảy ra, chỉ trong một hoặc hai giờ nữa toàn bộ liên đoàn sẽ sụp đổ. Bạn không thể làm gì về nó.
Tình trạng, số đại biểu và cuộc bầu cử được xử lý bởi một chủ đề riêng biệt. Việc bầu cử lại sẽ không xảy ra, trạng thái sẽ không hiển thị bất cứ điều gì. Bạn nghĩ rằng bạn có một Lãnh sự trực tiếp, bạn hỏi, và không có gì xảy ra - không có câu trả lời. Đồng thời, trạng thái cho thấy mọi thứ đều ổn.
Chúng tôi đã gặp phải sự cố này và phải xây dựng lại các phần cụ thể của trung tâm dữ liệu để tránh sự cố này.
Phiên bản doanh nghiệp Consul Enterprise không có một số nhược điểm trên. Nó có nhiều chức năng hữu ích: lựa chọn cử tri, phân phối, nhân rộng. Chỉ có một "nhưng" - hệ thống cấp phép cho hệ thống phân tán rất tốn kém.
Cuộc sống hack: rm -rf /var/lib/consul - một phương thuốc chữa lành mọi bệnh tật của tác nhân. Nếu có điều gì đó không hiệu quả với bạn, chỉ cần xóa dữ liệu của bạn và tải dữ liệu xuống từ một bản sao. Nhiều khả năng, Lãnh sự sẽ làm việc.
BEFW
Bây giờ hãy nói về những gì chúng tôi đã thêm vào Consul.
là từ viết tắt của BackEndFgiận dữWtất cả. Tôi đã phải đặt tên cho sản phẩm bằng cách nào đó khi tạo kho lưu trữ để đưa các cam kết thử nghiệm đầu tiên vào đó. Tên này vẫn còn.
Mẫu quy tắc
Các quy tắc được viết bằng cú pháp iptables.
- -N BEFW
- -P ĐẦU VÀO THẢ
- -A INPUT -m trạng thái—trạng thái LIÊN QUAN, THÀNH LẬP -j CHẤP NHẬN
- - ĐẦU VÀO -i lo -j CHẤP NHẬN
- -A ĐẦU VÀO -j BEFW
Mọi thứ đều đi vào chuỗi BEFW, ngoại trừ ESTABLISHED, RELATED và máy chủ cục bộ. Mẫu có thể là bất cứ thứ gì, đây chỉ là một ví dụ.
BEFW hữu ích như thế nào?
Dịch vụ
Chúng tôi có một dịch vụ, nó luôn có một cổng, một nút để chạy trên đó. Từ nút của chúng tôi, chúng tôi có thể hỏi đại lý tại địa phương và biết rằng chúng tôi có một số loại dịch vụ. Bạn cũng có thể đặt thẻ.
Bất kỳ dịch vụ nào đang chạy và được đăng ký với Consul đều trở thành quy tắc iptables. Chúng tôi có SSH - mở cổng 22. Tập lệnh Bash rất đơn giản: cuộn tròn và iptables, không cần gì khác.
Khách hàng
Làm thế nào để mở quyền truy cập không phải cho tất cả mọi người mà có chọn lọc? Thêm danh sách IP vào bộ lưu trữ KV theo tên dịch vụ.
Ví dụ: chúng tôi muốn mọi người trên mạng thứ mười có thể truy cập dịch vụ SSH_TCP_22. Thêm một trường TTL nhỏ? và bây giờ chúng tôi có giấy phép tạm thời, chẳng hạn như trong một ngày.
Truy cập
Chúng tôi kết nối dịch vụ và khách hàng: chúng tôi có một dịch vụ, bộ lưu trữ KV sẵn sàng cho từng dịch vụ. Bây giờ chúng tôi cấp quyền truy cập không phải cho tất cả mọi người mà có chọn lọc.
Nhóm
Nếu mỗi lần viết hàng nghìn IP để truy cập thì chúng ta sẽ cảm thấy mệt mỏi. Hãy đưa ra các nhóm - một tập hợp con riêng biệt trong KV. Hãy gọi nó là Bí danh (hoặc nhóm) và lưu trữ các nhóm ở đó theo nguyên tắc tương tự.
Hãy kết nối: bây giờ chúng ta có thể mở SSH không dành riêng cho P2P mà cho cả một nhóm hoặc một số nhóm. Tương tự như vậy, có TTL - bạn có thể thêm vào một nhóm và tạm thời xóa khỏi nhóm.
Tích hợp
Vấn đề của chúng tôi là yếu tố con người và tự động hóa. Cho đến nay chúng tôi đã giải quyết nó theo cách này.
Chúng tôi làm việc với Puppet và chuyển mọi thứ liên quan đến hệ thống (mã ứng dụng) cho họ. Puppetdb (PostgreSQL thông thường) lưu trữ danh sách các dịch vụ đang chạy ở đó, chúng có thể được tìm thấy theo loại tài nguyên. Ở đó bạn có thể tìm ra ai đang nộp đơn ở đâu. Chúng tôi cũng có hệ thống yêu cầu kéo và yêu cầu hợp nhất cho việc này.
Chúng tôi đã viết befw-sync, một giải pháp đơn giản giúp truyền dữ liệu. Đầu tiên, cookie đồng bộ được truy cập bởi con rốidb. API HTTP được định cấu hình ở đó: chúng tôi yêu cầu những dịch vụ chúng tôi có, những gì cần phải làm. Sau đó, họ đưa ra yêu cầu với Lãnh sự.
Có tích hợp không? Có: họ đã viết ra các quy tắc và cho phép các Yêu cầu Kéo được chấp nhận. Bạn có cần một cổng nhất định hoặc thêm máy chủ vào một nhóm nào đó không? Kéo Yêu cầu, xem xét - không còn nữa “Tìm 200 ACL khác và cố gắng làm điều gì đó về nó.”
Tối ưu hóa
Ping localhost với chuỗi quy tắc trống mất 0,075 mili giây.
Hãy thêm 10 địa chỉ iptables vào chuỗi này. Kết quả là ping sẽ tăng lên gấp 000 lần: iptables hoàn toàn tuyến tính, việc xử lý từng địa chỉ sẽ mất một chút thời gian.
Đối với tường lửa nơi chúng tôi di chuyển hàng nghìn ACL, chúng tôi có rất nhiều quy tắc và điều này gây ra độ trễ. Điều này không tốt cho các giao thức chơi game.
Nhưng nếu chúng ta đặt 10 địa chỉ trong ipset Ping thậm chí sẽ giảm.
Vấn đề là “O” (độ phức tạp của thuật toán) đối với ipset luôn bằng 1, bất kể có bao nhiêu quy tắc. Đúng, có một hạn chế - không thể có nhiều hơn các quy tắc 65535. Hiện tại, chúng tôi đang làm việc với điều này: bạn có thể kết hợp chúng, mở rộng chúng, tạo hai ipset thành một.
Lưu trữ
Sự tiếp tục hợp lý của quá trình lặp lại là lưu trữ thông tin về các máy khách cho dịch vụ trong ipset.
Bây giờ chúng tôi có cùng một SSH và chúng tôi không viết 100 IP cùng một lúc mà đặt tên của ipset mà chúng tôi cần liên lạc và quy tắc sau DROP. Nó có thể được chuyển đổi thành một quy tắc “Ai không ở đây, DROP”, nhưng rõ ràng hơn.
Bây giờ chúng tôi có các quy tắc và bộ. Nhiệm vụ chính là tạo một bộ trước khi viết quy tắc, vì nếu không iptables sẽ không viết quy tắc.
Đề án chung
Ở dạng sơ đồ, mọi thứ tôi nói đều trông như thế này.
Chúng tôi cam kết với Puppet mọi thứ đều gửi về hosting, dịch vụ ở đây, ipset ở đó, ai không đăng ký ở đó thì không được phép.
Cho phép từ chối
Để nhanh chóng cứu thế giới hoặc nhanh chóng vô hiệu hóa ai đó, khi bắt đầu tất cả các chuỗi, chúng tôi đã tạo hai ipset: rules_allow и rules_deny. Làm thế nào nó hoạt động?
Ví dụ: ai đó đang tạo tải trên Web của chúng tôi bằng bot. Trước đây, bạn phải tìm IP của anh ta từ nhật ký, đưa nó cho các kỹ sư mạng để họ tìm ra nguồn lưu lượng và cấm anh ta. Giờ nó trông khác hẳn.
Chúng tôi gửi nó cho Lãnh sự, đợi 2,5 giây và thế là xong. Vì Consul phân phối nhanh chóng thông qua P2P nên nó hoạt động ở mọi nơi, mọi nơi trên thế giới.
Có lần tôi bằng cách nào đó đã dừng hoàn toàn WOT do lỗi với tường lửa. rules_allow - đây là bảo hiểm của chúng tôi chống lại những trường hợp như vậy. Nếu chúng tôi mắc lỗi ở đâu đó với tường lửa, có thứ gì đó bị chặn ở đâu đó, chúng tôi luôn có thể gửi một điều kiện 0.0/0để nhanh chóng thu thập mọi thứ. Sau này chúng tôi sẽ sửa chữa mọi thứ bằng tay.
Bộ khác
Bạn có thể thêm bất kỳ bộ nào khác vào không gian $IPSETS$.
Để làm gì? Ví dụ, đôi khi ai đó cần ipset để mô phỏng việc tắt một phần nào đó của cụm. Bất cứ ai cũng có thể mang theo bất kỳ bộ nào, đặt tên cho chúng và chúng sẽ được Lãnh sự nhận. Đồng thời, các bộ có thể tham gia vào các quy tắc iptables hoặc hoạt động như một nhóm NOOP: Tính nhất quán sẽ được duy trì bởi daemon.
Thành viên
Trước đây, nó như thế này: người dùng kết nối với mạng và nhận thông số qua miền. Trước sự ra đời của tường lửa thế hệ mới, Cisco không biết làm thế nào để hiểu được người dùng ở đâu và IP ở đâu. Do đó, quyền truy cập chỉ được cấp thông qua tên máy chủ của máy.
Chúng tôi đã làm gì? Chúng tôi bị mắc kẹt tại thời điểm chúng tôi nhận được địa chỉ. Thông thường đây là dot1x, Wi-Fi hoặc VPN - mọi thứ đều thông qua RADIUS. Đối với mỗi người dùng, chúng tôi tạo một nhóm theo tên người dùng và đặt một IP vào đó với TTL bằng dhcp.lease của nó - ngay sau khi nó hết hạn, quy tắc sẽ biến mất.
Bây giờ chúng tôi có thể mở quyền truy cập vào các dịch vụ, giống như các nhóm khác, theo tên người dùng. Chúng tôi đã loại bỏ nỗi đau của tên máy chủ khi chúng thay đổi và chúng tôi đã trút bỏ gánh nặng cho các kỹ sư mạng vì họ không còn cần đến Cisco nữa. Bây giờ các kỹ sư tự đăng ký quyền truy cập trên máy chủ của họ.
Cách nhiệt
Đồng thời, chúng tôi bắt đầu tháo dỡ lớp cách nhiệt. Các nhà quản lý dịch vụ đã kiểm kê và chúng tôi đã phân tích tất cả các mạng của mình. Hãy chia chúng thành các nhóm giống nhau và trên các máy chủ cần thiết, các nhóm đã được thêm vào, chẳng hạn như để từ chối. Bây giờ, sự cô lập dàn dựng tương tự kết thúc trong quy tắc_deny của quá trình sản xuất, nhưng không phải trong chính quá trình sản xuất.
Sơ đồ này hoạt động nhanh chóng và đơn giản: chúng tôi xóa tất cả ACL khỏi máy chủ, dỡ bỏ phần cứng và giảm số lượng Vlan bị cô lập.
Kiểm soát tính toàn vẹn
Trước đây, chúng tôi có một trình kích hoạt đặc biệt báo cáo khi ai đó thay đổi quy tắc tường lửa theo cách thủ công. Tôi đang viết một bài viết dối trá khổng lồ để kiểm tra các quy tắc tường lửa, việc này thật khó khăn. Tính toàn vẹn hiện được kiểm soát bởi BEFW. Anh ấy nhiệt tình đảm bảo rằng các quy tắc anh ấy đưa ra không thay đổi. Nếu ai đó thay đổi quy tắc tường lửa, mọi thứ sẽ thay đổi trở lại. “Tôi nhanh chóng thiết lập proxy để có thể làm việc tại nhà”—không còn lựa chọn nào như vậy nữa.
BEFW kiểm soát ipset từ các dịch vụ và liệt kê trong befw.conf, các quy tắc dịch vụ trong chuỗi BEFW. Nhưng nó không giám sát các chuỗi, quy tắc khác và các ipset khác.
Bảo vệ va chạm
BEFW luôn lưu trữ trực tiếp trạng thái tốt đã biết cuối cùng trong cấu trúc nhị phân state.bin. Nếu có sự cố xảy ra, nó luôn quay trở lại trạng thái này.bin.
Đây là bảo hiểm chống lại hoạt động Lãnh sự không ổn định, khi nó không gửi dữ liệu hoặc ai đó đã mắc lỗi và sử dụng các quy tắc không thể áp dụng được. Để đảm bảo rằng chúng tôi không bị thiếu tường lửa, BEFW sẽ quay lại trạng thái mới nhất nếu xảy ra lỗi ở bất kỳ giai đoạn nào.
Trong những tình huống quan trọng, đây là sự đảm bảo rằng chúng tôi sẽ có một bức tường lửa hoạt động. Chúng tôi mở tất cả các mạng xám với hy vọng quản trị viên sẽ đến và sửa chữa. Một ngày nào đó tôi sẽ đưa cái này vào cấu hình, nhưng bây giờ chúng ta chỉ có ba mạng màu xám: 10/8, 172/12 và 192.168/16. Trong Lãnh sự của chúng tôi, đây là một tính năng quan trọng giúp chúng tôi phát triển hơn nữa.
Demo: trong khi báo cáo, Ivan trình diễn chế độ demo của BEFW. Xem trình diễn dễ dàng hơn . Mã nguồn demo có sẵn .
Cạm bẫy
Tôi sẽ kể cho bạn nghe về những lỗi chúng tôi gặp phải.
ipset thêm bộ 0.0.0.0/0. Điều gì xảy ra nếu bạn thêm 0.0.0.0/0 vào ipset? Tất cả các IP sẽ được thêm vào? Truy cập Internet sẽ có sẵn?
Không, chúng tôi sẽ gặp một lỗi khiến chúng tôi phải ngừng hoạt động trong hai giờ. Hơn nữa, lỗi này đã không hoạt động kể từ năm 2016, nó nằm ở RedHat Bugzilla với số hiệu #1297092 và chúng tôi đã vô tình tìm thấy nó - từ báo cáo của nhà phát triển.
Hiện nay quy định nghiêm ngặt tại BEFW là 0.0.0.0/0 chuyển thành hai địa chỉ: 0.0.0.0/1 и 128.0.0.0/1.
bộ khôi phục ipset < tập tin. ipset làm gì khi bạn bảo nó restore? Bạn có nghĩ nó hoạt động giống như iptables không? Nó sẽ phục hồi dữ liệu?
Không có gì giống như vậy - nó hợp nhất và các địa chỉ cũ không đi đâu cả, bạn không chặn quyền truy cập.
Chúng tôi đã tìm thấy lỗi khi thử nghiệm cách ly. Bây giờ có một hệ thống khá phức tạp - thay vì restore tổ chức create temp, sau đó restore flush temp и restore temp. Khi kết thúc trao đổi: đối với tính nguyên tử, bởi vì nếu bạn thực hiện việc đó trước flush và tại thời điểm này một số gói đến, nó sẽ bị loại bỏ và sẽ xảy ra sự cố. Vì vậy, có một chút ma thuật đen ở đó.
lãnh sự kv get -datacenter=other. Như tôi đã nói, chúng tôi nghĩ rằng chúng tôi đang yêu cầu một số dữ liệu, nhưng chúng tôi sẽ nhận được dữ liệu hoặc sẽ gặp lỗi. Chúng tôi có thể thực hiện việc này thông qua Lãnh sự tại địa phương, nhưng trong trường hợp này cả hai đều sẽ bị treo.
Ứng dụng khách Lãnh sự địa phương là một trình bao bọc trên API HTTP. Nhưng nó chỉ bị treo và không phản hồi với Ctrl+C hoặc Ctrl+Z hoặc bất cứ thứ gì mà thôi kill -9 trong bảng điều khiển tiếp theo. Chúng tôi gặp phải điều này khi chúng tôi đang xây dựng một cụm lớn. Nhưng chúng tôi chưa có giải pháp, chúng tôi đang chuẩn bị sửa lỗi này trong Consul.
Lãnh đạo lãnh sự không trả lời. Chủ nhân của chúng tôi trong trung tâm dữ liệu không phản hồi, chúng tôi nghĩ: "Có lẽ thuật toán chọn lại bây giờ sẽ hoạt động?"
Không, nó sẽ không hiệu quả và việc giám sát sẽ không hiển thị bất cứ điều gì: Lãnh sự sẽ nói rằng có một chỉ số cam kết, một nhà lãnh đạo đã được tìm thấy, mọi thứ đều ổn.
Chúng ta xử lý việc này thế nào đây? service consul restart bằng cron mỗi giờ. Nếu bạn có 50 máy chủ thì không có vấn đề gì lớn. Khi có 16 người trong số họ, bạn sẽ hiểu nó hoạt động như thế nào.
Kết luận
Kết quả là chúng tôi đã nhận được những lợi ích sau:
- Bảo hiểm 100% cho tất cả các máy Linux.
- Tốc độ
- Tự động hóa.
- Chúng tôi đã giải phóng các kỹ sư phần cứng và mạng khỏi chế độ nô lệ.
- Khả năng tích hợp đã xuất hiện gần như vô hạn: ngay cả với Kubernetes, ngay cả với Ansible, thậm chí với Python.
Nhược điểm: Lãnh sự, mà bây giờ chúng ta phải sống, và cái giá phải trả cho sai sót rất cao. Ví dụ: một lần vào lúc 6 giờ chiều (giờ vàng ở Nga), tôi đang chỉnh sửa nội dung nào đó trong danh sách các mạng. Lúc đó chúng tôi chỉ đang xây dựng vật liệu cách nhiệt tại BEFW. Tôi đã mắc lỗi ở đâu đó, có vẻ như tôi đã chỉ sai mặt nạ, nhưng mọi thứ đã diễn ra trong hai giây. Đèn giám sát sáng lên, người trực hỗ trợ chạy tới: “Chúng tôi có tất cả!” Người đứng đầu bộ phận tái mặt khi giải thích cho doanh nghiệp lý do tại sao điều này lại xảy ra.
Chi phí xảy ra sai sót cao đến mức chúng tôi phải đưa ra quy trình phòng ngừa phức tạp của riêng mình. Nếu bạn triển khai điều này trên một địa điểm sản xuất lớn, bạn không cần phải cấp mã thông báo chính cho Lãnh sự cho mọi người. Điều này sẽ kết thúc tồi tệ.
Chi phí Tôi đã viết mã trong 400 giờ một mình. Nhóm 4 người của tôi dành 10 giờ mỗi tháng để hỗ trợ mọi người. So với giá của bất kỳ tường lửa thế hệ mới nào, nó hoàn toàn miễn phí.
Kế hoạch. Kế hoạch dài hạn là tìm phương tiện di chuyển thay thế hoặc bổ sung cho Lãnh sự. Có lẽ đó sẽ là Kafka hoặc thứ gì đó tương tự. Nhưng trong những năm tới chúng tôi sẽ sống trên Lãnh sự.
Kế hoạch trước mắt: tích hợp với Fail2ban, với tính năng giám sát, với nftables, có thể với các bản phân phối, số liệu khác, giám sát nâng cao, tối ưu hóa. Hỗ trợ Kubernetes cũng nằm ở đâu đó trong kế hoạch, bởi vì hiện tại chúng tôi có một số cụm và mong muốn.
Thông tin thêm từ các kế hoạch:
- tìm kiếm sự bất thường trong giao thông;
- quản lý bản đồ mạng;
- Hỗ trợ Kubernetes;
- lắp ráp trọn gói cho toàn bộ hệ thống;
- Giao diện người dùng web.
Chúng tôi không ngừng nỗ lực mở rộng cấu hình, tăng số liệu và tối ưu hóa.
Tham gia dự án. Dự án hóa ra rất thú vị, nhưng thật không may, nó vẫn là dự án của một người. Đến và cố gắng làm điều gì đó: cam kết, kiểm tra, đề xuất điều gì đó, đưa ra đánh giá của bạn.
Trong khi đó chúng tôi đang chuẩn bị cho , sẽ diễn ra vào ngày 6 và 7 tháng XNUMX tại St. Petersburg và chúng tôi mời các nhà phát triển hệ thống tải cao . Những diễn giả có kinh nghiệm đã biết phải làm gì, nhưng đối với những người mới bắt đầu diễn thuyết thì ít nhất chúng tôi khuyên bạn nên . Tham gia hội nghị với tư cách là diễn giả có một số lợi thế. Bạn có thể đọc cái nào, ví dụ, ở cuối .
Nguồn: www.habr.com