traffic filtering: experience and recommendations of amres security wg

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


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)


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 …?”


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


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


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.


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


Traffic filtering: in the AMRES service centres


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


Traffic filtering: in the AMRES member institutions


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


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


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).


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.).


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)


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


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


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)


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


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


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).


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


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)


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


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


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


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]


Traffic filtering: Experience and Recommendationsof AMRES Security WG

Mara Bukvić, Belgrade University Computing Center/AMRES

Campus Best Practice Workshop

Skopje

15th of September 2011

traffic filtering: experience and recommendations of amres security wg

Documents