Discussion:
Meerdere netwerk interfaces met gateway
(te oud om op te antwoorden)
Stef
2010-10-14 13:39:14 UTC
Permalink
Momenteel heb ik twee netwerk interfaces, eth0 (naar buiten) en eth1
(intern).

Bij opstarten gebruiken ze deze configuraties:

[***@c7-d network-scripts]# cat ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
BROADCAST=x.x.x.191
IPADDR=x.x.x.188
IPV6INIT=yes
IPV6_AUTOCONF=yes
NETMASK=255.255.255.248
NETWORK=x.x.x.184
ONBOOT=yes
GATEWAY=x.x.x.185
TYPE=Ethernet
PEERDNS=yes
USERCTL=no

[***@c7-d network-scripts]# cat ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
NETMASK=255.255.255.0
IPADDR=192.168.47.200
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes

Normaal werkt dit prima, alles voor 192.168.47.0/24 gaat naar eth1
en al het overige naar eth0.

Nu komt er echter op 192.168.47.0/24 een gateway die andere
192.168.0.0/16 (en ook nog wat 10.0.0.0/8) via een tunnel beschikbaar
maakt. Handmatig heb ik nu even de routing tabel aangepast zodat heel
192.168.0.0/16 naar eth1 gaat en er een gateway is:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
x.x.x.184 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.47.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
192.168.0.0 192.168.47.254 255.255.0.0 UG 0 0 0 eth1
0.0.0.0 x.x.x.185 0.0.0.0 UG 0 0 0 eth0

Dit werkt (alleen moet die 10.0.0.0 regel er nog bij, zelfde gateway),
alleen is het niet permanent. Is het mogelijk het script van eth1 aan te
passen zodat bij boot steeds de juiste routing onstaat (en hoe)? Of moet
ik nog ergens iets scripten bij booten (hoe)?

Ik draai overigens CentOS 5 (RHEL5)
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

"When people are least sure, they are often most dogmatic."
-- John Kenneth Galbraith
Richard Lucassen
2010-10-14 15:19:24 UTC
Permalink
On Thu, 14 Oct 2010 15:39:14 +0200
Post by Stef
Nu komt er echter op 192.168.47.0/24 een gateway die andere
192.168.0.0/16 (en ook nog wat 10.0.0.0/8) via een tunnel beschikbaar
maakt. Handmatig heb ik nu even de routing tabel aangepast zodat heel
[..]
Post by Stef
Dit werkt (alleen moet die 10.0.0.0 regel er nog bij, zelfde gateway),
alleen is het niet permanent. Is het mogelijk het script van eth1 aan
te passen zodat bij boot steeds de juiste routing onstaat (en hoe)?
Of moet ik nog ergens iets scripten bij booten (hoe)?
Het is alweer een tijdje terug, maar destijds moest je een file
aanmaken in /etc/sysconfig/static-routes waar je dat kon aangeven. Maar
dat is alweer jaren geleden. De syntax weet ik echter niet meer. Via
google zou je het moeten kunnen vinden.

Maar wat je doet is niet echt netjes, je krijgt allemaal icmp redirects
op je 192.168.47.0/24 netwerk nu tenzij je ieder station daar van de
route vertelt. Het werkt echter wel. Beter is een eth2 te configgen met
daarachter het apparaat naar 192.168.0.0/16 en 10.0.0.0/8 gaat. Dan heb
je maar 1 gateway op je interne LAN en regelt de Linuxdoos de routering,
firewalling e.d.

R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
Stef
2010-10-14 21:55:41 UTC
Permalink
In nl.comp.os.linux.netwerken,
Post by Richard Lucassen
On Thu, 14 Oct 2010 15:39:14 +0200
Post by Stef
Nu komt er echter op 192.168.47.0/24 een gateway die andere
192.168.0.0/16 (en ook nog wat 10.0.0.0/8) via een tunnel beschikbaar
maakt. Handmatig heb ik nu even de routing tabel aangepast zodat heel
[..]
Post by Stef
Dit werkt (alleen moet die 10.0.0.0 regel er nog bij, zelfde gateway),
alleen is het niet permanent. Is het mogelijk het script van eth1 aan
te passen zodat bij boot steeds de juiste routing onstaat (en hoe)?
Of moet ik nog ergens iets scripten bij booten (hoe)?
Het is alweer een tijdje terug, maar destijds moest je een file
aanmaken in /etc/sysconfig/static-routes waar je dat kon aangeven. Maar
dat is alweer jaren geleden. De syntax weet ik echter niet meer. Via
google zou je het moeten kunnen vinden.
OK, ik zal daar eens naar gaan zoeken.
Post by Richard Lucassen
Maar wat je doet is niet echt netjes, je krijgt allemaal icmp redirects
op je 192.168.47.0/24 netwerk nu tenzij je ieder station daar van de
route vertelt. Het werkt echter wel. Beter is een eth2 te configgen met
daarachter het apparaat naar 192.168.0.0/16 en 10.0.0.0/8 gaat. Dan heb
je maar 1 gateway op je interne LAN en regelt de Linuxdoos de routering,
firewalling e.d.
De linuxdoos gebruikt deze routering alleen om zelf naar buiten (via eth0)
en naar de tunnels (via eth1) te kunnen. Die tunnels worden weer door een
ciscodoosje geregeld dat naast die tunnels ook firewall/gateway is. De
normale netwerk clients gebruiken het ciscodoosje als gateway en de
linuxdoos alleen als locale server. Forwarding staat nog wel aan op de
linuxdoos, maar zou eigenlijk nu uit kunnen (hij is gateway geweest, maar
die taak is dus recent overgenomen door de ciscodoos).

Dus mij lijkt dat alles zo netjes is, of zie ik dat verkeerd? Enig punt
is wel dat nu de linux- en ciscodoos in feite parrallel aan elkaar
tussen het internet en het 192.168.47.0 netwerk staan.

Op zich zou ik clients ook de linuxdoos als default gateway kunnen
opgeven, maar dan moeten ze wel weten dat de ciscodoos de gateway
is voor de overige 192.168.x.0 netwerken. Doe je dat laatste niet,
dan krijg je toch pas de situatie die jij schetst?
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Caution: breathing may be hazardous to your health.
Stef
2010-10-14 22:19:34 UTC
Permalink
In nl.comp.os.linux.netwerken,
Post by Stef
In nl.comp.os.linux.netwerken,
Post by Richard Lucassen
On Thu, 14 Oct 2010 15:39:14 +0200
Post by Stef
Dit werkt (alleen moet die 10.0.0.0 regel er nog bij, zelfde gateway),
alleen is het niet permanent. Is het mogelijk het script van eth1 aan
te passen zodat bij boot steeds de juiste routing onstaat (en hoe)?
Of moet ik nog ergens iets scripten bij booten (hoe)?
Het is alweer een tijdje terug, maar destijds moest je een file
aanmaken in /etc/sysconfig/static-routes waar je dat kon aangeven. Maar
dat is alweer jaren geleden. De syntax weet ik echter niet meer. Via
google zou je het moeten kunnen vinden.
OK, ik zal daar eens naar gaan zoeken.
En al gevonden, inderdaad static-routes dus.

[***@c7-d ~]# cat /etc/sysconfig/static-routes
any net 192.168.0.0 netmask 255.255.0.0 gw 192.168.47.254
any net 10.0.0.0 netmask 255.0.0.0 gw 192.168.47.254

(ipv 'any' zou ook 'eth1' kunnen, maar zo zoekt ie het zelf uit)

[***@c7-d ~]# service network stop
[..]

[***@c7-d ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface

[***@c7-d ~]# service network start
[..]

[***@c7-d ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
x.x.x.184 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.47.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
192.168.0.0 192.168.47.254 255.255.0.0 UG 0 0 0 eth1
10.0.0.0 192.168.47.254 255.0.0.0 UG 0 0 0 eth1
0.0.0.0 x.x.x.185 0.0.0.0 UG 0 0 0 eth0

Perfect opgelost, dank!
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

If you are honest because honesty is the best policy, your honesty is corrupt.
Richard Lucassen
2010-10-15 08:12:39 UTC
Permalink
On Thu, 14 Oct 2010 23:55:41 +0200
Post by Stef
Post by Richard Lucassen
Maar wat je doet is niet echt netjes, je krijgt allemaal icmp
redirects op je 192.168.47.0/24 netwerk nu tenzij je ieder station
daar van de route vertelt. Het werkt echter wel. Beter is een eth2
te configgen met daarachter het apparaat naar 192.168.0.0/16 en
10.0.0.0/8 gaat. Dan heb je maar 1 gateway op je interne LAN en
regelt de Linuxdoos de routering, firewalling e.d.
De linuxdoos gebruikt deze routering alleen om zelf naar buiten (via
eth0) en naar de tunnels (via eth1) te kunnen. Die tunnels worden
weer door een ciscodoosje geregeld dat naast die tunnels ook
firewall/gateway is. De normale netwerk clients gebruiken het
ciscodoosje als gateway en de linuxdoos alleen als locale server.
Forwarding staat nog wel aan op de linuxdoos, maar zou eigenlijk nu
uit kunnen (hij is gateway geweest, maar die taak is dus recent
overgenomen door de ciscodoos).
Dus mij lijkt dat alles zo netjes is, of zie ik dat verkeerd? Enig
punt is wel dat nu de linux- en ciscodoos in feite parrallel aan
elkaar tussen het internet en het 192.168.47.0 netwerk staan.
Op zich zou ik clients ook de linuxdoos als default gateway kunnen
opgeven, maar dan moeten ze wel weten dat de ciscodoos de gateway
is voor de overige 192.168.x.0 netwerken. Doe je dat laatste niet,
dan krijg je toch pas de situatie die jij schetst?
Klopt, maar je ziet regelmatig meerdere gateways op een lokaal netwerk
en dat is smerig. Vandaar de opmerking ;-)
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
Stef
2010-10-15 12:16:42 UTC
Permalink
In nl.comp.os.linux.netwerken,
Post by Richard Lucassen
Klopt, maar je ziet regelmatig meerdere gateways op een lokaal netwerk
en dat is smerig. Vandaar de opmerking ;-)
Meerdere gateways per definitie smerig? Je krijgt dat inderdaad snel
als je bijvoorbeeld een wireless router op een bestaand netwerk
inprikt. Ik zie daar niet zo'n probleem in, maar ik heb er dan ook
geen verstand van. ;-)

Aangenomen natuurlijk dat de clients weten welke gateway voor welk
netwerk bedoeld is.


Dus de volgende situatie lijkt mij (als leek) netjes:

192.168.47.0 192.168.48.0
Client <----------------------> Gateway 48 <-------------->
<---------------+
|
| 192.168.49.0
+------> gateway 49 <-------------->




Deze situatie zou ik inderdaad ook als 'niet netjes' omschrijven:

192.168.47.0 192.168.48.0
Client <----------------------> Gateway 48 <-------------->
+------>
|
| 192.168.49.0
+------> gateway 49 <-------------->


Mee eens, of is er toch ook bezwaar tegen de eerste situatie?
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Signs of crime: screaming or cries for help.
-- The Brown University Security Crime Prevention Pamphlet
Richard Lucassen
2010-10-15 14:59:21 UTC
Permalink
On Fri, 15 Oct 2010 14:16:42 +0200
Post by Stef
192.168.47.0 192.168.48.0
Client <----------------------> Gateway 48 <-------------->
<---------------+
|
| 192.168.49.0
+------> gateway 49 <-------------->
192.168.47.0 192.168.48.0
Client <----------------------> Gateway 48 <-------------->
+------>
|
| 192.168.49.0
+------> gateway 49 <-------------->
Ik zie het verschil niet zo tussen de twee ASCII art tekeningen...
Post by Stef
Mee eens, of is er toch ook bezwaar tegen de eerste situatie?
Wat dacht je van dit?:

192.168.47.0 192.168.48.0
Client <----------------------> Gateway <-------------->
|
|
| 192.168.49.0
(tunnel)gateway naar 49 <--------->


Voor het 47 netwerk heb je nu maar 1 gateway, die zoekt wel weer uit
waar 48 en 49 zitten, die routeert de zaak meteen. En vice versa. Wel zo
netjes. Als de gateway nu ook kan firewallen kun je de diverse
verkeerstromen goed regelen. Ook kun je er nu een default gateway naar
het internet (of meerdere) aan knopen.

R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
Stef
2010-10-15 16:05:00 UTC
Permalink
In nl.comp.os.linux.netwerken,
Post by Richard Lucassen
On Fri, 15 Oct 2010 14:16:42 +0200
Post by Stef
192.168.47.0 192.168.48.0
Client <----------------------> Gateway 48 <-------------->
<---------------+
|
| 192.168.49.0
+------> gateway 49 <-------------->
192.168.47.0 192.168.48.0
Client <----------------------> Gateway 48 <-------------->
+------>
|
| 192.168.49.0
+------> gateway 49 <-------------->
Ik zie het verschil niet zo tussen de twee ASCII art tekeningen...
Situatie 1: Client kan beide gateways zelf benaderen en gebruikt
voor elk netwerk de juiste gateway.

Situatie 2: Client kent alleen gateway 48 en verkeer naar '49'
moet dus van client via GW48 (die GW49 wel kent) naar GW49 hoppen.
Verkeer terug zal overigens dan wel direct van GW49 naar client
gaan. (zo'n situatie heb ik vorige week per ongeluk gecreerd:
Verkeer heen via GW1 en tunnel 1 en terug via GW2 en tunnel 2.
Werkt wel, maar verdient geen schoonheidsprijs lijkt me)
Post by Richard Lucassen
Post by Stef
Mee eens, of is er toch ook bezwaar tegen de eerste situatie?
192.168.47.0 192.168.48.0
Client <----------------------> Gateway <-------------->
|
|
| 192.168.49.0
(tunnel)gateway naar 49 <--------->
Voor het 47 netwerk heb je nu maar 1 gateway, die zoekt wel weer uit
waar 48 en 49 zitten, die routeert de zaak meteen. En vice versa. Wel zo
netjes. Als de gateway nu ook kan firewallen kun je de diverse
verkeerstromen goed regelen. Ook kun je er nu een default gateway naar
het internet (of meerdere) aan knopen.
Zo zit de zaak nu ook, voor de 'normale' clients, in elkaar. De enkele
gateway is dat ciscodoosje met 2 tunnels en de internet verbinding. De
linuxdoos (geen 'normale' client) maakt voor de tunnels nu ook gebruik
van het ciscodoosje. Alleen heeft hij ook nog een directe verbinding
naar het internet. Die zou ik ook via het ciscodoosje kunnen laten lopen
en de externe verbinding van de linuxdoos af halen.

Ik zit dan wel met 1 probleem: Ik wil de linuxdoos ook van buiten kunnen
benaderen (webserver). Dat zou natuurlijk weer kunnen via port-forwarding
op de ciscodoos. Maarja, dan heb je gelijk geen voordeel meer van het
beschikbaar hebben van meerdere externe ip's en het instellen van een
port forward op die ciscodoos is m.i. ook niet erg doorzichtig.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Chess tonight.
Richard Lucassen
2010-10-15 22:41:14 UTC
Permalink
On Fri, 15 Oct 2010 18:05:00 +0200
Post by Stef
Situatie 1: Client kan beide gateways zelf benaderen en gebruikt
voor elk netwerk de juiste gateway.
Dat kan, maar als je 1000 clients op een netwerk hebt is dat lastig
lijkt me ;-)
Post by Stef
Situatie 2: Client kent alleen gateway 48 en verkeer naar '49'
moet dus van client via GW48 (die GW49 wel kent) naar GW49 hoppen.
Verkeer terug zal overigens dan wel direct van GW49 naar client
Verkeer heen via GW1 en tunnel 1 en terug via GW2 en tunnel 2.
Werkt wel, maar verdient geen schoonheidsprijs lijkt me)
Maar als er een stateful firewall tussen staat zal die de onbekende
packets gaan droppen. Het 49 netwerk zal zijn weg ook via de 48 moeten
terugvinden naar het 47 netwerk. Pas dan gaat het goed. Ook met
stateful firewall
Post by Stef
Post by Richard Lucassen
Voor het 47 netwerk heb je nu maar 1 gateway, die zoekt wel weer uit
waar 48 en 49 zitten, die routeert de zaak meteen. En vice versa.
Wel zo netjes. Als de gateway nu ook kan firewallen kun je de
diverse verkeerstromen goed regelen. Ook kun je er nu een default
gateway naar het internet (of meerdere) aan knopen.
Zo zit de zaak nu ook, voor de 'normale' clients, in elkaar. De enkele
gateway is dat ciscodoosje met 2 tunnels en de internet verbinding. De
linuxdoos (geen 'normale' client) maakt voor de tunnels nu ook gebruik
van het ciscodoosje. Alleen heeft hij ook nog een directe verbinding
naar het internet. Die zou ik ook via het ciscodoosje kunnen laten
lopen en de externe verbinding van de linuxdoos af halen.
Dat lijkt me wel zuiverder als ik het goed snap
Post by Stef
Ik zit dan wel met 1 probleem: Ik wil de linuxdoos ook van buiten
kunnen benaderen (webserver). Dat zou natuurlijk weer kunnen via
port-forwarding op de ciscodoos. Maarja, dan heb je gelijk geen
voordeel meer van het beschikbaar hebben van meerdere externe ip's en
het instellen van een port forward op die ciscodoos is m.i. ook niet
erg doorzichtig.
Ik zou een webserver niet op je interne LAN zetten maar in een DMZ
(DeMilitarized Zone). Als dat ding door een botnet of een andere idioot
onder handen wordt genomen kan het ding verder zelf nergens naartoe,
die loopt tegen firewall rules aan. Een DMZ kun je zien als een netwerk
50 dat je op een aparte kaart zet en dat je flink firewall't.

Ik weet niet wat voor cisco doos het is, maar die kunnen uitstekend met
meerdere ip's overweg lijkt me zo.

R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
Stef
2010-10-15 23:35:13 UTC
Permalink
In nl.comp.os.linux.netwerken,
Post by Richard Lucassen
On Fri, 15 Oct 2010 18:05:00 +0200
Post by Stef
Situatie 1: Client kan beide gateways zelf benaderen en gebruikt
voor elk netwerk de juiste gateway.
Dat kan, maar als je 1000 clients op een netwerk hebt is dat lastig
lijkt me ;-)
Met een stuk of 5 wil het allemaal nog wel heb ik gemerkt. :-)

Ik heb ook nog even in dhcp.conf gezocht of ik het de DHCP server
kon laten doen, maar daar kwam ik zo snel niet uit. Dus ik heb
het toen maar even handmatig gedaan en was ook tijdelijk. Alles
werkt nu weer netjes op 1 gateway (behalve onderstaande linuxdoos)
Post by Richard Lucassen
Post by Stef
Zo zit de zaak nu ook, voor de 'normale' clients, in elkaar. De enkele
gateway is dat ciscodoosje met 2 tunnels en de internet verbinding. De
linuxdoos (geen 'normale' client) maakt voor de tunnels nu ook gebruik
van het ciscodoosje. Alleen heeft hij ook nog een directe verbinding
naar het internet. Die zou ik ook via het ciscodoosje kunnen laten
lopen en de externe verbinding van de linuxdoos af halen.
Dat lijkt me wel zuiverder als ik het goed snap
OK, ik zal daar nog eens over nadenken.
Post by Richard Lucassen
Ik zou een webserver niet op je interne LAN zetten maar in een DMZ
(DeMilitarized Zone). Als dat ding door een botnet of een andere idioot
onder handen wordt genomen kan het ding verder zelf nergens naartoe,
die loopt tegen firewall rules aan. Een DMZ kun je zien als een netwerk
50 dat je op een aparte kaart zet en dat je flink firewall't.
Tja, ik wil er van binnenuit ook nog bij kunnen. Het is slechts een klein
thuisnetwerk en de server heeft dus meerder functies die ook (of alleen)
van binnen bereikbaar moeten zijn,

Momenteel staat ingaand alleen poort 80 open in de firewall en er is
geen mogelijkheid data te uploaden. Is er dan een reeel risico dat
er nog iets mogelijk is?
Post by Richard Lucassen
Ik weet niet wat voor cisco doos het is, maar die kunnen uitstekend met
meerdere ip's overweg lijkt me zo.
Dat zou ie inderdaad moeten kunnen. Volgens mij kan hij ook zoiets als
IP forwarden i.p.v. port forwarden. Configuratie is nu voor mij gedaan
en ik heb er wel toegang toe maar wil er liefst niet te veel aan
sleutelen. En als je linux firewall en routing gewent bent is zo'n
cisco wel even wennen zeg. Is overigens een ASA 5505.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

That's always the way when you discover something new; everyone thinks
you're crazy.
-- Evelyn E. Smith
Richard Lucassen
2010-10-16 08:27:31 UTC
Permalink
On Sat, 16 Oct 2010 01:35:13 +0200
Post by Stef
Post by Richard Lucassen
Ik zou een webserver niet op je interne LAN zetten maar in een DMZ
(DeMilitarized Zone). Als dat ding door een botnet of een andere
idioot onder handen wordt genomen kan het ding verder zelf nergens
naartoe, die loopt tegen firewall rules aan. Een DMZ kun je zien
als een netwerk 50 dat je op een aparte kaart zet en dat je flink
firewall't.
Tja, ik wil er van binnenuit ook nog bij kunnen. Het is slechts een
klein thuisnetwerk en de server heeft dus meerder functies die ook
(of alleen) van binnen bereikbaar moeten zijn,
Momenteel staat ingaand alleen poort 80 open in de firewall en er is
geen mogelijkheid data te uploaden. Is er dan een reeel risico dat
er nog iets mogelijk is?
Ook over een enkele poort 80 is zo'n webserver te rooten bij de juiste
vulnerabilty. En als ze 'm rooten, dan is het zaak dat ze er zo weinig
mogelijk lol van hebben, dus knijp het ding naar buiten en ook
naar binnen helemaal af. In een DMZ staan machines die geroot zijn en
die zoveel mogelijk schade willen aanbrengen. Zo moet je een DMZ zien.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
houghi
2010-10-16 09:02:33 UTC
Permalink
Post by Stef
Tja, ik wil er van binnenuit ook nog bij kunnen. Het is slechts een klein
thuisnetwerk en de server heeft dus meerder functies die ook (of alleen)
van binnen bereikbaar moeten zijn,
Ik zit met de zelfde situatie.
Post by Stef
Momenteel staat ingaand alleen poort 80 open in de firewall en er is
geen mogelijkheid data te uploaden. Is er dan een reeel risico dat
er nog iets mogelijk is?
Ja. Laatst zelf nog meegemaakt. Wel door mijn eigen domme fout. Ik had
wel phpMyAdmin geinstaleerd, maar niet geconfigureerd. Dat wil dus
zeggen dat het standaard paswoord er nog op stond.

Als je iets als php hebt draaien, dan moet je zorgen dat het veilig is.
Zorg ook dat zaken die niet van buiten te zien hoeven zijn ook niet
bereikbaar zijn.

Wat ik gedaan heb zijn de volgende zaken met mijn LAMP:
1) Enkel maar zaken die van buiten bereikbaar moeten zijn ook bereikbaar
gemaakt.
2) Directories die geen php nodig hebben, php afgezet. Kijk maar naar
http://houghi.eu/s/info.php
3) Error 404 omgezet naar een forward naar een externe site. Kijk maar
naar http://houghi.eu
4) De zaken die intern beschikbaar moeten zijn in een heel andere
directory gezet. /srv/www/htdocs en /srv/local, aangezien srv wel een
aparte dedicated partitie is.
5) vhost met naam opgezet zodat ik naar http://lokaal ga (Dus ook hosts
file aanpassen)
6) Die lokaal enkel maar toegang vanaf lokale netwerk (zelfs enkel maar
twee machines, niet een derde) via de Apache configuratie
7) Nog eens gaan kijken wat er echt allemaal vanuit buiten beschikbaar
moet zijn.

Voor dat laatste ben ik aan twee directories gekomen.
Intern heb ik nu verschillende Virtual Hostings
1) Een werkende, waar ik zaken heb staan zoals phpMyAdmin en nog wat
zaken waarvan ik ze wil hebben en die enge dingen doen als:
<?php
$data=$_GET['c'];
if($data) exec("/usr/bin/ivtv-tune --device=/dev/video0 -teurope-west -f $data");
?>
Yep, da's eng en wil je niet naar de buitenwereld laten zien. Die is
bereikbaar via http://local voor 2 machines
2) Kopie van mijn site houghi.org om zaken eerst te testen voor ik ze
upoad. Bereikbaar via http://houghi voor 2 machines
3) Test site om te klooien. Bereikbaar via http://test en enkel voor
localhost.
4) Mijn 'echte' lokale site. Bereikbaar via http://houghi.eu, maar dan
enkel die directories die ik wil dat bereikbaar zijn. De rest is een
forward naar http://houghi.org

Als je geen php of dergelijke hebt, dan is het allemaal een stuk minder
erg. Maar zorg hoe dan ook dat enkel dat wat echt nodig is ook echt
vanuit buiten bereikbaar is. Zo had ik heel vroeger ook een webmail er
op staan, maar nu lees ik mijn mail gewoon via ssh en mutt.

houghi
--
Post by Stef
Artiest : Prince
Lied : money dont matter 2 night
Album : The Very Best Of Prince
Arnold
2010-10-15 20:29:46 UTC
Permalink
Post by Stef
In nl.comp.os.linux.netwerken,
Post by Richard Lucassen
Klopt, maar je ziet regelmatig meerdere gateways op een lokaal netwerk
en dat is smerig. Vandaar de opmerking ;-)
Meerdere gateways per definitie smerig? Je krijgt dat inderdaad snel
als je bijvoorbeeld een wireless router op een bestaand netwerk
inprikt. Ik zie daar niet zo'n probleem in, maar ik heb er dan ook
geen verstand van. ;-)
Alternatief -als het maar om een paar clients gaat en het een standaard
paar-tientjes-wireless-router is - is dat je de DHCP server uitzet en de
uplink in een LAN poort prikt ipv de WAN poort. Dan kunnen mobiele clients
gewoon in de bestaande netwerkconfig mee en heb je geen gedoe met gateways
en aparte subnets. Sommige routers hebben ook een ingebouwde
accesspoint-only mode die misschien hetzelfde doet.
Stef
2010-10-15 23:43:39 UTC
Permalink
In nl.comp.os.linux.netwerken,
Post by Arnold
Post by Stef
Meerdere gateways per definitie smerig? Je krijgt dat inderdaad snel
als je bijvoorbeeld een wireless router op een bestaand netwerk
inprikt. Ik zie daar niet zo'n probleem in, maar ik heb er dan ook
geen verstand van. ;-)
Alternatief -als het maar om een paar clients gaat en het een standaard
paar-tientjes-wireless-router is - is dat je de DHCP server uitzet en de
uplink in een LAN poort prikt ipv de WAN poort. Dan kunnen mobiele clients
gewoon in de bestaande netwerkconfig mee en heb je geen gedoe met gateways
en aparte subnets. Sommige routers hebben ook een ingebouwde
accesspoint-only mode die misschien hetzelfde doet.
Dat kan nou net met die van mij niet. :-(
LAN poort gebruiken werkt, en je hebt er dan voor het bedrade deel een
switch bij. Wireless blijft echter altijd ander subnet. Mijn type heeft
nou net niet de optie om hem als access point te schakelen. Er schijnt
wel alternatieve firmware te bestaan die dat wel toelaat. Het gaat
overigens om een Asus WL-520GC (de GU schijnt het wel te kunnen).
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

"Linux: the operating system with a CLUE...
Command Line User Environment".
(seen in a posting in comp.software.testing)
Loading...