1 / 23

DNS & Mail in the DMZ

DNS & Mail in the DMZ. Jason Heiss Collective Technologies jheiss@ofb.net jheiss@colltech.com. Firewall Architectures. Screening Router Architecture. Screened Subnet Architecture. DNS (Domain Name Service). Goals. Separate internal and external DNS servers

Jims
Download Presentation

DNS & Mail in the DMZ

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. DNS & Mail in the DMZ Jason Heiss Collective Technologies jheiss@ofb.netjheiss@colltech.com

  2. Firewall Architectures

  3. Screening Router Architecture

  4. Screened Subnet Architecture

  5. DNS(Domain Name Service)

  6. Goals • Separate internal and external DNS servers • Limit the information about your network that is publicly available • Protect the internal DNS server from attack • Run as separate user • Successful attack on DNS server does not give root • Run in chroot environment • Successful attack doesn’t expose entire server

  7. Internal BIND Configuration • named.conf options { forward only; forwarders { 1.2.3.4; 1.2.3.5;}; } zone “foo.net” { type master; file “foo.net”; } • No root hints file • Zone files contain full info

  8. DMZ BIND Configuration • named.conf acl slaves { 10.1.2.3; 192.168.1.1; }; options { version “”; directory “/”; # Really /var/named named-xfer “/bin/named.xfer”; allow-transfer { slaves; }; } zone “.” { type hint; file “root.hints”; }; zone “foo.net” {type master; file “foo.net”; }; • Zone files contain only external hosts

  9. Running BIND as Non-root User • Very simple starting with BIND 8 • “named –u bind –g bind” • The only things the bind user should be able to write to are files for slave zones • By default, these are dumped into the main directory (from named.conf) with somewhat random names • This directory, therefore, would need to be writeable by bind • Best to specify specific filenames for each slave zone in named.conf and make only those files writeable by bind

  10. Running BIND in chroot • Looks simple • “named –t /var/named” • syslog • Can’t get at /var/run/log (or /dev/log or whatever) • “syslog –l /var/named/var/run/log” • holelogd from Obtuse System’s utils package • ndc • named makes a UNIX socket for ndc to talk to • mkdir /var/named/var/run • ln –s /var/named/var/run/ndc /var/run/ndc

  11. Running BIND in chroot, cont. • Slaves • Zone transfers to slaves use named-xfer • Must reside in chroot directory • Probably will require some dynamic libraries (or compile a static version of named-xfer) • /usr/libexec/ld-elf.so.1 • /usr/lib/libutil.so.3 • /usr/lib/libc.so.4

  12. ndc • ndc, for the most part, works fine (reload, stop, etc.) with all of this special configuration • Need symlink from the real /var/run/ndc to the chroot /var/run/ndc if chroot’d • ‘ndc start’ fires up named with no arguments • ‘ndc start –u bind –g bind –t /var/named’

  13. Complications • Subdomains • client.foo.net queries intradns.foo.net for host.sub.foo.net • Intradns ignores delegation and forwards query to bastion host • Bastion host is authoritative for (limited) foo.net, doesn’t know about sub.foo.net, and thus returns NXDOMAIN

  14. Complications, cont. • Subdomains, cont. • If you are big enough to need subdomains, you can probably afford a couple extra PCs to separate external DNS from forwarders • See DNS & Bind (DNS and Internet Firewalls section) for extensive discussion of problems and solutions

  15. Complications, cont. • Double-reverse DNS lookups • Performed by many FTP sites • Server looks up hostname associated with connecting IP • Server then looks up IP associated with that hostname • This IP must match original • Requires unique A and PTR records for all public IPs • Good case for proxies or NAT/PAT (masquerading)

  16. Mail

  17. Goals • Separate internal and external mail servers • Protects internal mail server(s) from attack • Provides choke point to apply filters • Masquerading • Virus scanning • Run as separate user • Run in chroot environment • Sendmail does not have a built-in chroot feature • Would be a good idea if your MTA supports it

  18. Internal Sendmail Configuration FEATURE(`local_procmail')dnl FEATURE(`mailertable')dnl MAILER(`local')dnl MAILER(`smtp')dnl define(`SMART_HOST', `bastion.foo.net')dnl

  19. Internal Sendmail Config, cont. • /etc/mail/mailertable foo.net local: .foo.net local: • /etc/mail/relay-domains foo.net

  20. DMZ Sendmail Configuration MASQUERADE_AS(`foo.net')dnl FEATURE(`mailertable')dnl FEATURE(`access_db’)dnl MAILER(`smtp')dnl define(`confRUN_AS_USER', `mail:mail')dnl define(`confSMTP_LOGIN_MSG', `')dnl define(`confPRIVACY_FLAGS', `goaway')dnl

  21. DMZ Sendmail Config, cont. • /etc/mail/mailertable foo.net smtp:mailhub.foo.net .foo.net smtp:mailhub.foo.net • /etc/mail/access Connect:mailhub.foo.net RELAY To:foo.net RELAY

  22. Running Sendmail as Non-root User • Queue should be owned by mail user so that Sendmail can queue mail temporarily • Otherwise user should have no privileges

  23. References • BIND • Grasshopper (Cricket) book (O’Reilly) • Building Internet Firewalls (O’Reilly) • Linux HOWTO • Sendmail • www.sendmail.org (Configuration Information) • www.sendmail.net (Good release notes) • ofb.net/~jheiss/sendmail_proxy.html • Bat book (O’Reilly)

More Related