• If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.
Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.

Announcement

Collapse
No announcement yet.

Firewall DMZ

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Firewall DMZ

    Cũng giống như nhiều thuật ngữ tin học khác được vay mượn từ thế giới thực, DMZ cũng là một thuật ngữ được dùng trong lĩnh vực bảo mật mạng máy tính. Vậy thì ý nghĩa và mục đích của từ DMZ trong tin học có giống với từ DMZ trong quân sự hay không?

    Giới thiệu

    Về mặt địa lý và con người, thì DMZ (Demilitarized Zone – vùng phi quân sự) là một khu vực mà tại đó sự hiện diện của các lực lượng quân đội (gồm binh lính, vũ khí, đạn dược…) cũng như các hoạt động quân sự (như do thám, tập trận, đánh nhau…) đều không được cho phép. Vì vậy, DMZ được coi như là một vùng ranh giới chia tách hai bên mà là thù địch của nhau và vùng DMZ thường được tạo nên sau những hiệp ước hòa bình, những thỏa thuận đình chiến. Trong thế giới thực, dải đất cắt ngang bán đảo Triều Tiên và phân tách bán đảo này ra thành hai nước là Hàn Quốc và Triều Tiên chính là một ví dụ về DMZ. Còn trong lịch sử chiến tranh Việt Nam thì sông Bến Hải chia tách hai miền nam Bắc cũng là một ví dụ khác về DMZ. Cũng giống như nhiều thuật ngữ tin học khác được vay mượn từ thế giới thực, DMZ cũng là một thuật ngữ được dùng trong lĩnh vực bảo mật mạng máy tính. Vậy thì ý nghĩa và mục đích của từ DMZ trong tin học có giống với từ DMZ
    trong quân sự hay không?

    Trước khi đi vào giải thích DMZ là gì cũng như tác dụng của nó thì tôi xin đưa ra một tình huống như thế này. Hệ thống mạng nội bộ (internal network) của một tổ chức thường bao gồm các server cung cấp các dịch vụ cơ bản như: Directory Service (Active Directory, OpenLDAP…), DNS, DHCP, File/Print Sharing, Web, Mail, FTP. Trong đó thì các server Web, Mail, FTP thường phải cung cấp các dịch vụ của chúng cho cả những người dùng nằm bên trong lẫn bên ngoài mạng nội bộ của tổ chức. Nếu trường hợp bạn đặt tất cả các server này nằm trong cùng một lớp mạng với các máy trạm của người dùng trong tổ chức thì sẽ như thế nào nếu hacker từ mạng bên ngoài (external network – ví dụ như Internet) kiểm soát được (các) “public server” như Web, Mail, FTP? Rất có thể hacker sẽ dựa vào các server đã bị chiếm đoạt này để đánh vào các server khác (như DNS, DHCP, Directory Service…) cũng như thâm nhập sâu hơn vào các máy trạm bên trong. Thế nên ở đây, ta cần có một giải pháp nào đó để hạn chế khả năng mạng internal bị tổn thương khi các public server trên bị tấn công. Và DMZ là một câu trả lời cho vấn đề này. DMZ là một mạng tách biệt với mạng internal vì DMZ sử dụng đường mạng (hoặc có subnet) khác với mạng internal. Và các server như Web, Mail, FTP, VoIP… là các dịch vụ tổ chức mong muốn người dùng có thể truy cập và sử dụng thông qua các mạng ngoài như Internet được đặt trong vùng DMZ. Còn các server phục vụ cho các mục đích nội bộ như DNS, DHCP, File/Print… vẫn được đặt trong vùng internal. Giữa DMZ và mạng external ta có thể đặt một firewall để cho phép các kết nối từ external chỉ đến được DMZ mà thôi. Còn giữa mạng internal và DMZ ta có thể đặt thêm một firewall khác để kiểm soát các lưu lượng từ DMZ đi vào internal. Như vậy, cũng giống với vùng DMZ trong quân sự, DMZ ở đây đã tạo ra sự phân tách giữa hai bên đối nghịch nhau: mạng internal và mạng external. Và có thể nói rằng DMZ đã bổ
    sung thêm một lớp bảo vệ cách ly cho mạng internal khi mà hacker từ mạng ngoài chỉ có thể tiếp cận tới các máy nằm trong DMZ mà thôi.

    Nếu bạn nghĩ mạng external như là “untrusted network” và mạng internal như là “trusted network” thì có thể coi DMZ như là mạng “nửa tin cậy, nửa không tin cậy” (semi-trusted). Nó không được an toàn như LAN nhưng do nó nằm sau một firewall nên nó an toàn hơn Internet. Hoặc bạn cũng có thể nghĩ về DMZ như là một “liaison network” (mạng có quan hệ bất chính :-p) vì nó có thể liên lạc với cả hai mạng Internet và LAN trong khi nằm giữa hai mạng này như được thể hiện trong hình trên. Nhưng không giống như sự yên ả, không có giao tranh mà ta có thể tìm thấy ở vùng DMZ ngoài đời thực, mạng DMZ ở đây thực sự ẩn chứa rất nhiều rủi ro do các mối đe dọa từ phía ngoài mang lại. Điển hình như việc hacker có thể sử dụng hình thức tấn công từ chối dịch vụ (DoS/DDoS) nhắm vào các server trong DMZ để làm gián đoạn hoặc dập tắt khả năng đáp ứng yêu cầu dịch vụ của các server này cho những người dùng hợp pháp thông thường. Và cũng không giống như sự vô chủ, trung lập của các vùng DMZ ở đời thực, khi tạo ra một DMZ cho tổ chức thì thực sự nó là một phần của cả hệ thống mạng nội bộ mà bạn phải kiểm soát chúng thật tốt. “Screened subnet” hoặc “Perimeter network” là những tên gọi khác của DMZ.

    Kiến trúc xây dựng DMZ

    DMZ được tạo nên bởi hai thành phần cơ bản là: các địa chỉ IP và các firewall. Có hai đặc điểm nhận dạng quan trọng của DMZ mà bạn cần nhớ là: 1. Nó có một network ID khác so với mạng internal. 2. Nó bị phân tách khỏi mạng Internet và cả mạng internal bởi (các) firewall. Dưới đây tôi sẽ nói rõ hơn về hai đặc điểm này của DMZ

    1. Địa chỉ IP dùng trong DMZ


    Tùy vào kiến trúc của DMZ và cấu hình trên firewall mà một DMZ có thể sử dụng public IP hoặc private IP cho các server trong DMZ. Nếu bạn sử dụng public IP cho DMZ, thường bạn sẽ cần chia mạng con (subnetting) khối địa chỉ IP mà ISP cấp cho bạn để bạn có được hai network ID tách biệt. Một trong hai network ID này sẽ được dùng cho external interface (card mạng nối trực tiếp tới ISP) của firewall và network ID còn lại được dùng cho mạng DMZ. Lưu ý khi chia subnet khối public IP này, bạn phải cấu hình cho router của bạn để các gói tin từ ngoài Internet đi vào sẽ tới được DMZ. Bạn cũng có thể tạo một DMZ có network ID giống với mạng internal nhưng vẫn đảm bảo có sự cách ly giữa DMZ và mạng internal bằng cách sử dụng VLAN Tagging (IEEE 802.1q). Lúc này các server trong DMZ và các máy trạm trong mạng internal đều được cắm chung vào một switch (hoặc khác switch nhưng các switch này được nối với nhau) nhưng được gán vào các VLAN khác nhau. Còn nếu bạn sử dụng private IP cho DMZ, bạn sẽ cần đến NAT (một số firewall hỗ trợ sẵn tính năng này) để chuyển các private IP này sang một public IP (mà được gán cho external interface của firewall nằm giữa Internet và DMZ). Vì một số ứng dụng không làm việc tốt với NAT (ví dụ, Java RMI) nên bạn cân nhắc việc chọn cấu hình NAT hay định tuyến giữa Internet và DMZ.

    2. Các Firewall


    Có nhiều cách khi thiết kế một hệ thống mạng có sử dụng DMZ. Hai mô hình cơ bản và thường gặp nhất là: single firewall (hay three legged firewall) và dual firewall. Dưới đây tôi sẽ nói sơ qua về phương thức hoạt động cũng như ưu khuyết điểm của hai mô hình này. a) Với single firewall Bạn sẽ chỉ cần tới một thiết bị có ba NIC (network interface card). Trong đó, một NIC nối với mạng external, NIC thứ hai nối với mạng DMZ, và NIC còn lại nối với mạng internal.


    Đó là lý do tại sao người ta gọi nó là “three legged firewall” (mỗi “chân” của firewall chính là một NIC của nó). Lúc này “three legged firewall” phải có khả năng kiểm soát toàn bộ traffic vào/ra giữa ba mạng (internal, external và DMZ) và nó trở thành điểm chịu lỗi duy nhất (single point of failure) cho toàn hệ thống mạng. Nếu có sự cố xảy ra với “three legged firewall” này thì cả DMZ và mạng internal đều không còn được bảo vệ nhưng bù lại bạn không phải tốn chi phí đầu tư thêm một firwewall nữa như trong mô hình dual firewall dưới đây. Khi sử dụng single firewall để tạo DMZ, ta có khái niệm trihomed DMZ. Bạn cũng có thể tạo ra hai (hoặc nhiều hơn) vùng DMZ tách biệt có các network ID khác nhau bằng cách cách trang bị thêm số NIC tương ứng cho single firewall. b) Với dual firewall Bạn sẽ cần tới hai thiết bị firewall, mỗi firewall có hai NIC và được bố trí như sau: - Firewall thứ nhất (được gọi là front-end firewall) có một NIC nối với mạng external (external interface) và NIC còn lại nối với DMZ (internal interface). Front-end firewall này có nhiệm vụ kiểm soát traffic từ Internet tới DMZ và mạng internal. - Firewall thứ hai (được gọi là back-end firewall) có một NIC nối với DMZ (external interface) và NIC còn lại nối với mạng internal (internal interface). Back-end firewall này có nhiệm vụ kiểm soát traffic từ DMZ và Internet tới mạng internal.



    Rõ ràng, so với single firewall thì giải pháp này tuy tốn kém hơn về chi phí triển khai khi phải đầu tư tới hai thiết bị firewall tách biệt nhưng về mặt hiệu suất và độ an toàn cho hệ thống mạng của bạn sẽ được cải thiện. Vậy nên, tùy vào hoàn cảnh của tổ chức và môi trường của từng hệ thống mạng mà bạn nên xem xét lựa chọn giữa single firewall hay dual firewall cho thích hợp. Một số khuyến cáo cho rằng nên chọn hai firewall từ hai nhà cung cấp (vendor) khác nhau với lời giải thích rằng nếu hacker có thể bẻ gãy firewall đầu tiên thì cũng hắn cũng khó khăn hơn trong việc phá vỡ firewall thứ hai bởi chúng được tạo nên theo những cách khác nhau. Còn bạn, bạn nghĩ như thế nào về điều này?

    Kết luận


    DMZ được coi như là một trong các lá chắn bảo vệ của hệ thống phòng thủ nhiều lớp (defense in depth) cho mạng nội bộ của tổ chức. Nhưng cũng giống như các lá chắn khác, nó vẫn có khả năng bị phá hủy và việc giữ gìn sự lành lặn của lá chắn này đòi hỏi bạn cần cài đặt, cấu hình, giám sát hoạt động đầy đủ và thường xuyên cho các firewall và server trong DMZ. Hy vọng qua bài viết này bạn đã có một cái nhìn tổng quan về các khía cạnh của DMZ: Nó là gì? Nó có tác dụng gì? Đặc điểm của nó? Các hình thái khác nhau của nó?… Còn việc triển khai DMZ trong từng trường hợp cụ thể với từng sản phẩm firewall cụ thể thì xin hẹn các bạn ở các bài viết khác.

    Tác giả: –manthang.
    Last edited by phamminhtuan; 28-02-2012, 10:53 AM.
    Phạm Minh Tuấn

    Email : phamminhtuan@vnpro.org
    Yahoo : phamminhtuan_vnpro
    -----------------------------------------------------------------------------------------------
Trung Tâm Tin Học VnPro
149/1D Ung Văn Khiêm P25 Q.Bình thạnh TPHCM
Tel : (08) 35124257 (5 lines)
Fax: (08) 35124314

Home page: http://www.vnpro.vn
Support Forum: http://www.vnpro.org
- Chuyên đào tạo quản trị mạng và hạ tầng Internet
- Phát hành sách chuyên môn
- Tư vấn và tuyển dụng nhân sự IT
- Tư vấn thiết kế và hỗ trợ kỹ thuật hệ thống mạng

Network channel: http://www.dancisco.com
Blog: http://www.vnpro.org/blog

  • #2
    Remote desktop firewall

    RD Gateway deployment in a perimeter network & Firewall rules


    Remote Desktop Gateway (RD Gateway) is a role service available in Windows Server 2008 and higher versions. It allows authenticated and authorized remote users to securely connect to resources on an internal corporate or private network over the Internet. RD Gateway encapsulates Remote Desktop Protocol (RDP) within RPC, within HTTP over a Secure Sockets Layer (SSL) connection. RD Gateway server is exposed to the Internet (an untrusted network) and because of the reasons discussed in the Perimeter network section, either RD Gateway server is deployed in the perimeter network or RD Gateway server is deployed in the internal network with an ISA server in the perimeter network.
    1. Perimeter network:

    A perimeter network (also known as a DMZ, demilitarized zone, or screened subnet) is a small network that is set up separately from an organization's private network and the Internet. In a network, the hosts most vulnerable to attack are those that provide services to users outside of the LAN, such as e-mail, web, RD Gateway, RD Web Access and DNS servers. Because of the increased potential of these hosts being compromised, they are placed into their own sub-network called a perimeter network in order to protect the rest of the network if an intruder were to succeed. Hosts in the perimeter network should not be able to establish communication directly with any other host in the internal network, though communication with other hosts in the perimeter network and to the external network is allowed. This allows hosts in the perimeter network to provide services to both the internal and external network, while an intervening firewall controls the traffic between the perimeter network servers and the internal network clients.
    2. Perimeter network designs:

    Typically, a perimeter network can be designed and deployed in one of the following ways:
    • Single firewall (three-homed perimeter network)
    • Dual firewall

    2.1 Single-firewall perimeter network:

    In a single firewall perimeter network the firewall has 3 network adapters:
    • The first network adapter connects to the internal corporate network.
    • The second network adapter connects to the perimeter network.
    • The third network adapter connects to the external network (Internet).


    Figure 1: Single firewall perimeter network with RD Gateway server in the perimeter network
    2.2 Dual firewall perimeter network:

    In a dual firewall perimeter network, a firewall is located on either side of the perimeter network. One firewall is connected to the external network, one firewall is connected to the internal network, and the perimeter network resides between the two firewalls. This is a more secure approach because an attacker has to break both firewalls in order to get to the internal network.

    Figure 2: Dual firewall perimeter network with RD Gateway server in the perimeter network
    3. AD DS models in perimeter network

    Following are the possible AD DS models that are suitable for RD Gateway:
    • No AD DS in perimeter network: There is no AD in the perimeter network and RD Gateway (in the perimeter network) is joined to the internal network domain.
    • Forest trust model: One-way trust between the perimeter network AD DS and the internal network AD DS. RD Gateway is joined to perimeter AD DS.
    • Extended corporate forest model: A read-only domain controller for the internal network forest is in the perimeter network, and RD Gateway is joined to the internal network domain.

    3.1. RD Gateway without AD DS in perimeter network deployment:

    When there is no AD DS in the perimeter network, ideally the servers in the perimeter network should be in a workgroup, but the RD Gateway server has to be domain-joined because it has to authenticate and authorize corporate domain users and resources.
    The following diagram shows the traffic flow from the Internet to the perimeter network and from the perimeter network to the internal network in this deployment.

    Figure 3: Traffic flow from Internet to perimeter network and from perimeter to Internal network
    3.1.1. Internal firewall ports:

    In this deployment, RD Gateway needs the ports to be opened on the internal firewall for the following purposes:
    • To authenticate users
    • To authorize users
    • To resolve the DSN names of internal resources
    • To forward RDP packets from the client
    • To get the Certificate Revocation List
    • To send RADIUS requests (in a central NPS server scenario)

    3.2. RD Gateway with forest trust model deployment:

    In this deployment, there is AD DS in the perimeter network which trusts the internal network forest to authenticate the internal network forest users in the perimeter forest domain. RD Gateway is joined to the perimeter network domain. The trust between the perimeter network forest and the internal network forest is one-way, so configuring RD Gateway to use a central NPS server which is in the internal network is required in this deployment.
    The following diagram shows the traffic flow from the Internet to the perimeter network and from the perimeter network to the internal network in this deployment.

    Figure 4: Traffic flow from Internet to perimeter network and from perimeter to internal network
    3.2.1. Internal firewall ports:

    In this deployment, RD Gateway needs the ports to be opened on the internal firewall for the following purposes:
    • To establish one-way trust between the perimeter forest and the internal network forest
    • To forward RDP packets from the client
    • To send RADIUS requests
    • To get the Certificate Revocation List

    3.3. RD Gateway with extended corporate forest model:

    In this deployment, there is a read-only domain controller (RODC) in the perimeter network for the internal network forest. RD Gateway is joined to the internal network domain and talks to RODC for authentication and authorization purposes.
    The following diagram shows the traffic flow from the Internet to the perimeter network and from the perimeter network to the internal network in this deployment.

    Figure 5: Traffic flow from Internet to perimeter network and from perimeter to internal network
    3.3.1. Internal firewall ports:

    In this deployment, RD Gateway needs the ports to be opened on the internal firewall for the following purposes:
    • To communicate with the internal network forest from the RODC in the perimeter network
    • To forward RDP packets from the client
    • To get the Certificate Revocation List
    • To send RADIUS requests (in a central NPS server scenario)

    4. Firewall rule configurations required when RD Gateway is in the perimeter network:

    4.1. Firewall rules for the path between the external network and the perimeter network (Ports that need to be opened on the external firewall):

    • Port TCP:443 should be opened for allowing HTTPS traffic from the client sitting on the Internet to the RD Gateway server in the perimeter network.

    4.2. Firewall rules for the path between the perimeter network and the internal network (Ports that need to be opened on the internal firewall):

    The internal firewall should allow all communication from the RD Gateway server to internal network resources. Here are the ports that need to be opened on the internal firewall when the corresponding traffic (DNS, RADIUDS, RD Gateway Authentication, etc.) destination point is in the internal network.
    RD Gateway authentication traffic:

    Firewall rules between the perimeter network (RD Gateway) and the internal network (Domain Controller) to authenticate the user:
    • Server Protocol = Kerberos
    • Port = TCP: 88

    The RD Gateway server talks to the NT Directory Service (NTDS) RPC service on AD. The NTDS RPC service listens on an unused high end port. RD Gateway does not know the port number on which NTDS RPC service is listening. So RD Gateway talks to RPC Endpoint Mapper which listens on a constant port and gets the NTDS RPC service port number. Finally it makes a connection to the NTDS RPC service. Fortunately, the Admin can make the NTDS RPC service on AD listen on a constant port by using a registry key. To learn how to configure the registry values on AD for NTDS RPC service ports, see this article .
    • Server Protocol = RPC Endpoint Mapper
    • Port = TCP: 135, TCP: <Port on which NTDS RPC service listens on AD>

    Note: In Windows Server 2008 R2, RD Gateway can be configured to use non-native authentication methods through a custom authentication plug-in. If RD Gateway is configured with a custom authentication plug-in, contact the vendor of the authentication plug-in to find out which firewall rules are required for RD Gateway authentication.
    RD Gateway authorization traffic:

    Firewall rules between the perimeter network (RD Gateway) and the internal network (domain controller) to authorize the user:
    • Server Protocol = LDAP
    • For LDAP: Port = TCP: 389, UDP: 389

    Note: In Windows Server 2008 R2, RD Gateway can be configured to use non-native authorization methods through a custom authorization plug-in. If RD Gateway is configured with a custom authorization plug-in, contact the vendor of the authorization plug-in to find out which firewall rules are required for the RD Gateway authorization.
    DNS traffic:

    Firewall rules between the perimeter network and the internal network to resolve the internal network resources:
    • Server Protocol = DNS
    • Port = TCP: 53, UDP: 53

    RDP traffic:

    Firewall rules between the perimeter network and the internal network to forward RDP packets from client:
    • Server Protocol = RDP
    • Port = TCP: 3389

    Certificate Revocation List traffic:

    Firewall rules between the perimeter network and the internal network to contact CRL distribution point to get the certificate revocation list:
    • Server Protocol = LDAP or HTTP or FTP
    • For LDAP: port = TCP: 389, UDP: 389. For HTTP: port = 80. For FTP: Port = 21

    Note: The Certificate Revocation List is needed either to validate the client certificate during smart card authentication or when the certificate deployed on RD Gateway is an enterprise/standalone CA certificate. To know which protocol is needed to contact the CRL distribution point for a certificate, open the certificate and go to the Details tab and look at the CRL Distribution Points field.
    RADIUS traffic:

    If RD Gateway is configured to use a central server running NPS and if the NPS server is not in the perimeter network, then the following additional firewall rules are needed between the perimeter network (RD Gateway) and the internal network (NPS Server).
    • Server Protocol: RADIUS
    • Port = UDP: 1812
    • Server Protocol: RADIUS Accounting
    • Port = UDP: 1813

    5. RD Web Access and RD Gateway on the same server:

    If RD Web Access and RD Gateway are on the same server in the perimeter network or when RD Web Access is in the perimeter network, the following additional firewall rules need to be configured between the perimeter network (RD Web Access) and the internal network (RemoteApp Server).
    RD Web Access points to single RD Server or Single RD Server farm:

    This scenario is possible in Windows Server 2008 or higher versions. The WMI service on RD Server listens on an available high end port. The port on which WMI service listens can be fixed by executing the commands specified in this MSDN article. This fixed WMI port needs to be opened on the firewall.
    • Server Protocol: WMI
    • Port = TCP: <WMI Fixed Port>

    RD Web Access points to multiple RD Servers/farms:

    This scenario is possible in Windows Server 2008 R2. The WMI service on RD Web Access Server listens on an available high end port. The port on which WMI service listens can be fixed by executing the commands specified in this MSDN article. This fixed WMI port needs to be opened on the firewall.
    • Server Protocol: WMI
    • Port = TCP: <WMI Fixed Port>

    RD Web Access points to a centralized publishing server (Connection Broker):

    This scenario is possible in Windows Server 2008 R2.
    • Server Protocol = RPC
    • Port = TCP: 5504

    Note: If there is an ISA server already deployed in the perimeter network of your organization, then RD Gateway server can be put in the internal network which reduces the number of ports that need to be opened on the internal firewall (path from perimeter network to internal network) to one. Also, in order to ensure that un-authenticated traffic does not reach the RD Gateway server (i.e. the internal network), you can pre-authenticate the HTTPS traffic reaching the ISA using One-time-Password (OTP) – a form of RSA SecureID. More information on how to configure ISA can be found in the RD Gateway step-by-step guide.
    If authentication is not enabled on ISA, the following is the firewall configuration requirement in RD Gateway (internal network)-ISA (perimeter network) scenario.
    • If ISA is used as HTTPS-HTTPS bridging device:
      • Ports to be opened in the external firewall : TCP:443
      • Ports to be opened in the internal firewall: TCP: 443

    • If ISA is used as HTTPS-HTTP bridging device:
      • Ports to be opened in the external firewall: TCP:443
      • Ports to be opened in the internal firewall: TCP:80


    If authentication is enabled on ISA, then depending on the ISA authentication method some additional firewall rules may be needed.
    Last edited by phamminhtuan; 28-02-2012, 11:02 AM.
    Phạm Minh Tuấn

    Email : phamminhtuan@vnpro.org
    Yahoo : phamminhtuan_vnpro
    -----------------------------------------------------------------------------------------------
    Trung Tâm Tin Học VnPro
    149/1D Ung Văn Khiêm P25 Q.Bình thạnh TPHCM
    Tel : (08) 35124257 (5 lines)
    Fax: (08) 35124314

    Home page: http://www.vnpro.vn
    Support Forum: http://www.vnpro.org
    - Chuyên đào tạo quản trị mạng và hạ tầng Internet
    - Phát hành sách chuyên môn
    - Tư vấn và tuyển dụng nhân sự IT
    - Tư vấn thiết kế và hỗ trợ kỹ thuật hệ thống mạng

    Network channel: http://www.dancisco.com
    Blog: http://www.vnpro.org/blog

    Comment

    • Working...
      X