Transcript DRAFT ON NETWORK MANAGEMENT ARCHITECTURE

Traffic filtering:
Experience and Recommendations
of 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
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)
connect • communicate • collaborate
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)
connect • communicate • collaborate
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
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 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
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 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
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 59005910,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:
[email protected]
Version in Serbian on
https://www.bpd.amres.ac.rs/
Campus Best Practice Team:
[email protected]
connect • communicate • collaborate
Traffic filtering:
Experience and Recommendations
of AMRES Security WG
Mara Bukvić, Belgrade University Computing Center/AMRES
Campus Best Practice Workshop
Skopje
15th of September 2011
connect • communicate • collaborate