Uploaded on


  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • Single router filters incoming and outgoing traffic No defense in depth/Single point of failure (security-wise)
  • Exterior router limits access to DMZ hosts Internal router further limits access to internal hosts All inbound packets must terminate in the DMZ Defense in depth
  • Internal DNS server probably more critical to daily operations of business (unless you’re an Internet company!)
  • The configs shown are only the most basic bits, for demonstration purposes only, etc. This config not for a chroot’d setup, see DMZ config for that The forwarders would typically be your bastion DNS server(s) in the DMZ Root hints not needed because forwards do all non-local lookups
  • Sample config for a chroot’d setup on a bastion host
  • Making the main directory writeable by bind would expose named.conf and your master zone files to modification, etc.
  • /var/run/log in FreeBSD, /dev/log in Linux syslog syntax shown (-l) is for FreeBSD, Linux reportedly uses the –a flag Holelogd works for systems where syslogd doesn’t support multiple sockets Alternative to making /var/run in your chroot directory is to use the controls statement in named.conf to change the path to the socket Symlink for ndc socket in /var/run is for ndc, which doesn’t know about the chroot
  • Example libs are for FreeBSD 4.x See Linux HOWTO for Linux libs and other requirements
  • NXDOMAIN is shorthand RFC-speak for non-existent domain
  • Also issues (depending on setup) with all subdomain queries being sent from the main internal server to the forwarder, which has to do a recursive query (query main server for delegation, query subdomain server for data). This causes extra load on forwarders. Also talked about in the cricket book.
  • Unique records can be generic (192-168-1-1.foo.net or whatever) Masquerading==PAT (There goes Linux, messing up another perfectly good term)
  • Point at website for more complete m4 file
  • Must make database map out of mailertable with “makemap hash mailertable < mailertable” Could use access_db (discussed shortly) instead of relay-domains
  • Again note that you must make a database map out of mailertable and access **Explain access** **Note 8.10+**


  • 1. DNS & Mail in the DMZ Jason Heiss Collective Technologies [email_address] [email_address]
  • 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 {;;};
    • }
    • 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 {;; };
    • 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)