LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Security Week: July 28th, 2014
Linux Advisory Watch: July 25th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
( PORTFW - Locally ) - I can't reach my PORTFWed server from the INTERNAL lan

7.19. ( PORTFW - Locally ) - I can't reach my PORTFWed server from the INTERNAL lan

Basically, say your domain, acme.com, has an external IP address of 1.2.3.4 and you are PORTFWing all WWW traffic to an internal machine, say, 192.168.0.20/24. Then an /internal/ user on the 192.169.0.x network tries to contact to http://www.acme.com and expects things to work. Well, that isn't going to happen with a basic config. Let me explain. Basically, http://www.acme.com is being resolved to the IP of http://1.2.3.4 by your chosen DNS server. What really should be happening is the web request should resolve that request to http://192.168.0.20.

See the difference?

The proper solution to this is to setup a SPLIT DNS server. Internal users would be configured to use an /internal/ DNS server which would resolve requests like this with the 192.168.0.20 address when asked for www.acme.com. All external users should be serviced by an /external/ DNS server which will will resolve the requrest to the 1.2.3.4 IP address. From there, IPTABLES/IPCHAINS/IPFWADM would then PORTFW the traffic to the 192.168.0.20 server as normal.

But you're probably thinking that you don't want to setup a split DNS server and there has to be another way. There are a few alternatives! The first alternative is if you only have a few internal machines. Here, you can setup a "hosts" file entry on *all* internal machines. That static hosts entry would basically look like:

www.acme.com    192.168.0.20

Got it? With that in place, the machine would consult the hosts table before going to the DNS server to resolve the host. This works well but if you change the IP address on that internal web server, you're going to need to manually update the hosts file on all of those internal machines. If you are interested in doing the more scalable split DNS approach, TrinityOS completely covers split and chrooted DNS servers. TrinityOS - Section 24 http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos

Now, if neither the split DNS nor the hosts file approach interests you, you still have a simple but effective alternative to get things working. What you can do is add some specific rules to your rc.firewall-* ruleset. Please see the "PORTFW Redirection of Internal requests" section under the Section 6.7 chapter.

Why didn't I mention this alternative solution first? The main reason is that it's not the ideal solution. The primary problem with this approach is that every packet will be going from the internal MASQed client to the MASQ server. There, the MASQ server will SNAT each packet to the internal MASQed WWW server's IP and then forward it to the internal web server. Once the packet is received and responded to by the web server, that response has to go back through all that processing back to the original client machine. This process is overly wasteful on both network bandwidth and MASQ server CPU cycles!

    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Hackers Plundered Israeli Defense Firms that Built ‘Iron Dome’ Missile Defense System
Internet of things big security worry, says HP
Boffins build FREE SUPERCOMPUTER from free cloud server trials
Insecure Connections: Enterprises hacked after neglecting third-party risks
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.