1 / 15

Observations on an enterprise IPv6 firewall and IDS

Observations on an enterprise IPv6 firewall and IDS. Tim Chown tjc@ecs.soton.ac.uk. IETF 68, 19th March 2007 Prague. Talk outline. Scenario IPv6 firewall and IDS deployment Observations on firewall activity Observations on IDS activity Considerations for firewall management

carol-mcleod
Download Presentation

Observations on an enterprise IPv6 firewall and IDS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Observations onan enterprise IPv6firewall and IDS Tim Chown tjc@ecs.soton.ac.uk IETF 68, 19th March 2007 Prague

  2. Talk outline • Scenario • IPv6 firewall and IDS deployment • Observations on firewall activity • Observations on IDS activity • Considerations for firewall management • Considerations for IDS developers

  3. Scenario • Enterprise (academic) network • Approx 1,000 hosts/servers • Up to 2,000 users • Using various OS’es and hardware • Running a dual-stack deployment • IPv6 pervasively on the wire • Most network services dual-stack (DNS, MX, web, etc) • Operational now for over three years • Partially done through 6NET project (www.6net.org)

  4. Border firewall and IDS • Lacking a suitable commercial solution at this time, currently looking for unified IPv4/IPv6 solutions • Currently use parallel paths into our site • Commercial IPv4 firewall • BSD pf for IPv6 • Snort IDS for both • Dual-stack DMZs including wireless LAN

  5. IPv6 firewall experience • Currently logging all pf blocked connections • Averaging around 20-30k entries per week • Very low compared to IPv4 • Most logged filter events are between our IPv6 DMZ and the internal IPv6 network • Similar level and protocols to existing IPv4 DMZ filtering • Around 500 or so ‘miscellaneous’ entries per week • No real evidence of systematic port scans • ‘Probing’ is to ports on publicly advertised systems, e.g. DNS servers, MX servers, Web servers, NTP servers

  6. Miscellaneous filters • In the ‘miscellaneous’ category: • X11 traffic • http • Highlights ruleset inconsistencies between IP versions. • ftp • SubethaEdit (port 6942) • ssh • auth • microsoft-ds (port 445) • …

  7. Microsoft-ds example • Log entries: 15:33:18.038763 2002:8c6d:14e7::8c6d:14e7.51878 > augur.ecs.soton.ac.uk.microsoft-ds: S 919595593:919595593(0) win 8192 <mss 1220,nop,wscale 8,[|tcp]> 15:33:21.034973 2002:8c6d:14e7::8c6d:14e7.51878 > augur.ecs.soton.ac.uk.microsoft-ds: S 919595593:919595593(0) win 8192 <mss 1220,nop,wscale 8,[|tcp]> 15:33:27.028456 2002:8c6d:14e7::8c6d:14e7.51878 > augur.ecs.soton.ac.uk.microsoft-ds: S 919595593:919595593(0) win 8192 <mss 1220,nop,nop,sackOK> • Target is a publicly advertised IPv6 node • The 2002::/16 source prefix is 6to4 • 8c 6d 14 e7 is 140.109.20.231 • Apparent source: • 231.20.109.140.in-addr.arpa. 86400 IN PTR guppy.iis.sinica.edu.tw.

  8. Malformed packets • An example sent towards our web server, perhaps looking to exploit an OS-specific bug/feature: 06:35:10.825875 2001:0:4136:e378:0:12c0:69f8:e96c > augur.ecs.soton.ac.uk: no next header 06:35:20.825276 2001:0:4136:e378:0:12c0:69f8:e96c > augur.ecs.soton.ac.uk: no next header 06:35:49.824144 2001:0:4136:e378:0:12c0:69f8:e96c > augur.ecs.soton.ac.uk: no next header

  9. Rarer ‘probing’ example • One host (in Thailand) checking presence/route to a number of publicly advertised systems: 20:06:51.850661 2001:f00::8.45821 > augur.ecs.soton.ac.uk.33434: udp 16 [hlim 1] 20:07:03.935552 2001:f00::8.45822 > sixprints.ecs.soton.ac.uk.33434: udp 16 [hlim 1] 20:09:14.044278 2001:f00::8.45824 > seven.ecs.soton.ac.uk.33434: udp 16 [hlim 1] 20:09:23.785148 2001:f00::8.45825 > zepler.ecs.soton.ac.uk.33434: udp 16 [hlim 1] 20:09:33.249159 2001:f00::8.45826 > moorhen.ecs.soton.ac.uk.33434: udp 16 [hlim1] 20:09:43.009118 2001:f00::8.45827 > crow.ecs.soton.ac.uk.33434: udp 16 [hlim1] 20:09:52.503731 2001:f00::8.45828 > jackdaw.ecs.soton.ac.uk.33434: udp 16 [hlim1] 20:10:02.243615 2001:f00::8.45829 > coot.ecs.soton.ac.uk.33434: udp 16 [hlim 1]

  10. Intrusion Detection Systems • We use Snort open source IDS/IPS • http://www.snort.org/ • A patch is available for IPv6 transport inspection • Just looks at certain application layer ‘signatures’ • Fuller support in release code soon • We expect a new test (beta) version any day now • Will include official IPv6 support for some features • Probably Stream5, HTTP Inspect, DCERPC and FTP Telnet preprocessors • New record type for IPv6 events • Will also need IPS IPv6 communication to firewall • To react to observed potential attacks

  11. Observations on our IDS • Running on our external link path • Note Snort supports multiple probe points • In a recent week’s logs: • Events logged from 26 different sources • Some from same /64 link, so it’s possible IPv6 privacy addresses may mask true number of sources • Can check the signature IDs, e.g: • http://www.snort.org/pub-bin/sigs.cgi?sid=1042

  12. Example IDS events seen • Logged events include: • WEB-IIS view source via translate header • BAD-TRAFFIC udp port 0 traffic • WEB-MISC backup access • WEB-MISC SSLv3 invalid data version attempt • IIS UNICODE CODEPOINT ENCODING • ATTACK-RESPONSES 403 Forbidden • TCP Portsweep • DOUBLE DECODING ATTACK • OVERSIZE REQUEST-URI DIRECTORY • Similar to what we see for IPv4 IDS

  13. Firewall management • Currently we have two firewall platforms • Could be managed via single interface/GUI • Need a consistent management interface for IPv4 and IPv6 hosts • Allow dual-stack or multiaddressed nodes to be managed • Reduce management complexity • Avoid inconsistencies • Not the case for all platforms looked at to date • Also important to consider IPv6-enabled status of all services for an IPv6 DNS-advertised host

  14. IDS considerations • The Snort we’ve used only examines application layer data for potential attacks • Uses the same signatures as IPv4 • We need to understand IPv6-specific issues to detect in IPv6 IDS systems, e.g. • Excessive hop-by-hop headers/options • Routing Header usage • Header ordering • Malformed headers • Transition tool abuse • Snort won’t see these issues today

  15. Summary • IPv6 firewall activity light (but so is traffic level) • Probing activity targeted at ‘advertised’ IPv6 addresses • IPv6 IDS seeing IPv4-like attacks • But we’re only looking at the application not the IP layer • And no way to do IPS messaging over IPv6 yet • Need to consider how firewalls can be consistently managed for dual-stack IPv4/IPv6 nodes • Need to discuss IPv6-specific IDS considerations • Testing new Snort version soon • Seeking people to help start an ID on this topic…

More Related