[kwlug-disc] firewall question

[Cedric Puddy]

Hi Glenn,

I'd consider a couple of different things.  One question I have in  
back of my mind: this client data: is it encrypted while in flight  
(eg: SSL or anything)?

That being said, here are what I think your main options are:

1) Your database server is running Linux, and therefore almost  
certainly has IP Tables -- make a quicky firewall setup/use the el- 
cheapo-simple firewall tool that came with your distro/use a third  
party firewall script to make a simple host based firewall --  
something like this:

		iptables -A INPUT -s <your webserver ip>/32 --dport 80 -j ACCEPT
		iptables -A INPUT -s <your local lan>/24 --dport 80 -j ACCEPT
		iptables -A INPUT -s 0.0.0.0/0 --dport 80 -j REJECT

	(my spider sense suggests to me that there may be some minor errors  
in the above, but take it in the spirit of pseudo code, K? :)  That  
wouldn't do a blessed thing to regulate traffic regarding any other  
port besides port 80, but presumably, your firewall isn't passing  
anything besides that inbound any way.

	This solution is probably best if your firewall is too basic to allow  
you to create access lists.

2) Your firewall is good enough that you an apply access lists to  
inbound port maps, or you upgrade it to one that can.  If you are on a  
budget, use a WRT54GL with Tomato firmware, and get a nice UI that  
covers both firewalling and QoS (great if you decide you want to play  
with VOIP service while you're at it :), or recycle a PC with pfSense,  
or.... you get the idea.

	This solution allows you to never pass invalid traffic onto your  
lan.  The previous solution, combined with a cheap router, makes it  
pretty easy for an attacker to fill up all the NAT translation slots  
on your router, for example.  Dropping the connection at the WAN side  
makes stupid exploits like that harder.

3) You can swing a VPN into play -- take a close look at OpenVPN.   
OpenVPN is UDP based, so it's very NAT friendly.  It is quite  
powerful, and potentially provides value in all kinds of  
circumstances, so I'd suspect that most geeks would get long term  
value out of learning it.

	The VPN approach ensures that your data is encrypted while in flight,  
and allows you to have some additional measure of confidence that your  
peer who you think it is.

	The one potential gotcha with a VPN is that it extends your private  
network to a 2nd location -- potentially, an attacker that compromises  
your remote box might suddenly have the run of your office network as  
well.  For that reason, you might want to build your tunnel strictly  
between the two boxes that need to talk, and apply an access list (a  
la idea #1) to ensure that only the expected traffic is exchanged  
between the two hosts.

	Another example of a VPN infrastructure (that intrinsically limits  
possible interactions between hosts) is SSH port forwarding, which may  
be just as good for your needs.  There are various examples of how to  
keep SSH port forwards nailed up, and if you just need one or two  
ports, or something that is SOCKS compliant, then it can be really  
quite effective.  (I use this for all manner of things -- for example,  
when I want to remotely access one of my mysql servers with the GUI on  
my laptop, I ssh with a port forward to a box on the LAN that *is*  
allowed to access the mysql server, fire up my GUI mysql client, and  
tada, I'm talking to the remote SQL instance, without having to put my  
current IP address into it's table of valid hosts, etc.)

	SSH ports can be another area of vulnerability -- I would suggest  
looking at Single Packet Port Knocking techniques to all but  
completely mitigate any concerns on that from (this is where your  
firewall blocks all traffic, but keeps an eye out for specially  
crafted PGP encrypted packets.  If it sucessfully decrypts one of  
these packets, it will get a pay load that tells it to open up the  
firewall for one specific remote IP address for one specific port, for  
a few specific minutes -- that's your opportunity to connect, and one  
that nobody else can really do much to take advantage of.)

I hope that one or more of those suggestions sparks some excitement  
for you!

	All the Best,

	-Cedric


On 16-Feb-09, at 7:34 PM, Insurance Squared Inc. wrote:

> I've got a database inhouse here running on a linux server...our  
> client
> DB. Normally I'd just disallow port 80 at the router and call it done
> for security :).  However, the database takes input from my website.
> HTML forms are routinely POSTED to a specific program on the inhouse
> server.  So I've got port 80 pointed at the server.  That works fine,
> but now my DB server is exposed to the world.
>
> If it was a webserver, I wouldn't worry about it. But if it was a web
> server, I wouldn't be running client data on it.
>
> What's my best/easiest security solution?  Basically I need one way in
> for my webserver to POST records to the DB.  No external http: access
> (other than internal to my network) necessary.
>
> I'm thinking along the lines of:
> - can I set my router to direct incoming POSTS to the server, but not
> allow anything out?  This is just a standard home QOS router.
> - Do I just use an htaccess file to only allow in/out access from
> internal IP's, and only incoming from external IP's?
> -  worst case, do I delve into IPtables?
>
> The first one is the one I like, but I don't think it's possible.  The
> second is easy for me to implement, but makes me more nervous.  The
> third is possibly more secure than the second one but for me, much  
> more
> complex to implement.
>
> Thoughts?
>
> -glenn
>
> _______________________________________________
> kwlug-disc_kwlug.org mailing list
> kwlug-disc_kwlug.org at kwlug.org
> http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org



|  CCj/ClearLine - Unix/NT Administration and TCP/IP Network Services
|  118 Louisa Street, Kitchener, Ontario, N2H 5M3, 519-489-0478
\________________________________________________________
    Cedric Puddy, IS Director            cedric at thinkers.org
      PGP Key Available at:              http://www.thinkers.org/cedric