connect communicate collaborate traffic filtering: experience and recommendations of amres security...
TRANSCRIPT
connect • communicate • collaborate
Traffic filtering: Experience and Recommendationsof AMRES Security WG
Mara Bukvić, Belgrade University Computing Center/AMRES
Campus Best Practice Workshop
Skopje
15th of September 2011
connect • communicate • collaborate
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)
connect • communicate • collaborate
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 …?”
connect • communicate • collaborate
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
connect • communicate • collaborate
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
connect • communicate • collaborate
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.
connect • communicate • collaborate
Traffic filtering: on the AMRES connections to the Internet
Hierarchical structure of AMRES
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)
Position 1
connect • communicate • collaborate
Traffic filtering: in the AMRES service centres
Hierarchical structure of AMRES
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)
Position 2
connect • communicate • collaborate
Traffic filtering: in the AMRES member institutions
Hierarchical structure of AMRES
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
Position 3 and 4
connect • communicate • collaborate
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
connect • communicate • collaborate
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).
connect • communicate • collaborate
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.).
connect • communicate • collaborate
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)
connect • communicate • collaborate
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
connect • communicate • collaborate
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 networkadd records in DNS tables for direct mapping (MX record) and inverse mapping (PTR record) for resolving name to addresses and vice verseallow 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 interfaceAdditional config. on servers.
– switch off “relay” function for all non authorized users– Antivirus, antispam, loging and SNMP
connect • communicate • collaborate
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)
connect • communicate • collaborate
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-text format vs. encryption form
Recommendations:
Use SSH instead of Telnet (where it is possible)
Still restrain SSH on perimeter – allowed access to servere on port 22
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
connect • communicate • collaborate
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
connect • communicate • collaborate
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).
connect • communicate • collaborate
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 loggingCreate 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
connect • communicate • collaborate
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)
connect • communicate • collaborate
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
connect • communicate • collaborate
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
connect • communicate • collaborate
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
connect • communicate • collaborate
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:
Version in Serbian on
https://www.bpd.amres.ac.rs/
Campus Best Practice Team:
connect • communicate • collaborate
Traffic filtering: Experience and Recommendationsof AMRES Security WG
Mara Bukvić, Belgrade University Computing Center/AMRES
Campus Best Practice Workshop
Skopje
15th of September 2011