iptables op interface controleren

[Mfpower]

Ik heb twee nics in m'n bak zitten; eth0 en eth1. Ze zijn beiden goed geconfigureerd en hangen ook beide DIRECT aan het Internet. Geen masq of nat of wat dan ook. Ze hebben ook beide een uniek IP, wat door dhcp nog wel eens verandert.

Nu wil ik een aantal services draaien op eth0 (ftp, ssh, ident, en een port range voor pasv) en een webserver op eth1. Ik heb deze code in m'n firewall:

code:

# Default policy
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Localhost mag alles
iptables -A INPUT -p ALL -i lo -j ACCEPT
iptables -A OUTPUT -p ALL -o lo -j ACCEPT

# Uitgaand verkeer vanaf de internet interface mag voor nu
iptables -A OUTPUT -p ALL -o eth0 -j ACCEPT
iptables -A OUTPUT -p ALL -o eth1 -j ACCEPT

# Open ports
iptables -A INPUT -p tcp -i eth0 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 21 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 113 -j ACCEPT
iptables -A INPUT -p tcp -i eth1 --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 40000:50000 -j ACCEPT

Maar als ik dit doe accepteert ie op beide interfaces alles. Hoe kan dit nou? Zie ik iets heel lulligs over het hoofd?

[_JGC_]

Waar leeg jij je bestaande firewall? als jou distributie die je niet eens wilt noemen een leuke iptables -A INPUT -j ACCEPT of iets wat lijkt in de firewall heeft staan, heeft die altijd nog voorrang boven je standaard DROP policy.

[Mfpower]

_JGC_ schreef op 16 december 2003 @ 15:19:
Waar leeg jij je bestaande firewall? als jou distributie die je niet eens wilt noemen een leuke iptables -A INPUT -j ACCEPT of iets wat lijkt in de firewall heeft staan, heeft die altijd nog voorrang boven je standaard DROP policy.

Mijn distributie is debian 3.0 stable met een 2.4.23 kernel. Ik ben m'n firewall natuurlijk druk aan het testen en ik leeg 'm tussentijds met een scriptje wat ik ergens vandaan heb. En dat werkt wel. Want hij dropt alle poorten behalve die ik dus zelf openzet. Alleen m'n openstaande ports zijn vanaf elke interface bereikbaar.

[TrailBlazer]

tik een iptables -nvL in en post dat

[Mfpower]

TrailBlazer schreef op 16 december 2003 @ 15:27:
tik een iptables -nvL in en post dat

ok:

code:

arutha:/etc/init.d# iptables -nvL
Chain INPUT (policy DROP 64 packets, 8783 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          icmp type 0
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          icmp type 3
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          icmp type 5
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          icmp type 8
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          icmp type 11
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  *      *       224.0.0.0/8          0.0.0.0/0
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0          tcp flags:!0x16/0x02 state NEW
  362  314K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:22
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:21
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:113
    0     0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:80
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0          tcp dpts:40000:50000
    0     0 ACCEPT     tcp  --  eth0   *       CENSORED-IP 0.0.0.0/0          tcp dpt:901
    0     0 ACCEPT     tcp  --  eth0   *       CENSORED-IP      0.0.0.0/0          tcp dpts:137:139
    0     0 ACCEPT     udp  --  eth0   *       CENSORED-IP      0.0.0.0/0          udp dpts:137:139

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 1 packets, 100 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
  188  8508 ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      eth1    0.0.0.0/0            0.0.0.0/0

[PolarWolf]

Mfpower schreef op 16 december 2003 @ 15:06:
Maar als ik dit doe accepteert ie op beide interfaces alles. Hoe kan dit nou? Zie ik iets heel lulligs over het hoofd?

Hoe heb je gecontroleerd of op beide interfaces alles wordt geaccepteerd? Heb je vanaf het internet een scan uitgevoerd?
Als ik deze firewall zo zie, en ook de output die je net hebt gepost zou alles wel zo'n beetje goed moeten zijn.

Is er overigens een hele goede reden waarom je 40000-50000/tcp open hebt staan?

Maak het jezelf makkelijk, en zet boven in je script ook een paar -F regels om de firewall te flushen. Dan weet je zeker dat je vers begint.

[Mfpower]

Nou ik ben een beetje verder maar nog niet helemaal. Zoals al blijkt uit eerdere problemen lijkt m'n systeem geen onderscheid te maken tussen eth0 en eth1.
Ik heb m'n firewall zo aangepast dat hij nu filtert op IP adressen, en dat lijkt beter te werken. Toch raar. Maar goed, er is nu een ander probleem wat aan het eerste ten grondslag ligt. Misschien een ander topic maar ik ga er hier maar op door:

Ik zal eerst de situatie uitleggen. Ik ben zo'n gelukkig iemand met een directe LAN verbinding (dus geen kabel of adsl) naar het internet. Ik heb hier een switch met een uplink in de socket in de muur. Daar hangen twee pc's aan. M'n workstation en m'n server. M'n server is het probleemgeval met 2 nics.

Ik krijg keurig 3 ip adressen toegewezen (1 voor workstation, 2 voor server) via dhcp.

Vanaf m'n workstation en vanaf lo lijkt alles keurig te werken. Ik had de webserver draaien op eth1 en de rest op eth0. Ik kwam er prima bij en het draaide als een zonnetje. Echter, andere mensen komen er niet op! Ik was enigszins verbaasd aangezien mensen wel op m'n shell konden komen. Wat blijkt; op de een of andere manier werkt van buitenaf maar 1 nic tegelijk. Als ik eerst eth0 start en dan eth1 krijg ik bij eth1 een bericht:

SIOCADDRT: File exists.

Als ik eerst eth1 start en dan eth0 krijg ik het bericht ook, maar dan van eth0. De nic die ik dus het laatste start die doet het niet! Tenminste hij is vanaf buitenaf niet bereikbaar. Hij krijgt wel een ip van dhcp. En vanaf m'n workstation die in dezelfde switch geplugd is lijkt het WEL allemaal goed te werken.

Ik start m'n nics met ifup overigens en beide zijn in de interfaces file goed geconfigd voor dhcp.

Wie snapt dit nog?

[PolarWolf]

Mfpower schreef op 17 december 2003 @ 16:03:
Wie snapt dit nog?

Ik wel.

Je hebt twee NICs in een switch gestopt, die allebei een adres krijgen uit dezelfde DHCP pool, met hetzelfde gateway adres. etc.
Heb je de routing tabel wel eens bekeken? Volgens mij heb jij een gigantische routing knoop. Kijk maar eens wat je default gateway is, en nog belangrijker, aan welke interface die hangt. Tenzij je met beide interfaces aan totaal andere netwerken hangt zal wat jij wil volgens mij nooit gaan lukken. En dan nog wordt het lastig met betrekking tot routing vanuit je server.

[Mfpower]

Hmm. Ok misschien ben ik wel een beetje noob in deze .

Maar kun je me ook uitleggen waarom het dan niet werkt? Ik dacht dat een interface gewoon naar z'n ip zou luisteren en dat verkeer voor een bepaald IP gewoon keurig hierheen gerouterd wordt. Gaat het bij de externe router fout (waar ik geen controle over heb)?.

Er staat hier namelijk nog een pc met wel 4 nics (wel aparte sockets in de muur). En dat werkt. Daarbij zijn er ook kamers met wel 4 pc's op een switch met 1 socket in de muur. Dan zou mijn combinatie toch wel moeten werken?

Ow, en nog een ding wat ik vaag vind. Computers op de switch of in het gebouw kunnen wel de server op beide nics bereiken.

[ Voor 12% gewijzigd door Mfpower op 17-12-2003 16:40 ]

[Verwijderd]

Als iemand jou van buiten op één van de twee nics probeert te benaderen, is het niet te garandeeren, dat het retour verkeer vanaf dezelfde netwerkkaart komt.
het is maar net welke nic op dat moment het minst belast is, en dus het gemakkelijkste naar de gateway kan.

mijns inziens heb je twee netwerkkaarten alleen nodig als je twee verschillende netwerken wilt benaderen. ( of waneer je ze linkt, en één virtuele netwerkkaartmaakt met dubbele snelheid )

mag ik je dus vragen waarom je twee nics gebruikt om naar het internet te gaan vanaf een server?

en zoals hierboven gevraagt, post inderdaad je route tabel eens

ow, dat computers die in het gebouw staan, de server wel goed kunnen benaderen, komt omdat dat nog voor de gateway gebeurt.

[ Voor 10% gewijzigd door Verwijderd op 17-12-2003 16:48 ]

[PolarWolf]

Mfpower schreef op 17 december 2003 @ 16:31:
Hmm. Ok misschien ben ik wel een beetje noob in deze .

Maar kun je me ook uitleggen waarom het dan niet werkt? Ik dacht dat een interface gewoon naar z'n ip zou luisteren en dat verkeer voor een bepaald IP gewoon keurig hierheen gerouterd wordt. Gaat het bij de externe router fout (waar ik geen controle over heb)?.

Om harde uitspraken te kunnen doen zou ik je routing tabel moeten zien, en ook die van de die PC met 4 NICs. Het gaat er ook niet om of en hoe het verkeer op jou PC terecht komt, dat gaat wel goed, maar hoe het wordt teruggestuurd.
Stel er komt verkeer binnen op NIC2, maar je default gateway naar het internet staat via NIC1. Het antwoord op verkeer op NIC2 zal dus je PC verlaten via NIC1. Dit kun je controleren met bijvoorbeeld tcpdump. tcpdump -ni eth0, en maak wat requests op NIC2. Kijk of je het antwoord hierop voorbij ziet komen.

Volgens mij is er wel een oplossing. Ofwel met iproute2 ofwel een beetje slim NAT'ten met iptables. Hiervoor heb ik echter documentatie nodig die ik hier even niet heb (zit op m'n werk). Kijk alvast maar eens op http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN268

Zo-wie-zo goed om te lezen wanneer je met dit soort geklooi bezig bent.

[Mfpower]

Ok hier is route tabel. Ik heb de IP adressen eruit gevist:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xxx.xxx.xxx.xxx   *               255.255.254.0   U     0      0        0 eth0
xxx.xxx.xxx.xxx   *               255.255.254.0   U     0      0        0 eth1
default         xxx.xxx.xxx.xxxx   0.0.0.0         UG    0      0        0 eth0

Gateway lijkt inderdaad alleen over eth0 te gaan. De reden dat ik dit wil is omdat ik meerdere services op een box draai die ik nou niet direct met elkaar wil associeren.

Ik weet inderdaad van die andere server met 4 ip's (met overigens zelfde routing tabel) dat ze daar iets met iprouting gedaan hebben om ftp traffic te verdelen.

Edit: nog niet alle reacties gelezen.

[ Voor 8% gewijzigd door Mfpower op 17-12-2003 16:56 ]

[PolarWolf]

Mfpower schreef op 17 december 2003 @ 16:53:
Ok hier is route tabel. Ik heb de IP adressen eruit gevist:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xxx.xxx.xxx.xxx   *               255.255.254.0   U     0      0        0 eth0
xxx.xxx.xxx.xxx   *               255.255.254.0   U     0      0        0 eth1
default         xxx.xxx.xxx.xxxx   0.0.0.0         UG    0      0        0 eth0

Gateway lijkt inderdaad alleen over eth0 te gaan. De reden dat ik dit wil is omdat ik meerdere services op een box draai die ik nou niet direct met elkaar wil associeren.

Ik weet inderdaad van die andere server met 4 ip's (met overigens zelfde routing tabel) dat ze daar iets met iprouting gedaan hebben om ftp traffic te verdelen.

Edit: nog niet alle reacties gelezen.

Okay, ik heb dat hoofdstuk uit LARTC nog eens gelezen, en volgens mij is dat bruikbaar.
Het enige probleem dat ik kan bedenken is dat "provider1" en "provider2" uit het voorbeeld in jou geval een en dezelfde zijn. Het gaat echter om de regel:

This set of commands makes sure all answers to traffic coming in on a particular interface get answered from that interface.

Volgens mij moet je het gewoon eens proberen (wel eerst drie keer lezen wat er precies staat). Installeer iproute2 maar eens, maak twee nieuwe tabellen aan in /etc/iproute2/rt_tables, en voeg wat routes toe volgens het voorbeeld, en met het feit in gedachten dat "provider1" en "provider2" in jou geval dezelfde zijn.

Success.

[Mfpower]

Bedankt voor alle reacties ik heb er echt wat aan gehad. Ik gebruik nu iproute om de boel goed door te lussen. En het werkt als een trein, precies wat ik voor ogen had!

[PolarWolf]

Mfpower schreef op 17 december 2003 @ 18:58:
Bedankt voor alle reacties ik heb er echt wat aan gehad. Ik gebruik nu iproute om de boel goed door te lussen. En het werkt als een trein, precies wat ik voor ogen had!

For the record, wat was nou precies de oplossing?