How risky is it to have a web server on the internal LAN?

Take the case of a typical ADSL modem+router, doing NAT for the
internal LAN, and you get a little extra subnet of IPs from the ISP
and bring that subnet through the router to the internal LAN, where a
web server is set up to respond to one of the extra IPs.

There is no DMZ - this is all done with just one router e.g. one of
the better Drayteks.

So the internal LAN has some machines on 192.168.1.x, and the server
will be on a public IP of say 123.124.125.126.

The vulnerability I see in mixing stuff like that is that *all*
packets arriving on 123.124.125.126 are presented to *all* machines on
the internal LAN.

In theory, if a machine is not responding to that IP, all should be
well, but there have been loads of attacks involving malformed IP
packets.

How much protection does a normal ethernet controller provide? I
though the controller itself will ignore packets addressed to IPs
other than its own one - or is this an O/S function?

The router won't provide any protection to the 123.124.125.126 stuff
because that bypasses NAT, and AFAICS also bypasses the "DOS attack
protection" which the Drayteks offer.

It would be better if the 192.168.1.x internal LAN was behind another
NAT router, but you lose a lot of that protection if that 2nd router
has any open ports, which it will have if you need to support e.g. RDP
over VPN from the outside. I suppose one could terminate the VPN in
the *2nd* router, but then you have to open ports in the 1st router...

**Realistically** what is the risk in doing all this with a single
router?

I would have thought that after all these years, WinXP will have been
well patched against the obvious network attacks using malformed
packets which are *not* addressed to the machine in question.

And the web server has a unix firewall anyway. Even if you put it
behind a NAT router, you still have to open port 80, and a few others.

We have seen loads of dictionary attacks over the years, against port
443 usually. The routers do not have external admin enabled

 

Don't most routers have a DMZ setting that allows external packets
through to the IP you give it?

--
=========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

 

ARP is your protection here. The router (in fact any machine sending
an IP packet) will look up the ethernet address that corresponds to the
IP address, and put that in the headers. Other machines won't even see
the packet as it won't have their ethernet address, which either comes
from the network card or else is chosen by the wireless stack.

Only local machines can do ethernet broadcasts that would be seen by
all machines on your network.

In practical terms, only the risk that the router may get pwned, plus the
risk to some target computer that can receive packets, where "receive"
includes responses to its outgoing requests.

That's an application level attack which is quite different.

Nick

 

[snip]

The more modern Drayteks also support VLANS. So one specific port on
the LAN switch component could be allocated to the public subnet, and
connected to the web server. The other ports could be allocated to the
NATted internal LAN.

 

The usual method is to use a server with dual ports - one faces the internal
LAN and the other the web.

 

No they are not. Not unless you have a hub. Does anyone MAKE a hub anymore?

Malformed IP packets dont traverse the internet very well.


Look even with a hub, the packet HAS to have a well formed target
address or it wont be there. Nothing will respond to that except
something that has its interae iund to that address..OK you might try a
flood ping omna network address..but even then its inlikel;ty to do much.

I guess if its running a windows stack on a 286 it might be at risk..

With a switch the switch will know which IP address corresponds to which
MAC address and will route on that. Even a flood wont work because teh
actual networ adress is different to teh internal machines so a network
bridacts will ONLY go to those mahines known to be on that network.

Its more that an ethernet packet has a MAC address. And the switch knows
it.

It has to discover it initially using ARP - which is an ethernet
broadcast requesting an IP address to announce its MAC address.

But after that unless it cant 'get through' it will cache the arp for at
least a time.

A switch IS an Ethernet level router. its designed to be that way to
increase bandwidth so that a matrix of four machines communicating 2 x 2
don't flood each others cables needlessly.. For example.

So once you have a switch, it learns what machines are down what bit of
wire.

You dint propaget MAC addresses across the internet, so unless your
router is dioing NAT yiu cant talk to 192,168 machines directly.

Well thats cos you were dumb enough not to put the server on the 192 net
and redirect the porst to it, where its decently firewalled.

I've run a web server under NAT for years .. just get the router to
redirect port 80 traffic to 192.168.0.27:80 or whatever the server is
actually on. No need for public IP addresses beyond the one for the router.
..
That way you have full firewalling except on that port..but that's what
you want anyway - full access to port 80 from anywhere and nothing to
any other ports from the big bad internet.

I wouldnt take any bets based on WINXP security, but its simply
irrelevant. It will never see any packets.

uneccessary if you NAT it.

I only run a firewall on a server if its otherwise wide open. In this
case it wont be. You should NAT it like everything else.

443 is https isn't it?

 

DMZ less good for a single server than direct port pass through.

 

No it isn't.

The USUAL method is a static IP address and simply pass what server
ports are needful through to whatever server you have on the LAN..

Leave the server on a 'local' IP address and let the router sort out the
NAT - that's what it does best.

No need for dual porting or firewalls beyond what's on the router at all.

If you want e.g. remote admin access to the server, open up its port and
then firewall that port on the router except from 'trusted' admin source
addresses.

I've got a networked printer that is 'accessible' from the internet
here. BUT only from ONE external IP address - where I have a remote
virtual server that has a print queue sending back to my address here.

I've got a web server, but that is globally accessible. Except I got fed
up with people busting my bandwidth so its password protected and the
high traffic stuff is now on the hosted virtual server.

Been running that for years with no security problems Just bandwith
busting..

 

You don't need to get any additional IPs - just make sure your IP is
fixed rather than dynamic.
Then you set your router up to forward port 80 traffic to 192.168.n.n
- being the internal address of the webserver, port 25 traffic to the
address of your mailserver, and so on for any other servers you have.

Most routers support port forwarding, and most give a choice between
doing it port by port (good, because any unassigned traffic gets
blocked) or by setting a "default forwarding address" for any incoming
traffic (which is less sensible, as it exposes all ports on the
nominated server to the internet).

More risky than completely hiding the servers from the internal lan in
their own dmz, but less risky than giving them public IP addresses and
completely exposing all their ports on the internet.

I certainly wouldn't daisychain NAT. NATted Nat is an abomination.
I'd use a router and a physically separate firewall, with the firewall
being built on a PC with 3 ethernet cards - one for lan, one for
connection to the router (with the router passing the public IP
address through to it), and the third a dmz for servers which may be
reached from either lan or internet. You can configure the dmz using
local addresses (on a different subnet to the lan) and use port
forwarding in the firewall to send everything to the right place.
Or you can have a /29 subnet which gives you 6 IPs to play with, 5 of
which could be for use on the DMZ (you need one for the external
address of the firewall).
You only really need more than one IP address if you want to run more
than one server on the same port, and there aren't many IP addresses
to go around, so I'd recommend the private IP through NAT route.
You may need to run your own DNS server to provide local resolution
for the real addresses of servers in the dmz, or you could do that
with hosts files - it depends on how many PCs you have to look after.

On anything that can be exposed to that kind of attack, I run 3
strikes and out account locking (the number of strikes can be varied
depending on the security level you want/need and how likely it is for
a legitimate user to be clobbered by a lockout). You can still get in
as root/admin from the local console even if something has locked the
account by trying to break in over the network.
Of course, on a router that may mean breaking out the serial cable and
doing battle with the CLI

 

The router will send and ARP request for the public IP address, which
only the machine configured with will respond to with its MAC address,
then the switch (either internal to the router, or any additional ones
you have) will deliver the packets *only* to that MC address.

So unless you set (or add) the public IP address on a machine, the
outside packets won't reach it.

Without a DMZ there is still some risk, if the web server is
compromised, an attacker then has easier access to other servers on your
LAN.

 

OK I omitted some vital facts

Straight NAT, with port forwarding of port 80 etc, is what we had
before.

And that remains the case i.e. we use NAT to protect the internal
network - just like most people do.

The reason the public IP subnet is brought straight through is because
I wanted to be able to run an SSL VPN and access the internal network
machines with it, AND at the same time we want to run an online shop
on the web server which will also use port 443.

And you cannot do that with just a single public IP.

And we don't want to run the SSL VPN on a port other than 443 because
the whole point of having a SSL VPN for remote access is to get a
method which every GPRS/3G network has to support. Previously I used a
PPTP VPN, which worked fine when it worked, but there are an awful lot
of mobile networks, and loads of WIFI networks, which don't support
the PPTP protocol.

AND I wanted to do all this with just ONE box (plus the ADSL modem,
plus the ethernet switch on the inside) for ease of admin, and due to
my rather finite understanding of how this stuff works.

AND I need to be able to fully understand the config myself (it's my
own business).

If one had an SSL VPN router on which one could config which of the
external IPs the SSL VPN will respond on, and on which one could
config which of the external IPs have port forwarding of port 443,
that would be a fine solution because one could just buy a little
subnet from the ISP (2 usable IPs would do), NAT the lot, port forward
ports 80, etc, port forward 443 *from* a specific external IP to the
inside LAN, etc. But I never found such a box. I spent way too much
trying to config a piece of shit called a Sonicwall TZ100 on which I
never even got DNS working (well not with a PPPoE-connected ADSL
modem), I never got anything support-wise out of Fortigate (except a
sales call weeks later).

Sure a router with two separate ethernet interfaces on the internal
LAN would possibly also solve this...

On the Drayteks there is no choice which of the external IPs the VPN
terminator responds on. If you buy a subnet of say 8 IPs (5/6 usable)
you can bring them in using the WAN IP ALIAS, but then the VPN will
respond on them all and you cannot run an HTTPS server anywhere. And
any IP which is not brought in using the WAN IP ALIAS is wasted; all
you can do is bring it in using the 2nd SUBNET feature, which is what
we did.

I am sure there are Cisco boxes which can do it "all" but, as old
followers of my postings here will know I have not been exactly
successful in finding anybody who can set them up and I would never
understand them. I used to run some Cisco 803s whose IOS config was
rarely more than just about legible to me.

The unix server runs under FreeBSD and has a kernel level firewall.
This should be fine except it cannot be used to block e.g. dictionary
attacks from the same IP because, at that level, it cannot tell the
higher level activity.

Ultimately, it seems to me, the vulnerability of this setup hangs
wholly on the existence of back doors, and as always, DOS. If you port
forward e.g. an external IP of 123.124.125.126 to an internal LAN IP
of 192.168.1.20, and on that *physical* ethernet LAN (implemented with
a 16 port Netgear gigabit unmanaged switch) are some winXP PCs with
IPs of .30,31,etc, plus the server, then there is no way for anybody
to do anything other than DOS attacks (quite feasible given the ADSL
downlink is ~5mbits/sec but the uplink is only 800k, so if you send in
packets which require a response you can bring the system to a halt,
but the Draytek has some bandwidth limiting feature IIRC) or make use
of some back doors.

 

I looked at that but I don't think this is in any way usable unless
you use a managed switch afterwards. I also don't see any config in
the router for actually using that feature selectively as necessary.

 

NAT is *not* protection. It even doesn't prevent incoming connections —
if there is malicious code on your "internal" machines which wants to
accept an incoming connection rather than doing the normal thing of
connecting *out* to a server somewhere, there are *plenty* of ways that
it can do so. Including uPnP and various other protocol-specific tricks
where NAT boxes have to snoop on the traffic and open incoming ports in
order to work around the fundamental brokenness of what they're doing.

I think you'd be much better off abiding by the KISS principle. Just
have a single network of public IP addresses. Firewall the insecure
boxes if you think it's necessary, but don't mess around with NAT. Any
of the security benefits you *think* you get from NAT, are provided just
as well by a simple connection-tracking firewall.

Note that if you're using a VPN you want to make sure it runs over UDP
rather than only over TCP. TCP over TCP is not particularly efficient on
a slow and lossy link.

 

That's probably fair comment. For simplicity you would probably have a
totally separate switch to handle the VLAN for the web server (if you
needed more than one port), but naturally a managed switch that supports
VLANs gives better flexibility.

Which Vigor do you have?

In practise it may be better to run the web server at a hosting site, so
you get the benefit of higher relability and faster internet
connectivity, power backup, on-site tech support, and the like. But
there may be some specific reason why you want it at your location -
linked to a production database for factory? Web cameras of your
garden? Do tell ....

 

2955.

It's a very good box, which does some really nice stuff, has really
nice SSL VPN features like RDP emulation *in the router* (so the
client can be just any web browser, albeit with a bit of a performance
hit), and even I can understand how to set it up Not cheap at about
£350.

In a small business you need to be able to get to the office machines
when you are on holiday etc. I have used PPTP for years but too often
it doesn't work, and is never reliable.

It is partly historical.

We used to run an email server, which ran the TMDA challenge based
antispam, but as the years went on this got overwhelmed by up to 10k
spam emails per day, so we went to Messagelabs and now just get a
filtered email feed (which is obviously tightly firewalled in the
router).

We also run the firm's web server on it; it is low traffic (under 1GB
per month) so runs fine over ADSL. Soon we will have an online shop on
it too, with some fairly minimal integration to our accounts software.

And we have a backup of the web and email servers on a machine at
another location (my home), and Messagelabs (£400/year) will
automatically send email to the other site if the first is dead. It
works well for us. Home is on ZEN and work is on A&A; both very good
ISPs, except you don't want to run Iplayer under the A&A pricing
structure

I do run another website which is ~ 14GB/month and that one is hosted
on a proper server somewhere. A friend did it for free, and I help to
keep it down by putting big files in my home ISP's 1GB free filespace
which unfortunately has a 50MB filesize limit. That site is also
backed up on the home machine and I can change it over in an instant,
which I have had to do a few times.

I know it would be more logical to host it all somewhere, but I like
the redundancy, the ease of switching over the web server IPs in the
registrar's DNS control panel, and it enables me to host a load of
websites for e.g. the kids and for some friends, at zero cost.

 

I am not sure that is true actually.

You may have to be 'interesting' in your choice of VPN ports however.

Ah.. So you need two distinct services running off port 443, hmm.

I HOPE you mean ADSL ROUTER.

FULLY understanding anything is probably overly optimistic, but yes, you
need to understand ENOUGH to get it working with at least the most
glaring security holes covered.

I'll skip that because it don't (as you surmise) exist.

skip that as well.

Right.

It seems to me that the simple solution given what you need to achieve,
is more or less what you have arrived at./

Stick aa single card in the unix, and bind the external address to it,
and firewall it as appropriate.

It wont be able to talk to the internal network unless the ROUTER is
able to route between two internal interfaces, in which case all packets
going between the server and the internal network will go via the router
as everyone's default route.

I have not seen any consistency in consumer routes when doing this. Some
will allow you to contact a local 'web server' via the Nated or
externalised address, some wont..

You can solve that by binding a SECOND internal address to the SAME card
.. then the server has two addresses on the same interface and will
respond to either.

Make sure there is no default route on the internal interface if you
don't want the server using NATted sessions on traffic outbound to the
internet.

All that will WORK as I think you have realised, but the issue is now
one of security.

dont respond to pings is a good start.

They can flood you, but it wont take out the uplink.

I am more concerned about someone getting access to the server via the VPN.

The moment you put any kind of login passthrough on a public IP
address that you want to be generally available, you are increasing
risks hugely. Sure its ssl so you cant sniff the passwords - but who
bothers? a trojan on the users PC recording keystrokes... pure
dictionary attack...

I think you need to assume, even if its a remote chance, that you will
get someone logged in some day who should not be..

And gear your security to limit where else they can get before they get
there.

I am sanguine about running web servers - the code is good and access to
anything but what you serve them is limited - but admin logins or
general purpose pass throughs? That's a different matter.

For what its worth I don't think your original problem is a real problem
at all. There are far worse ones - see above. I.e it doesn't matter
where physically you put the box. Its the routing firewalling and
general management that is at issue.

And my experience of VPNs is not adequate to be of much further help.

 

Thereby negating one of the main reasons for choosing an SSL based VPN,
that every man and his dog allows what looks like HTTPS traffic out of
their network to the internet, so you can use your VPN most places where
you have web access (whether or not via a proxy server).

 

Well I have bitten the bullet and moved all of those to a virtual
private server.

Think it was around 15 quid a month.

That's rysnced back to here, for backup.

It allows me to make this network once more 'private' and indeed, that
might be an easy way out for you - move the websites offsite (but give
our IP addresses very direct access to it) and simply solve the VPN
problem separately.

My problem was mostly bandwidth, and the fact I needed my own code
running on the server doing specialised stuff. So a pure hosted solution
was out.

Not lot of disk space, but then its not actually needed.

I am thinking of moving email there, but that involves some real hassle
to deal with spam and relaying that I will have to tackle. And I know
how fast logfiles can grow if a mail server gets compromised.yuk!

 

It does. In te true sense of incoming connections.

Putting it simply, if a SYN packet comes into the router from the
internet, which machine must it forward it to? It cannot know UNLESS
you have opened up a translation that port 80 destination packets go
to THAT machine.

Not really, no.


Including uPnP and various other protocol-specific tricks

So don't have IGDP turned on, on the router in the first place.

If you want to play multiplayer doom or whatever, then you are by
definition not a serious network that takes security seriously.

Nat - pure NAT is almost all th firewall you will ever need.

It protects the network behind form ALL attacks initiated from outside.

If you download malware mind you, all bets are off.

Indeed, but KISS in most peoples cases is NAT everything and a
passthrough for port 80 to a web server.

Just

UDP is less secure at various levels though.

 

Also, I don't see I have a choice if I want to run an SSL VPN.

That is quite an important requirement, and it leads to having to get
extra IPs, etc, etc.