Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Consider a Internet Based Website which does authentication. The Web Application can do the authentication by calling an Authentication Server which is not connected to the internet. The Authentication Server is not in the DMZ. However if 2 Factor Authentication needs to be done via One Time Password over SMS then the Authentication Server (which triggers the sending of the SMS) needs to be connected to the internet (to access the external SMS Gateway).

So how is this need taken care of? Is a proxy used - if yes, what kind of proxy?

share|improve this question
    
just a suggestion have u looked into how gmail sends sms in this way? Is it online or offline..or probably driven through some content delivery network.. –  Saladin Jul 13 '13 at 19:05
    
How do the Web Application call the Authentication Server if not connected to the internet? –  F. Hauri Jul 17 '13 at 6:51
    
@F.Hauri Why does the Auth Server need to be connected to the Internet for the Web Application to call it? –  user93353 Jul 17 '13 at 6:59
    
Ok I don't say that Internet is needed, just asked: ``How did you plan to do exchanges between Internet Web app and not connected Authority server'' (secondary ethernet connector on web app server?) –  F. Hauri Jul 17 '13 at 7:32
    
@F.Hauri Web Application is in the DMZ. Auth Server is in the intranet. Web Application can access Auth Server. –  user93353 Jul 17 '13 at 7:33

4 Answers 4

In a situation like this, all you need is a firewall. You should certainly not have a DMZ, and have no need for a proxy, but simply a firewall.

As with all your machines, the webserver should only be accessible on ports which are intended to be public-facing. The authentication server can be allowed only to egress packets on the SMS protocol, whatever that may be.

So your firewall set up would look something like:

NEW INGRESS:
* -> webserver:http   ALLOW
* -> webserver:https  ALLOW
* -> *                DROP

NEW EGRESS:
auth -> smshost:sms   ALLOW 
*    -> *             DROP

ESTABLISHED:
* -> *                ALLOW
share|improve this answer

In a perfect world

The Authentication Authority Server is not connected at all in order to prevent every unwanted (or not well monitored) outgoing connections (like trojan horses in worst case).

For this you will need

  • a way for Authentication Exchanges with the public Application Server.

    This could be done by using dedicated local network and/or using specific dedicated protocol.

  • a way for sending SMS.

    For this, there are essentialy two different solutions:

    1. Direct operator calling, using ISDN or analog modem. This is one of the more suitable solution as this don't depend on internet connection at all.
    2. Use a dedicated local network to a proxy, behind a firewall, and a dedicated protocol.

This solution present a strong security approach as they are not connected at all to the internet, but host is harder to maintain up to date: you have to physicaly load each upgrades.

And finally if there exist a way to connect this host to the internet (using the modem or a local gateway) an efficient trojan horse may find them! If this could happen, all this become totally wrong!

Simplier and efficient but lighter

Install your Authentication Authority Server behind a strong firewall that drop every packet but not

  1. packets from or to the Application server, that match protocol used for.
  2. packets from the Authentication Authority Server to your SMS provider, that match sms exchange protocol (maybe https) and his replies.

Sample based on GNU/Linux iptables:

LOCIF=eth0
DMZIF=eth1
PUBIF=eth2
AUTHSERV=192.168.3.21
WEBAPP=192.168.1.2
AUTHPORT=12345
SMSPORT=443
SMSSERV=1.2.3.4
iptables -t filter -P FORWARD DROP
iptables -t filter -o $LOCIF -i $DMZIF -d $AUTHSERV/32 -s $WEBAPP/32 -p tcp --dport $AUTHPORT -j ACCEPT
iptables -t filter -i $LOCIF -o $DMZIF -s $AUTHSERV/32 -d $WEBAPP/32 -p tcp --sport $AUTHPORT -j ACCEPT
iptables -t filtes -i $LOCIF -o $PUBIF -s $AUTHSERV/32 -d $SMSSERV/32 -p tcp --dport $SMSPORT -j ACCEPT
iptables -t filter -i $PUBIF -o $LOCIF -d $AUTHSERV/32 -s $SMSSERV/32 -p tcp --sport $SMSPORT -m state --state RELATED, ESTABLISHED -j ACCEPT

In this host, a trojan horse could reach Internet directly (must be blocked by firewall), so you have to keep your system and your firewall up to date, with care!

Monitor your traffic

Any case, if you want to trust your Authentication Authority Server, you have to finely and actively monitor all network traffic to this host.

Using low-level network monitor like tcpdump for sample.

share|improve this answer

You can use a VPN between the Authentication Server and SMS provider and only pass VPN traffic to the Authentication Server.

share|improve this answer

we have a similar setup, triggering SMS via Mail:

  • Authentication-Server is able to send mails via a distinct Mailgateway; from/to is restricted
  • Mails are deliver to the SMSGateway from that Mailgateway

If you need to trigger the SMS via HTTP/REST-Api and you dont want to Connect your Auth-Server to the internet you can do it via simple reverse_proxy - setup (nginx, apache):

  • Auth -> proxy: https://sms_proxy.intern/request
  • the Proxy has the SMS-Gateway as proxy_pass - destination configured. if you strip the right headers your auth-server stays complete invisible

Edit: typos

share|improve this answer
    
Is that reserve_proxy or reverse_proxy? –  user93353 Jul 15 '13 at 23:53
    
reverse; changed the answer –  that guy from over there Jul 16 '13 at 5:36
    
The answer still shows reserve :-) –  user93353 Jul 18 '13 at 4:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.