Traffic filtering: Experience and Recommendations of AMRES Security WG

1. Traffic filtering: Experience and Recommendationsof AMRES Security WG Mara Bukvić,Belgrade University Computing Center/AMRES Campus Best Practice Workshop Skopje 15th of September2011

2. Traffic filtering: Experience of AMRES Security WG – First steps • Before GN3/NA3/T4 no joint effort on production of BPDs in AMRES • Initial Challenges: • Explaining idea of WG and BPD to community • Selecting area of interest and subjects of BPDs • Security is selected as area of interest in AMRES – reasons: • Community show interest for wide range of topic in area (firewalls, CERT, AAI) • Urgent and/or continual improvements needed (in parts or whole network) • New colleagues (join institution team or institution join AMRES)

3. Recommendations regarding the first steps • Discussion in WG could be beneficial for you • (even there are not financial support at first) • Candidate topic to start with: • Areas which need continual improvements, such as phy topic, email spam, filtering, network monitoring … • there are experiences inside community • Areas in which NREN is not yet developed but keeping pace with in others, such as eduroam, and wireless, IPv6 … • No much or previous experiences in area is challenging for community • Gather experience, learn and grow together • “Is there some BPD about …?”

4. Recommendations regarding the first steps (cont.) • Do not have to be ambitious at the beginning (start) • Benefit from other NRENs experience, use already prepared BPDs • Can try with existing BPDs and try to discus • If it cover your needs in proper way • How to change it and adopt it to your situation

5. Traffic filtering: Experiences of AMRES Security WG – Questions raised • Subject for very long time with us • What exactly do you mean when you say “traffic filtering”? • Answering on this question leads us to: • Identification points of filtering the traffic in hierarchical structure of AMRES

6. Traffic filtering: Positions in hierarchical structure of AMRES Hierarchical structure of AMRES Positions 1. on the AMRES connections to the Internet; 2. in the AMRES service centres; 3. on the connections between AMRES member institution and the regional service centre; 4. in the internal network of the AMRES member organisations themselves.

7. Traffic filtering: on the AMRES connections to the Internet Hierarchical structure of AMRES Position 1 Block disallowed protocols, destination service ports and IP addresses No much left of legacy filtering should be regulated by Policy for Traffic Filtering at AMRES (adopted by the management body of AMRES)

8. Traffic filtering: in the AMRES service centres Hierarchical structure of AMRES Position 2 Exhensive use of proxy service Resaons: Support for KOBSON service Requirements for logging Inclusion of institutions’ proxy services on positions 4 should be regulated by Policy for Traffic Filtering at AMRES (adopted by the management body of AMRES)

9. Traffic filtering: in the AMRES member institutions Hierarchical structure of AMRES Position 3 and 4 might be regulated by Policy for Traffic Filtering at institution (adopted by the management body of that institutions) We need BPDs for position 3 and 4

10. Traffic filtering: Initial Conclusions and Recommendations of AMRES Sec. WG • Discussion leads to: • Identification points of filtering the traffic in hierarchical structure of AMRES • How to select device (technology and performance) • Agree of documents needed: • Policy for packet filtering at AMRES • BPDs: • AMRES BPD Traffic Filtering in End Institutions • AMRES BPD Traffic Filtering – An Overview of Technologies and the Points of Their Application at AMRES

11. An Overview of filtering technology • Packet filters on: • routers or • firewalls (the standard stateful packet inspection) • Dedicated proxy • Available devices with basic solutions from intrusion detection technology. The improved version is called • stateful protocol analysis, • also known as DPI (deep packet inspection).

12. An Overview of filtering technology (contin.) • The stateful protocol analysis can: • determine whether an e-mail message contains an attachment type that is not allowed (e.g. exec files); • determine whether instant messaging is used via an HTTP port; • block the connection through which an unwanted command is executed (e.g. an FTP put command on the FTP server); • block access to a page with unwanted active content, e.g. Java; • identify an irregular sequence of commands exchanged in the communication between two hosts (e.g. an unusually large number of repetitions of the same command or the use of a command before using the command it depends on, etc.); • enable the verification of individual commands and the minimum and maximum length of appropriate command-line arguments (e.g. the number of characters used in a username, etc.).

13. Traffic filtering: Experiences of AMRES Security WG – Questions raised • Discussion about traffic filtering usually starts with question not easy to solve, i.e. • How to filter torrent? • Disallowed download of movies and block busters • Finding solution for dynamic port filtering • Important to know: • SERENATE studia 80% satisfied with basic services (web, mail), if bandwidth, mobility could be provided in addition • AMRES 80% WEB services (including KoBSON service: joint procurement of research and scientific paper)

14. Traffic filtering: Experiences of AMRES Security WG – Recommendations • Identify services important for your network, such us www, mail, ssh vs. telenet, ntp … and try to agree and define rules for them • Block spam, set antispoofing filters, consider to control ICMP on you network • Keep local traffic local • Use logging

15. Mail (port 25) • Two kind of filters needed: • traffic from to infected or malicious computers • stations on network perimeter • spam on servers • Identify the mail servers in local network • add records in DNS tables for direct mapping (MX record) and inverse mapping (PTR record) for resolving name to addresses and vice verse • allow outgoing mail traffic (sending mail) only for these servers on port 25 • allow incoming mail traffic (receiving mail) fwd. these servers only • Access to external mail servers – web interface • Additional config. on servers. • switch off “relay” function for all non authorized users • Antivirus, antispam, loging and SNMP

16. Web • Consider using proxy • Enable restrict traffic additionally - complementary to restrict traffic on network perimeter • Logging could be more important for you than cheching • Switch on standard (XFF : X-Forwarded-For) for identification of original address of packets on their way through proxy server (source address of client which started connection)

17. Telnet vs. SSH (port 23 vs. 22) • Enable remote access to equipment and use of command-line mode on remote devices (routers also) • Exchange information in clear-textformat vs. encryption form • Recommendations: • Use SSH instead of Telnet (where it is possible) • Still restrain SSH on perimeter – allowed access to servere on port22 • If it is not possible to avoid using of Telnet: • constrain usage to your local network, • Still strongly recommend to use segmentation on local network (standard 802.1q) , enable access only to devices which do not support other protocols • outgoing Telnet traffic toward external servers might be allowed

18. Antispoofing • Antispoofing on network perimeter:   • Incoming - It is recommended to deny traffic from the outside that has the same source address that your internal network. • Outgoing - It is advisable to block false source address from your own internal network and “protect others” • There should be barrier for private and reserved address space • Means address space: 10.0.0.0/8; 172.168.0.0/16; 192.168.0.0/16; 127.0.0.0/8; 0.0.0.0/8; 224.0.0.0/4 etc., incoming and outgoing traffic, • Complete list it RFC1700

19. Keep local traffic local • Deny all TCP / UDP traffic from around the world against all your resources and/or local services • Example: • 135 -139 i 445 (NetBIOS, CIIFS) , both directions, • 111 (RPC) • 1433 i 1434 (MS SQL), both directions, • 389 (LDAP) • 161, 162 (SNMP), might be completely restricted or allowed for access from NREN management stations (read and collect statistics).

20. Traffic filtering: Final Recommendations of AMRES Security WG • Identify services important for your network, such us www, mail, ssh vs. telenet, ntp … and try to agree and define rules for them, decide about ICMP traffic • Select strategy - Default permit versus default deny • Everything not permitted is denied. (Closed end) – strongly recommended • Anything that is not denied is allowed. (Front end) • How to handle “forgotten” services – there is logging • Create a rule to the end that allows everything else, but that also logs all elements in this one rule. • See the log for services / traffic you want to allow, and expand the original list of approved services. • Remove a rule at the end of the process

21. Example – set of common services defined in AMRES • ! ABSOLUTELY ALLOWED SERVICES • ! – icmp • ! - domain (udp,tcp port 53) • ! - snmp (udp port 161) • ! - ntp i time protokols (udp,tcp port 123,37,580) • ! - SMTP i SMTP TLS  (tcp port 25, 587) • ! - telnet (tcp port 23) • ! - finger (tcp port 79) • ! - POP3 i POP3 SSL  (tcp port 110, 995) • ! - IMAP i IMAP SSL (tcp port 143, 993) • ! - irc (tcp port 194,6665,6667) • ! - auth, ident (tcp port 113) • ! - ssl (tcp port 443)

22. Example – set of services defined in AMRES (cont.) • ! ABSOLUTELY ALLOWED SERVICES (cont.) • ! - icq (tcp port 4000,5190, udp port 4000) • ! - traceroute (udp port 33434-33465) • ! - cvsup (tcp/udp port 2401 i port 5999) • ! - Yahoo Voice/Webcam (udp/tcp 5000-5010, tcp 5100) • ! - rsync (tcp port 873) • ! - SciFinder (tcp port 210) • ! - Remote Desktop (tcp 3389) • ! - VRVS (tcp 46000-46100,udp 46004,udp 51000-56000,tcp 5900-5910,tcp 1720) • ! - NetPerf (tcp 12865) • !- SIP, H.323 i RTP, • ! - Gtalk, MSN messenger, Jabber, Skype

23. Example – set of services from EDURAOM Policy • SSH: TCP/22 outgoing traffic • HTTP: TCP/80 outgoing traffic • HTTPS: TCP/443 outgoing traffic • IMAP2+4: TCP/143 outgoing traffic • IMAP3: TCP/220 outgoing traffic • IMAPS: TCP/993 outgoing traffic • POP: TCP/110 outgoing traffic • POP3S: TCP/995 outgoing traffic •  Passive (S)FTP: TCP/21 outgoing traffic • SMTPS : TCP/465 outgoing traffic • SMTP with STARTTLS: TCP/587 outgoing traffic • RDP: TCP/3389 outgoing traffic

24. Example – set of services from EDURAOM Policy (cont.) • Standard IPSec VPN: IP protocol 50 (ESP) i 51 (AH), and incoming traffic; UDP/500 (IKE) outgoing traffic. • OpenVPN 2.0: UDP/1194 • IPv6 Tunnel Broker service: IP protocol 41 - outgoing and incoming traffic • IPsec NAT- Traversal UDP/4500 • Cisco IPSec VPN over TCP: TCP/10000 outgoing traffic • PPTP VPN: IP protocol 47 (GRE) outgoing and incoming traffic; TCP/1723: outgoing traffic

25. AMRES BPDs (Engl. version) about traffic filtering are coming soon? • Find they on the page with all Campus Best Practice documents • http://www.terena.org/campus-bp/ • Currently 31 documents available • Be first who knows – subscribe to the list Announcements of new documents: • campus-bp-announcements@terena.org • Version in Serbian on • https://www.bpd.amres.ac.rs/ • Campus Best Practice Team: • gn3campus@uninett.no

26. Traffic filtering: Experience and Recommendationsof AMRES Security WG Mara Bukvić,Belgrade University Computing Center/AMRES Campus Best Practice Workshop Skopje 15th of September2011