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?

On Tue, 29 Nov 2011 23:02:28 +0000, Peter
<occassionally-(E-Mail Removed)> wrote:
>
> There is no DMZ - this is all done with just one router e.g. one of
> the better Drayteks.
--
================================================== =======
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

In article <(E-Mail Removed)>,
Peter <occassionally-(E-Mail Removed)> wrote:
>
>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?

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.

>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?

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.

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

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

Nick
--
Serendipity: http://www.leverton.org/blosxom (last update 29th March 2010)
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996

Peter wrote:
> 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.

[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.

--
Graham J

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

"Peter" <occassionally-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

Peter wrote:
> 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.
>

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



> 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.
>

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.




> 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?
>

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.




> 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.
>

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.


> 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'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 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.
>

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


> 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.
>

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.



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

443 is https isn't it?

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

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


> On Tue, 29 Nov 2011 23:02:28 +0000, Peter
> <occassionally-(E-Mail Removed)> wrote:
>> There is no DMZ - this is all done with just one router e.g. one of
>> the better Drayteks.

R. Mark Clayton wrote:
> The usual method is to use a server with dual ports - one faces the internal
> LAN and the other the web.
>
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..

Peter <occassionally-(E-Mail Removed)> considered Tue, 29 Nov
2011 23:02:28 +0000 the perfect time to write:

>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.

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.
>
>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 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.
>
>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

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

Peter wrote:

> 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.

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.