IPables firewall

Pagina: 1
Acties:
  • 130 views sinds 30-01-2008
  • Reageer

  • Haranaka
  • Registratie: September 2000
  • Laatst online: 07-06 23:13
Ik krijg het maar niet voorelkaar :(
Ik kan wel ftpen van mijn andere pc in intern netwerk, maar van buiten af ho maar. Het zelfde met ssh.

rc.firewall
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
#!/bin/bash

#flush old, del firewallchian if exists
/sbin/iptables -F
/sbin/iptables -F -t nat
/sbin/iptables -X firewall

#masq:
/sbin/iptables -A POSTROUTING -o eth1 -s 192.168.1.0/24 -t nat -j MASQUERADE
/sbin/iptables -P FORWARD ACCEPT

#setup firewall chain:
/sbin/iptables -N firewall
/sbin/iptables -A firewall -j LOG --log-level info --log-prefix "Firewall:"
/sbin/iptables -A firewall -j DROP

#local host accpeteren:
/sbin/iptables -A INPUT -s 127.0.0.1/32 -i ACCEPT
#Haranaka 2 accepteren:
/sbin/iptables -A INPUT -s 192.168.1.2/32 -d 0/0 -j ACCEPT

#Domain name resonving = ??
/sbin/iptables -A INPUT -p udp --source-port 53 -i ACCEPT
/sbin/iptables -A INPUT -p tcp --source-port 53 -i ACCEPT

#########################
##  Poorten forwarden  ##
#########################

#CS servers winbak
/sbin/iptables -A PREROUTING -t nat -p udp -d 129.125.103.216 --dport 27025 -j DNAT --to 192.168.1.2:27025
/sbin/iptables -A PREROUTING -t nat -p udp -d 129.125.103.216 --dport 27017 -j DNAT --to 192.168.1.2:27017

#koe proxy Haranaka winbak:
/sbin/iptables -A PREROUTING -t nat -p tcp -d 129.125.103.216 --dport 2065 -j DNAT --to 192.168.1.2:2065
#schaak:
/sbin/iptables -A PREROUTING -t nat -p tcp -d 129.125.103.216 --dport 6667 -j DNAT --to 192.168.1.2:6667
/sbin/iptables -A PREROUTING -t nat -p tcp -d 129.125.103.216 --dport 28800:29000 -j DNAT --to 192.168.1.2:28800-29000

#########################
##  Poorten openen     ##
#########################


#linux CS server;
/sbin/iptables -A INPUT -p udp --destination-port 27020 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --destination-port 7002 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --destination-port 7002 -j ACCEPT

#linux PB server:
/sbin/iptables -A INPUT -p udp --destination-port 24347 -j ACCEPT
/sbin/iptables -A INPUT -p udp --destination-port 24348 -j ACCEPT

# Apache Webserver
/sbin/iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT



#ftp linuxbak; (passief en non kunnen naast elkaar, passief weinig gebruikt.
/sbin/iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
#passive ftp:
/sbin/iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
#non-passive ftp:
/sbin/iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --sport 20 -m state --state ESTABLISHED -j ACCEPT

#ssh:
/sbin/iptables -A INPUT -p tcp --destination-port 22 -j ACCEPT

#proxys 
/sbin/iptables -A INPUT -p tcp --destination-port 2064 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --destination-port 2060 -j ACCEPT

#########################
##  Rest tegen de muur ##
#########################

/sbin/iptables -A INPUT -p icmp -j firewall
/sbin/iptables -A INPUT -p tcp --syn -j firewall
/sbin/iptables -A INPUT -p udp -j firewall

#einde

...


Verwijderd

Effe iptraf (zie freshmeat) installeren, dan zie je zo waar het probleem zit.
P.S. ik zie daar staan, accept input tcp sourceport 53, maar iedereen kan je dan dus overal connecten mits ze maar sourceport 53 gebruiken?

  • Sjonny
  • Registratie: Maart 2001
  • Laatst online: 15:05

Sjonny

Fratser

port 53 open is idd niet zo slim. Mik em alleen open voor je 192 netwerk, en niet voor internet als je al een DNS server draait, anders kan het zowiezo wel dicht.
Let ook op je --dport en --sport params voor poort 21. Je haalt wat door elkaar volgens mij..

The problem is in the part of your brain that handles intelligence.


  • Haranaka
  • Registratie: September 2000
  • Laatst online: 07-06 23:13
stomme vraag: hoe zet ik 53 alleen open voor intern netwerk?

Over de poort 21, heb ik uit deze thread:
[topic=172058]

...


Verwijderd

Ik combineer dns/firewall als volgt,

Ik laat alle interne pc's hun dns requests naar de server sturen, die ze weer doorstuurt naar de nameservers van m'n provider. (in named.conf instellen)
Van buitenaf zet ik 53 tcp en udp open, voor m'n zonefiles.
En dan laat ik named z'n requests naar buiten sturen met sourceport 53 (wederom named.conf), zodat replies ook gewoon door de firewall kunnen.

Je zou, als je zelf geen zonefiles hebt, je inkomende dns kunnen beperken tot de ip's van de servers van je provider.

Ik zou je wel aanraden te beginnen met een hele simpele firewall, en die steeds verder uit te breiden... dan heb je voor jezelf meer overzicht en als je weer wat hebt toegevoegd en het geeft problemen weet je meteen waar je die moet zoeken.

Verwijderd

Okee, ten eerste: Is de module ip_contrack en ip_contrack_ftp geladen (of in de kernel gebakken) :? Zo niet meteen doen.

Ten tweede: check die ftp regels nog maar eens goed met de door mij gegeven regels in het andere draadje. Ik haalde er in een oogopslag al een fout uit. (Ff snel gekeken in het andere draadje en daar stond het goed ).

Ten derde: Laat named (ongeacht je firewall) alleen binden aan je interne IP en niet aan je externe IP

Ten vierde: (ik weet niet of dit zo is) Laat named nooit als root draaien!!!!

Ten vijfde: Je kan iptables-rulesets laten gelden voor slechts bepaalde nic's door de interface erbij op te geven.
Voor INPUT rules doe je dit met de -i switch, voor OUTPUT rules met de -o switch.
Dus stel voor dat je interne NIC eth1 is, dan kun je die DNS-regels zo aanpassen, dat je er hetvolgende bijzet: "-i eth1"

Verwijderd

Werkt established/related met alle protocollen?
Dan laat je dus gewoon alleen alle est/rel binnen en heb je een vette firewall?
P.S. is named alleen in intern interface binden een precaution? of heeft het ook nog speciaal nut?

Verwijderd

De state optie werkt met tcp/ip d.e.s.d.a. de ip_contrack module geladen is.

Uiteraard moet je niet alleen established en related toelaten als je services draait op je computertje (immers er moeten ook nieuwe connecties opgebouwd worden ;) ).

Meer info hiervover kun je vinden in de man-pages van iptables (als het goed is) en anderes in een van de HOWTO's op bijvoorbeeld netfilter.samba.org.

Het binden van named aan alleen de interne interface is gewoon een veiligheids maatregel. Ook al heb je dan geen (goede) firewall draaien, dan reageerd named niet op queries die binnen komen op de externe interface. Dit maakt het al een stuk moeilijker (niet onmogelijk) om in te breken via named.

Verwijderd

Op maandag 02 juli 2001 17:03 schreef nelske het volgende:
[..]
Uiteraard moet je niet alleen established en related toelaten als je services draait op je computertje (immers er moeten ook nieuwe connecties opgebouwd worden ;) ).
M'n interne net wordt nu door een firewall /server gescheiden van de buitenwereld, maar ik moet op dat ding dus services openzetten.
Wat ik van plan ben is _achter_ de internet server nog een computer te zetten die _echt_ alleen establisted/related doorlaat. :Y)
Ik heb alleen nog niet veel met iptables gedaan omdat trustix nog geen 2.4 kernel gebruikt, maar dat komt nog wel, en anders gewoon 2.2 met ipchains en acked-tcp.

  • Haranaka
  • Registratie: September 2000
  • Laatst online: 07-06 23:13
Op maandag 02 juli 2001 13:48 schreef nelske het volgende:
Okee, ten eerste: Is de module ip_contrack en ip_contrack_ftp geladen (of in de kernel gebakken) :? Zo niet meteen doen.

Ten tweede: check die ftp regels nog maar eens goed met de door mij gegeven regels in het andere draadje. Ik haalde er in een oogopslag al een fout uit. (Ff snel gekeken in het andere draadje en daar stond het goed ).

Ten derde: Laat named (ongeacht je firewall) alleen binden aan je interne IP en niet aan je externe IP

Ten vierde: (ik weet niet of dit zo is) Laat named nooit als root draaien!!!!

Ten vijfde: Je kan iptables-rulesets laten gelden voor slechts bepaalde nic's door de interface erbij op te geven.
Voor INPUT rules doe je dit met de -i switch, voor OUTPUT rules met de -o switch.
Dus stel voor dat je interne NIC eth1 is, dan kun je die DNS-regels zo aanpassen, dat je er hetvolgende bijzet: "-i eth1"
1) zijn ingebakken
2) bedankt, ftp regels verbetert, nog geen succes. Ik zit trouwens meer met dat ik niet vanaf buiten kan ssh-en dan ftp-en.
3) named had ik nog nooit vangehoord, heb nagekeken, hij staat niet eens op mijn pc :? 4) niemand draait named dus zeker niet door de root.
5) thnks, zal er even mee gaan prutsen met die poort 53.


Maar dit (en de andere) aanwijzingen zijn toch geen dingen die het funktioneren van ssh en ftp in de weg staan? of zie ik het fout? Ik kan het wel van binnen mijn netwerk maar daar buiten niet.

...


Verwijderd

Hmzz waarom SSH niet werkt is een beetje vreemd!
Toevallig toch geen blokkerende output-rgels he?

Ik zie wel dat ik een aardig foutje heb gemaakt in die FTP-regels. Als die state-regels moeten met elkaar omgewisseld worden. Zoals ze er nu staan geldt het voor ftp-en vanaf die linux-bak en haar netwerk naar de buitenwereld toe i.p.v. andersom.

Stom stom stom |:( sorry

  • Haranaka
  • Registratie: September 2000
  • Laatst online: 07-06 23:13
Op maandag 02 juli 2001 19:02 schreef nelske het volgende:
Hmzz waarom SSH niet werkt is een beetje vreemd!
Toevallig toch geen blokkerende output-rgels he?

Ik zie wel dat ik een aardig foutje heb gemaakt in die FTP-regels. Als die state-regels moeten met elkaar omgewisseld worden. Zoals ze er nu staan geldt het voor ftp-en vanaf die linux-bak en haar netwerk naar de buitenwereld toe i.p.v. andersom.

Stom stom stom |:( sorry
dit heb ik er nu van gemakt:
code:
1
2
3
4
5
6
7
8
/sbin/iptables -A INPUT -p tcp --sport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --dport 21 -m state --state ESTABLISHED -j ACCEPT
#passive ftp:
/sbin/iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
#non-passive ftp:
/sbin/iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT

Bedoelde je het zo?
Ook een "grootmeester" kan wel eens een foutje maken toch?

Over ssh, nee heb verder geen regels dan dit en hier spreekt niets elkaar tegen dacht ik zo.
[edit]
ftp: ik wordt er nu niet meer gelijk vanaf geknikkert als ik probeer connectie te maken maar ik krijg nu een time out.
ssh: nog steeds "connection closed by remote host".

...


Verwijderd

Op maandag 02 juli 2001 19:27 schreef Haranaka het volgende:

[..]
#non-passive ftp:
/sbin/iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED -j ACCEPT
Het kan aan mij liggen, maar ik zeg het toch maar even.
Als iemand van het interne net met active ftp naar buiten connect, maakt die betreffende ftp host een connectie terug vanaf poort 20, oke, maar dit is toch een totaal nieuwe connect? :?

Verwijderd

Op maandag 02 juli 2001 19:27 schreef Haranaka het volgende:

[..]
dit heb ik er nu van gemakt:
code:
1
/sbin/iptables -A INPUT -p tcp --sport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
oke, je draait toch zelf een ftp server.
#non-passive ftp:
[..]
code:
1
/sbin/iptables -A OUTPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
Als iemand jouw server connect via active ftp zal jouw server dus een nieuwe connect maken vanaf port 20 naar een unpriv. port van de betreffende user.
Dit is dan toch ook gewoon een nieuwe connect?

Verwijderd

Op maandag 02 juli 2001 19:27 schreef Haranaka het volgende:
Bedoelde je het zo?
Ook een "grootmeester" kan wel eens een foutje maken toch?
Ghehe, was ik maar een "grootmeester" :) Nee ben ook gewoon een Linux gebruiker die nog een hele hoop te leren heeft :)
Maar ik bedoelde het niet helemaal zo.
Meer in de trant van:
code:
1
2
3
4
5
6
7
8
/sbin/iptables -A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT
#passive ftp:
/sbin/iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
#non-passive ftp:
/sbin/iptables -A INPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT

Overigens heb ik bovenstaande code niet zo in m'n firewall zitten. Mijn ftp-server zit intern, dus ik forward simpelweg alle non-passive poorten (20,21) naar m'n ftp-server.
Ik heb echter wel de eerste regels in m'n firewall staan voor ftp-verkeer naar buiten. Bovenstaande regels moeten dus in mijn ogen ook gewoon werken voor een ftp-server op de NAT-box zelf.
Over ssh, nee heb verder geen regels dan dit en hier spreekt niets elkaar tegen dacht ik zo.
Kijk je log files eens na; wat wordt er precies gelogd? (Geeft vaak veel informatie ;) )
[edit]
ftp: ik wordt er nu niet meer gelijk vanaf geknikkert als ik probeer connectie te maken maar ik krijg nu een time out.
ssh: nog steeds "connection closed by remote host".
Probeer het bovenstaande eens, ftp moet in mijn ogen dan gewoon werken.
Op maandag 02 juli 2001 22:28 schreef Mainwave het volgende:

[..]

oke, je draait toch zelf een ftp server.
[..]

Als iemand jouw server connect via active ftp zal jouw server dus een nieuwe connect maken vanaf port 20 naar een unpriv. port van de betreffende user.
Dit is dan toch ook gewoon een nieuwe connect?
De ip_conntrack_ftp module is hiervoor. Deze kan PORT, Passive comando's etc herkennen. Dit is ook de reden waarom deze verbindingen met deze module als RELATED gezien kunnen worden i.p.v. Nieuwe verbindingen. Zonder die module zou je volkomen gelijk hebben ja :)

Verwijderd

Op maandag 02 juli 2001 23:34 schreef nelske het volgende:
[..]
De ip_conntrack_ftp module is hiervoor. Deze kan PORT, Passive comando's etc herkennen. Dit is ook de reden waarom deze verbindingen met deze module als RELATED gezien kunnen worden i.p.v. Nieuwe verbindingen. Zonder die module zou je volkomen gelijk hebben ja :)
Aaah, slim ja. :)
Ben nog niet zo op de hoogte van die firewalling code in 2.4 kernel.

Verwijderd

Ook nog wat goeie info over securtiy

http://www.tempest.com.br/advisories/01-2001.html
Pagina: 1