[kwlug-disc] firewall question
cedric at thinkers.org
Mon Feb 16 20:41:05 EST 2009
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
All the Best,
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
> 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
> complex to implement.
> kwlug-disc_kwlug.org mailing list
> kwlug-disc_kwlug.org at 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
More information about the kwlug-disc_kwlug.org