Netzwerk / Hosts per Terminal anlegen

Wie kann man das Konfigurieren?
shellshock
Posts: 13
Joined: April 18th, 2017, 5:11 am

Netzwerk / Hosts per Terminal anlegen

Post by shellshock » April 18th, 2017, 10:59 am

Hallo Community,

lassen sich Netzwerk- / Hostsobjekte inklusive Name und IP-Adresse auch über das Terminal anlegen?

Ich würde gerne ein Skript bauen, das mir automatisch solche Objekte erzeugt und ich sie dann über die GUI einzelnen Firewall-Regeln zuordnen kann.

Grüße
shelli

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by ummeegge » April 18th, 2017, 1:09 pm

Hallo shelli,
das sollte kein Problem sein. Unter /var/ipfire/fwhosts/customhosts findet sich die entsprechende Datei in folgendem Format:

Code: Select all

1,Hostname,192.168.70.2/255.255.255.255,Kommentar
also ein

Code: Select all

echo "2,Hostname2,192.168.70.3/255.255.255.255,Kommentar2" >> /var/ipfire/fwhosts/customhosts
sollte da schon reichen.

Geht auch blockweise mit z.b.:

Code: Select all

cat > /var/ipfire/fwhosts/customhosts << EOF
1,Test,ip,192.168.7.2/255.255.255.255,test
2,TestA,ip,192.168.7.3/255.255.255.255,testA
3,TestB,ip,192.168.7.4/255.255.255.255,testB
4,TestC,ip,192.168.7.5/255.255.255.255,testC
5,TestD,ip,192.168.7.6/255.255.255.255,testD
6,TestE,ip,192.168.7.7/255.255.255.255,testE
7,TestF,ip,192.168.7.8/255.255.255.255,testF
8,TestG,ip,192.168.7.9/255.255.255.255,testG
9,TestH,ip,192.168.7.10/255.255.255.255,testH
10,TestI,ip,192.168.7.11/255.255.255.255,testI
EOF
Wenn du nun viele Hosts hast (was ich mal denken würde ;-) geht das ja auch z.b. mittels for loop...

UE
Image
Image
Image

shellshock
Posts: 13
Joined: April 18th, 2017, 5:11 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by shellshock » April 18th, 2017, 6:43 pm

Danke UE!

Ich versuche mich gerade an einem Skript nach Vorbild vom Kuketz-Blog: https://www.kuketz-blog.de/google-und-f ... lockieren/

Mein Ziel: Alle (bzw. möglichst alle) Google IP-Adressen erfassen, daraus dann ein Netzwerk-Objekt für die GUI bauen, mit dem sich dann ganz einfach Regeln bauen lassen.

Bonus: Den Prozess automatisiert wiederholen, um neue bzw. geänderte IP-Adressen zu erfassen.

Ich weiß mein Vorhaben klingt schräg. :-)

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by ummeegge » April 19th, 2017, 5:49 am

Guten Morgen,
klingt eigentlich gar nicht so schräg, es gab mal einen ähnlichen Thread hier allerdings wurde das damals mittels IPset --> http://wiki.ipfire.org/en/configuration/firewall/ipset und der firewall.local --> http://wiki.ipfire.org/en/configuration ... wall.local gemacht.
Den Thread findest du hier --> viewtopic.php?t=15124 die Lösungen da gehen noch ein wenig weiter aber das erste Skript könnte bei dir vielleicht interessant sein wenn event auch ein wenig überdimensioniert. Skript findest du u.a. auch hier --> https://github.com/ummeegge/scripts/blo ... _update.sh . Du kannst im Bereich "## Blacklist addresses" die URL(s) eingeben, das Skript sucht sich dann IP´s und/oder CIDR´s raus und packt sie in entsprechende Sets. Dadurch das IPSet seine Sets Hasht, können da mehrere tausend Adressen rein ohne das es performance Schwierigkeiten gibt.
- Die FW Regeln werden automatisch gesetzt.
- Das Skript ist auf Updates ausgelegt (flusht die Chains bei jedem Start und setzt die Regeln neu), kann z.b. mittels frcon geschaltet werden.
- Es gibt einen Counter der dir auch anzeigt wieviel Pakete/Bytes an die jeweilig geblockten IP´s/CIDR´s geschickt wurden (findest du unter /etc/ipset/counterlist_ipset ). Du findest die Counter auch über die IPTables commandline oder über das WUI -->
Image
aber nur für die komplette Chain und nicht per IP , hierfür wäre dann die Counter Liste.

Kannst es ja mal testen für diese Art von Files, ich habe noch eine Kleinigkeit am Skript geändert da das Format ein anderes ist. Du kannst dir anschauen wie das Skript arbeitet in dem du z.b. beim Shebang noch ein -x ranhängst -->

Code: Select all

#!/bin/bash -x
EDIT: Was ich noch vergessen habe, die FW Regeln die vom Skript gesetzt werden REJECTEN INPUT, OUTPUT und FORWARD (also auch IPFire selber) was dann z.b. so aussieht:

Code: Select all

-> ping -c 3 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
From 192.168.2.3 icmp_seq=1 Destination Port Unreachable
From 192.168.2.3 icmp_seq=1 Destination Port Unreachable
From 192.168.2.3 icmp_seq=1 Destination Port Unreachable

--- 8.8.4.4 ping statistics ---
0 packets transmitted, 0 received, +3 error

Grüsse,

UE
Image
Image
Image

shellshock
Posts: 13
Joined: April 18th, 2017, 5:11 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by shellshock » April 21st, 2017, 10:46 am

Danke ummeegge!

Ich habe da jetzt mal was gebastelt, was sich sicherlich noch optimieren lässt: https://www.kuketz-blog.de/ipfire-beta- ... t-gesucht/

Hinweise immer gerne.

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by ummeegge » April 22nd, 2017, 7:36 am

Hallo,
wenn es was gebracht hat immer gerne ;-). Danke dir auch für deine weiteren Ideen, werd ich mir gerne mal anschauen.

Grüsse,

UE
Image
Image
Image

shellshock
Posts: 13
Joined: April 18th, 2017, 5:11 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by shellshock » April 25th, 2017, 7:07 am

Hattest du schon Zeit in das Skript reinzuschauen? Ich habe es jetzt nochmal geupdatet: https://www.kuketz-blog.de/ipfire-beta- ... t-gesucht/

Wofür ich noch keine Lösung habe: Zusammenfassen der Adressblöcke in größere, damit nicht so viele Objekte erzeugt werden müssen. Das mit der Bash zu lösen, ist allerdings gar nicht so einfach. Falls du da Ideen hast, immer her damit.

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by ummeegge » April 27th, 2017, 1:48 pm

Hallo shelli,
shellshock wrote: Hattest du schon Zeit in das Skript reinzuschauen? Ich habe es jetzt nochmal geupdatet: https://www.kuketz-blog.de/ipfire-beta- ... t-gesucht/
noch nicht wirklich. Ich hab dein Skript gerade mal rüberlaufen lassen, folgende Sachen sind mir auf die Schnelle aufgefallen:

- Die internen Antwortzeiten (bsp. iptables Aufruf) gehen extrem runter. Ein

Code: Select all

time iptables -L FORWARDFW
braucht auf meinem JNC9C

Code: Select all

real	1m59.867s
user	0m0.113s
sys	0m0.190s
- In den FW Regeln finden sich u.a. sowas:

Code: Select all

mpk20-01-eng-sw2.corp.tfbnw.net/22
ae24.bb02.hkg1.tfbnw.net/19
ae5.pr01.vie1.tfbnw.net/22
po441.asw01.ams3.tfbnw.net/22
cache.google.com/27
192-119-28-0.mci.googlefiber.net/24
user-64-9-236-0.googlewifi.com/22
0.0.154.104.bc.googleusercontent.com/15
0.148.216.162.bc.googleusercontent.com/22
time1.google.com/24
0.192.35.8.bc.googleusercontent.com/21
rio01s23-in-f0.1e100.net/24
0.24.114.74.bc.googleusercontent.com/21
0.112.255.173.bc.googleusercontent.com/20
lax17s03-in-f0.1e100.net/24
0.128.251.23.bc.googleusercontent.com/19
bom05s05-in-f0.1e100.net/24
0.48.236.23.bc.googleusercontent.com/20
0.188.81.208.bc.googleusercontent.com/22
ham02s13-in-f0.1e100.net/24
lax02s21-in-f0.1e100.net/24
atl14s39-in-f0.1e100.net/24
0.160.167.107.bc.googleusercontent.com/19
gru03s05-in-f0.1e100.net/24
0.232.223.199.bc.googleusercontent.com/21
mil02s06-in-f0.1e100.net/24
lhr26s05-in-f0.1e100.net/24
0.176.222.162.bc.googleusercontent.com/21
ber01s14-in-f0.1e100.net/24
muc03s07-in-f0.1e100.net/24
0.28.158.192.bc.googleusercontent.com/22
hkg12s11-in-f0.1e100.net/24
0.192.178.107.gae.googleusercontent.com/18
lga15s42-in-f0.1e100.net/24
sof01s12-in-f0.1e100.net/24
any-in-c000.1e100.net/18
ord38s04-in-f0.1e100.net/24
gru06s25-in-f0.1e100.net/24
0.0.184.35.bc.googleusercontent.com/13
ord08s12-in-f0.1e100.net/24
tsa01s07-in-f0.1e100.net/24
par03s02-in-f0.1e100.net/24
jnb01s07-in-f0.1e100.net/24
eze03s15-in-f0.1e100.net/24
mad01s14-in-f0.1e100.net/24
0.208.34.8.bc.googleusercontent.com/21
ord38s04-in-f0.1e100.net/16
fra16s07-in-f0.1e100.net/24
sof02s17-in-f0.1e100.net/24
muc03s13-in-f0.1e100.net/24
nuq04s29-in-f0.1e100.net/19
nrt13s38-in-f0.1e100.net/24
mil01s16-in-f0.1e100.net/24
0.192.170.108.bc.googleusercontent.com/18
0.108.68.208.bc.googleusercontent.com/22
0.112.192.199.bc.googleusercontent.com/22
0.0.192.35.bc.googleusercontent.com/13
crawl-66-249-64-0.googlebot.com/19
0.0.196.104.bc.googleusercontent.com/14
0.200.35.8.gae.googleusercontent.com/21
0.216.34.8.bc.googleusercontent.com/21
lis01s13-in-f0.1e100.net/24
den03s09-in-f0.1e100.net/24
0.80.59.108.bc.googleusercontent.com/20
mpk20-01-eng-sw2.corp.tfbnw.net/22
ae24.bb02.hkg1.tfbnw.net/19
ae5.pr01.vie1.tfbnw.net/22
po441.asw01.ams3.tfbnw.net/22
cache.google.com/27
192-119-28-0.mci.googlefiber.net/24
user-64-9-236-0.googlewifi.com/22
0.0.154.104.bc.googleusercontent.com/15
0.148.216.162.bc.googleusercontent.com/22
time1.google.com/24
0.192.35.8.bc.googleusercontent.com/21
rio01s23-in-f0.1e100.net/24
0.24.114.74.bc.googleusercontent.com/21
0.112.255.173.bc.googleusercontent.com/20
lax17s03-in-f0.1e100.net/24
0.128.251.23.bc.googleusercontent.com/19
bom05s05-in-f0.1e100.net/24
0.48.236.23.bc.googleusercontent.com/20
0.188.81.208.bc.googleusercontent.com/22
ham02s13-in-f0.1e100.net/24
lax02s21-in-f0.1e100.net/24
atl14s39-in-f0.1e100.net/24
0.160.167.107.bc.googleusercontent.com/19
gru03s05-in-f0.1e100.net/24
0.232.223.199.bc.googleusercontent.com/21
mil02s06-in-f0.1e100.net/24
lhr26s05-in-f0.1e100.net/24
0.176.222.162.bc.googleusercontent.com/21
ber01s14-in-f0.1e100.net/24
muc03s07-in-f0.1e100.net/24
0.28.158.192.bc.googleusercontent.com/22
hkg12s11-in-f0.1e100.net/24
0.192.178.107.gae.googleusercontent.com/18
lga15s42-in-f0.1e100.net/24
sof01s12-in-f0.1e100.net/24
any-in-c000.1e100.net/18
ord38s04-in-f0.1e100.net/24
gru06s25-in-f0.1e100.net/24
0.0.184.35.bc.googleusercontent.com/13
ord08s12-in-f0.1e100.net/24
tsa01s07-in-f0.1e100.net/24
par03s02-in-f0.1e100.net/24
jnb01s07-in-f0.1e100.net/24
eze03s15-in-f0.1e100.net/24
mad01s14-in-f0.1e100.net/24
0.208.34.8.bc.googleusercontent.com/21
ord38s04-in-f0.1e100.net/16
fra16s07-in-f0.1e100.net/24
sof02s17-in-f0.1e100.net/24
muc03s13-in-f0.1e100.net/24
nuq04s29-in-f0.1e100.net/19
nrt13s38-in-f0.1e100.net/24
mil01s16-in-f0.1e100.net/24
0.192.170.108.bc.googleusercontent.com/18
0.108.68.208.bc.googleusercontent.com/22
0.112.192.199.bc.googleusercontent.com/22
0.0.192.35.bc.googleusercontent.com/13
crawl-66-249-64-0.googlebot.com/19
0.0.196.104.bc.googleusercontent.com/14
0.200.35.8.gae.googleusercontent.com/21
0.216.34.8.bc.googleusercontent.com/21
lis01s13-in-f0.1e100.net/24
den03s09-in-f0.1e100.net/24
0.80.59.108.bc.googleusercontent.com/20
ist denke ich nicht so optimal ;)

- Einige Ranges beinhalten andere z.b.
216.239.32.0/19 geht
von: 216.239.32.1 bis: 216.239.63.254
und macht nachfolgende

Code: Select all

216.239.32.0/24
216.239.33.0/24
216.239.34.0/24
216.239.36.0/24
216.239.38.0/24
216.239.39.0/24
überflüssig. Jede Range oder IP macht eine eigene Regel aus die auch abgearbeitet werden will, das Skript bringt derzeit alleine für die FORWARDFW "529" Regeln. Wenn der Proxy da noch mitrein soll kommt das selbe nochmal für die OUTGOING mit dazu. Somit wird die Systemresponse irgendwann unterirdisch...
shellshock wrote: Wofür ich noch keine Lösung habe: Zusammenfassen der Adressblöcke in größere, damit nicht so viele Objekte erzeugt werden müssen. Das mit der Bash zu lösen, ist allerdings gar nicht so einfach. Falls du da Ideen hast, immer her damit.
Vielleicht lässt sich das so regeln das du die CIDR erstmal wegnimmst, nach doubletten suchst z.b.

Code: Select all

cut -d"/" -f1 | sort | uniq -d
und dir dann da die niedrigeren CIDRs rausfischt. Der Rest fliegt raus...

Ich würde allerdings für solche Aufgaben oben erwähntes IPset nehmen was genau für solche Aufgaben gedacht ist. Habe derzeit bei mir "21824" CIDRs und "3530" IPs drinne und das System läuft wie ein kühles blondes mit geschnitten Brot zu einem warmen Feierabend :P .

Schnelle Rückmeldung mal von hier.

Grüsse,

UE
Image
Image
Image

shellshock
Posts: 13
Joined: April 18th, 2017, 5:11 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by shellshock » April 27th, 2017, 5:39 pm

ummeegge wrote: - Die internen Antwortzeiten (bsp. iptables Aufruf) gehen extrem runter. Ein

Code: Select all

time iptables -L FORWARDFW
braucht auf meinem JNC9C

Code: Select all

real	1m59.867s
user	0m0.113s
sys	0m0.190s
Dann versuch es bitte mal mit einem:

Code: Select all

time iptables -L FORWARDFW -n
Dann führt iptables keine Reverse DNS-Lookups durch. Wird dann gleich viel schneller sein. ;-)
ummeegge wrote: - In den FW Regeln finden sich u.a. sowas:

Code: Select all

mpk20-01-eng-sw2.corp.tfbnw.net/22
ae24.bb02.hkg1.tfbnw.net/19
ae5.pr01.vie1.tfbnw.net/22
po441.asw01.ams3.tfbnw.net/22
cache.google.com/27
192-119-28-0.mci.googlefiber.net/24
user-64-9-236-0.googlewifi.com/22
0.0.154.104.bc.googleusercontent.com/15
0.148.216.162.bc.googleusercontent.com/22
time1.google.com/24
0.192.35.8.bc.googleusercontent.com/21
rio01s23-in-f0.1e100.net/24
0.24.114.74.bc.googleusercontent.com/21
0.112.255.173.bc.googleusercontent.com/20
lax17s03-in-f0.1e100.net/24
0.128.251.23.bc.googleusercontent.com/19
bom05s05-in-f0.1e100.net/24
0.48.236.23.bc.googleusercontent.com/20
0.188.81.208.bc.googleusercontent.com/22
ham02s13-in-f0.1e100.net/24
lax02s21-in-f0.1e100.net/24
atl14s39-in-f0.1e100.net/24
0.160.167.107.bc.googleusercontent.com/19
gru03s05-in-f0.1e100.net/24
0.232.223.199.bc.googleusercontent.com/21
mil02s06-in-f0.1e100.net/24
lhr26s05-in-f0.1e100.net/24
0.176.222.162.bc.googleusercontent.com/21
ber01s14-in-f0.1e100.net/24
muc03s07-in-f0.1e100.net/24
0.28.158.192.bc.googleusercontent.com/22
hkg12s11-in-f0.1e100.net/24
0.192.178.107.gae.googleusercontent.com/18
lga15s42-in-f0.1e100.net/24
sof01s12-in-f0.1e100.net/24
any-in-c000.1e100.net/18
ord38s04-in-f0.1e100.net/24
gru06s25-in-f0.1e100.net/24
0.0.184.35.bc.googleusercontent.com/13
ord08s12-in-f0.1e100.net/24
tsa01s07-in-f0.1e100.net/24
par03s02-in-f0.1e100.net/24
jnb01s07-in-f0.1e100.net/24
eze03s15-in-f0.1e100.net/24
mad01s14-in-f0.1e100.net/24
0.208.34.8.bc.googleusercontent.com/21
ord38s04-in-f0.1e100.net/16
fra16s07-in-f0.1e100.net/24
sof02s17-in-f0.1e100.net/24
muc03s13-in-f0.1e100.net/24
nuq04s29-in-f0.1e100.net/19
nrt13s38-in-f0.1e100.net/24
mil01s16-in-f0.1e100.net/24
0.192.170.108.bc.googleusercontent.com/18
0.108.68.208.bc.googleusercontent.com/22
0.112.192.199.bc.googleusercontent.com/22
0.0.192.35.bc.googleusercontent.com/13
crawl-66-249-64-0.googlebot.com/19
0.0.196.104.bc.googleusercontent.com/14
0.200.35.8.gae.googleusercontent.com/21
0.216.34.8.bc.googleusercontent.com/21
lis01s13-in-f0.1e100.net/24
den03s09-in-f0.1e100.net/24
0.80.59.108.bc.googleusercontent.com/20
mpk20-01-eng-sw2.corp.tfbnw.net/22
ae24.bb02.hkg1.tfbnw.net/19
ae5.pr01.vie1.tfbnw.net/22
po441.asw01.ams3.tfbnw.net/22
cache.google.com/27
192-119-28-0.mci.googlefiber.net/24
user-64-9-236-0.googlewifi.com/22
0.0.154.104.bc.googleusercontent.com/15
0.148.216.162.bc.googleusercontent.com/22
time1.google.com/24
0.192.35.8.bc.googleusercontent.com/21
rio01s23-in-f0.1e100.net/24
0.24.114.74.bc.googleusercontent.com/21
0.112.255.173.bc.googleusercontent.com/20
lax17s03-in-f0.1e100.net/24
0.128.251.23.bc.googleusercontent.com/19
bom05s05-in-f0.1e100.net/24
0.48.236.23.bc.googleusercontent.com/20
0.188.81.208.bc.googleusercontent.com/22
ham02s13-in-f0.1e100.net/24
lax02s21-in-f0.1e100.net/24
atl14s39-in-f0.1e100.net/24
0.160.167.107.bc.googleusercontent.com/19
gru03s05-in-f0.1e100.net/24
0.232.223.199.bc.googleusercontent.com/21
mil02s06-in-f0.1e100.net/24
lhr26s05-in-f0.1e100.net/24
0.176.222.162.bc.googleusercontent.com/21
ber01s14-in-f0.1e100.net/24
muc03s07-in-f0.1e100.net/24
0.28.158.192.bc.googleusercontent.com/22
hkg12s11-in-f0.1e100.net/24
0.192.178.107.gae.googleusercontent.com/18
lga15s42-in-f0.1e100.net/24
sof01s12-in-f0.1e100.net/24
any-in-c000.1e100.net/18
ord38s04-in-f0.1e100.net/24
gru06s25-in-f0.1e100.net/24
0.0.184.35.bc.googleusercontent.com/13
ord08s12-in-f0.1e100.net/24
tsa01s07-in-f0.1e100.net/24
par03s02-in-f0.1e100.net/24
jnb01s07-in-f0.1e100.net/24
eze03s15-in-f0.1e100.net/24
mad01s14-in-f0.1e100.net/24
0.208.34.8.bc.googleusercontent.com/21
ord38s04-in-f0.1e100.net/16
fra16s07-in-f0.1e100.net/24
sof02s17-in-f0.1e100.net/24
muc03s13-in-f0.1e100.net/24
nuq04s29-in-f0.1e100.net/19
nrt13s38-in-f0.1e100.net/24
mil01s16-in-f0.1e100.net/24
0.192.170.108.bc.googleusercontent.com/18
0.108.68.208.bc.googleusercontent.com/22
0.112.192.199.bc.googleusercontent.com/22
0.0.192.35.bc.googleusercontent.com/13
crawl-66-249-64-0.googlebot.com/19
0.0.196.104.bc.googleusercontent.com/14
0.200.35.8.gae.googleusercontent.com/21
0.216.34.8.bc.googleusercontent.com/21
lis01s13-in-f0.1e100.net/24
den03s09-in-f0.1e100.net/24
0.80.59.108.bc.googleusercontent.com/20
ist denke ich nicht so optimal ;)
Es werden nur Objekte mit IP-Adresse und Netzmaske erzeugt. Wenn du nicht "-n" anhängst, dann macht iptables ein Reverse DNS-Lookup für jeden Eintrag, daher dauert das so lange.
ummeegge wrote: - Einige Ranges beinhalten andere z.b.
216.239.32.0/19 geht
von: 216.239.32.1 bis: 216.239.63.254
und macht nachfolgende

Code: Select all

216.239.32.0/24
216.239.33.0/24
216.239.34.0/24
216.239.36.0/24
216.239.38.0/24
216.239.39.0/24
überflüssig. Jede Range oder IP macht eine eigene Regel aus die auch abgearbeitet werden will, das Skript bringt derzeit alleine für die FORWARDFW "529" Regeln. Wenn der Proxy da noch mitrein soll kommt das selbe nochmal für die OUTGOING mit dazu. Somit wird die Systemresponse irgendwann unterirdisch...
shellshock wrote: Wofür ich noch keine Lösung habe: Zusammenfassen der Adressblöcke in größere, damit nicht so viele Objekte erzeugt werden müssen. Das mit der Bash zu lösen, ist allerdings gar nicht so einfach. Falls du da Ideen hast, immer her damit.
Vielleicht lässt sich das so regeln das du die CIDR erstmal wegnimmst, nach doubletten suchst z.b.

Code: Select all

cut -d"/" -f1 | sort | uniq -d
und dir dann da die niedrigeren CIDRs rausfischt. Der Rest fliegt raus...
Ne, so leicht ist es leider nicht. Vielleicht fällt uns da noch was besseres ein.

Gruß shelli

5p9
Mentor
Mentor
Posts: 1676
Joined: May 1st, 2011, 3:27 pm

Re: Netzwerk / Hosts per Terminal anlegen

Post by 5p9 » May 4th, 2017, 12:11 pm

Hallo,

mal eine Frage. Ich arbeite gerade an einem neuen WLAN Konzept: https://forum.ipfire.org/viewtopic.php?f=6&t=18494

Hier ist es so, dass ich das ein oder andere System auch per Namen (für den DAU) z.B. per RDP erreichbar machen möchte.
ICh habe mir im Moment so beholfen das ich in Blau auch customhosts und eine customgruppe angelegt habe die dann eben nach green per RDP zugreifen dürfen.

Die Namensauflösung greift hier nicht, da das blue-Netz intern in green nicht bekannt ist und mein DNS-Server hier natürlich nicht viel bringt. Daher habe ich die Systeme die auch per RDP mit Namensangabe in der /etc/hosts hinterlegt.

z.B. so:

Code: Select all

# wtsen
192.168.xxx.xxx    terminal01.meine.domain        terminal01
...
...
das funktioniert recht gut, jedoch weiß ich nicht ob ich dieses Schema doch lieber an eine andere Stelle verwenden sollte als in der /etc/hosts datei. Kann ich dies dann auch so in der customhosts & customgruppe auch so abbilden?

VG, 5p9

shellshock
Posts: 13
Joined: April 18th, 2017, 5:11 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by shellshock » May 5th, 2017, 7:31 pm

So das Skript beseitigt jetzt auch Subnetze, die bereits von einem größeren abgedeckt werden. Das reduziert die Einträge erheblich: IPFire ASN-Script

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by ummeegge » May 6th, 2017, 11:27 am

Hallo shelli,
zunächst mal klasse Idee im Gesamten. Eure Änderungen sehen gut aus und optimieren den Regelsatz nochmal.

Facebook, Twitter und Google machen bis jetzt einen guten Eindruck, allerdings wird es mit einer effektiven Sperre bei Windows z.b. schon schwieriger. "https://www.microsoft.com" sperrt er ganz brav, wenn ich allerdings über die Suchmaschine meiner Wahl ;-) mal nach Windows suche macht er mir z.b. aus "https://www.microsoft.com" ein Länderspezifisches "https://www.microsoft.com/de-de/" auf was nicht mehr geblockt wird. Auch Dinger wie "https://products.office.com/en-us/products" fallen dabei hinten über. Als Nebeninfo mal.

Hab deine Idee mal parallel für IPset weiterentwickelt (hoffe das ist OK für dich) da:
1) Das Gruppenmenü im WUI bleibt übersichtlicher obwohl ihr da schon Klasse reduziert habt.
2) Es brauch kein weiteres zutun mehr über das WUI um Netzwerke hinzuzufügen oder auch wieder zu löschen.
3) Es gibt zwar keine "consolidateNetblocks" Funktion hierbei (cdr2mask ist auch nicht mehr nötig) allerdings sollte IPSet das Geschwindigkeitstechnisch durch das gehashte Mapping durchaus wettmachen.
4) "iptables -L" ist auch ohne "-n" machbar.

Ich lass das aber vielleicht erstmal raus ? damit dein/euer Skript hier weiter ohne zusätzlichen stuff getestet werden kann.

Ein Danke hierfür von meiner Seite wollt ich aber dennoch drangehängt haben, nice one ;) .

Grüsse,

UE

P.S. @5p9 bin noch nicht hinter deine Frage gestiegen, anderer Topic vielleicht ?
Image
Image
Image

shellshock
Posts: 13
Joined: April 18th, 2017, 5:11 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by shellshock » May 6th, 2017, 6:22 pm

ummeegge wrote: Facebook, Twitter und Google machen bis jetzt einen guten Eindruck, allerdings wird es mit einer effektiven Sperre bei Windows z.b. schon schwieriger. "https://www.microsoft.com" sperrt er ganz brav, wenn ich allerdings über die Suchmaschine meiner Wahl ;-) mal nach Windows suche macht er mir z.b. aus "https://www.microsoft.com" ein Länderspezifisches "https://www.microsoft.com/de-de/" auf was nicht mehr geblockt wird. Auch Dinger wie "https://products.office.com/en-us/products" fallen dabei hinten über. Als Nebeninfo mal.
Microsoft hostet ein Teil seiner Seiten über Akamai - die werden vom Microsoft ASN, bzw. später dann beim Blocken nicht erfasst.
ummeegge wrote: Hab deine Idee mal parallel für IPset weiterentwickelt (hoffe das ist OK für dich) da:
1) Das Gruppenmenü im WUI bleibt übersichtlicher obwohl ihr da schon Klasse reduziert habt.
2) Es brauch kein weiteres zutun mehr über das WUI um Netzwerke hinzuzufügen oder auch wieder zu löschen.
3) Es gibt zwar keine "consolidateNetblocks" Funktion hierbei (cdr2mask ist auch nicht mehr nötig) allerdings sollte IPSet das Geschwindigkeitstechnisch durch das gehashte Mapping durchaus wettmachen.
4) "iptables -L" ist auch ohne "-n" machbar.
Kannst du gerne machen. Ich finde es über das GUI eben ganz praktisch, weil ich dann für diverse Geräte ganz einfach auch Ausnahmen über die GUI festlegen kann. Aber klar, über IPset ist es natürlich performanter.
ummeegge wrote: Ein Danke hierfür von meiner Seite wollt ich aber dennoch drangehängt haben, nice one ;)
Danke! :-)

Grüße shelli

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by ummeegge » May 8th, 2017, 9:52 am

Hallo shelli,
hab gerade mal geschaut was der Unterschied für eine ASN Abfrage bei 'stat.ripe.net' und bei einer whoise Abfrage ist.

Beispiel ist eine Twitter ASN mit folgenden Kommandos:

Code: Select all

curl --silent "https://stat.ripe.net/data/announced-prefixes/data.json?preferred_version=1.1&resource=AS13414" | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}/[0-9]{1,2}' | uniq
Ausgabe für state.ripe.net

Code: Select all

199.59.148.0/22
104.244.42.0/24
104.244.45.0/24
202.160.131.0/24
104.244.46.0/24
199.96.62.0/23
185.45.5.0/24
199.96.60.0/23
188.64.231.0/24
185.45.6.0/23
103.252.114.0/23
199.16.156.0/22
199.96.60.0/24
192.133.76.0/23
103.252.112.0/23
104.244.40.0/24
199.16.156.0/23
188.64.227.0/24
64.63.0.0/18
199.96.57.0/24
188.64.230.0/24
188.64.229.0/24
188.64.226.0/23
104.244.47.0/24
199.96.56.0/24
104.244.43.0/24
202.160.130.0/24
202.160.129.0/24
202.160.128.0/24
192.133.76.0/22
199.96.58.0/23
188.64.224.0/24
188.64.225.0/24
104.244.44.0/24
199.96.61.0/24
188.64.226.0/24
199.96.56.0/23
192.44.69.0/24
104.244.41.0/24
188.64.228.0/24
Kommando:

Code: Select all

whois -h whois.radb.net -- '-i origin AS13414' | grep -Eo "([0-9.]+){4}/[0-9]+" | uniq
Ausgabe für whois.radb.net:

Code: Select all

199.96.57.0/24
199.16.156.0/22
199.59.148.0/22
192.133.76.0/22
192.133.76.0/23
199.96.59.0/24
199.96.58.0/24
199.96.63.0/24
199.96.56.0/21
103.252.112.0/22
103.252.114.0/23
185.45.4.0/23
69.12.56.0/21
104.244.42.0/24
185.45.5.0/24
185.45.4.0/24
199.96.56.0/24
202.160.128.0/22
202.160.128.0/24
202.160.129.0/24
202.160.130.0/24
202.160.131.0/24
188.64.224.0/24
188.64.225.0/24
188.64.226.0/24
188.64.227.0/24
188.64.228.0/24
188.64.229.0/24
188.64.230.0/24
188.64.231.0/24
188.64.224.0/21
104.244.40.0/24
104.244.41.0/24
104.244.43.0/24
185.45.6.0/23
192.44.68.0/23
192.48.236.0/23
199.96.56.0/23
199.69.58.0/23
199.96.60.0/23
199.96.62.0/23
192.44.68.0/24
192.44.69.0/24
103.252.112.0/23
188.64.226.0/23
104.244.44.0/24
104.244.45.0/24
104.244.46.0/24
104.244.47.0/24
Der Diff:

Code: Select all

diff --side-by-side stat.ripe.net whois.radb.net 
							      >	199.96.57.0/24
							      >	199.16.156.0/22
199.59.148.0/22							199.59.148.0/22
							      >	192.133.76.0/22
							      >	192.133.76.0/23
							      >	199.96.59.0/24
							      >	199.96.58.0/24
							      >	199.96.63.0/24
							      >	199.96.56.0/21
							      >	103.252.112.0/22
							      >	103.252.114.0/23
							      >	185.45.4.0/23
							      >	69.12.56.0/21
104.244.42.0/24							104.244.42.0/24
104.244.45.0/24						      <
202.160.131.0/24					      <
104.244.46.0/24						      <
199.96.62.0/23						      <
185.45.5.0/24							185.45.5.0/24
199.96.60.0/23						      |	185.45.4.0/24
188.64.231.0/24						      <
185.45.6.0/23						      <
103.252.114.0/23					      <
199.16.156.0/22						      <
199.96.60.0/24						      <
192.133.76.0/23						      <
103.252.112.0/23					      <
104.244.40.0/24						      <
199.16.156.0/23						      <
188.64.227.0/24						      <
64.63.0.0/18						      <
199.96.57.0/24						      <
188.64.230.0/24						      <
188.64.229.0/24						      <
188.64.226.0/23						      <
104.244.47.0/24						      <
199.96.56.0/24							199.96.56.0/24
104.244.43.0/24						      |	202.160.128.0/22
202.160.130.0/24					      <
202.160.129.0/24					      <
202.160.128.0/24						202.160.128.0/24
192.133.76.0/22						      |	202.160.129.0/24
199.96.58.0/23						      |	202.160.130.0/24
							      >	202.160.131.0/24
188.64.224.0/24							188.64.224.0/24
188.64.225.0/24							188.64.225.0/24
104.244.44.0/24						      <
199.96.61.0/24						      <
188.64.226.0/24							188.64.226.0/24
							      >	188.64.227.0/24
							      >	188.64.228.0/24
							      >	188.64.229.0/24
							      >	188.64.230.0/24
							      >	188.64.231.0/24
							      >	188.64.224.0/21
							      >	104.244.40.0/24
							      >	104.244.41.0/24
							      >	104.244.43.0/24
							      >	185.45.6.0/23
							      >	192.44.68.0/23
							      >	192.48.236.0/23
199.96.56.0/23							199.96.56.0/23
							      >	199.69.58.0/23
							      >	199.96.60.0/23
							      >	199.96.62.0/23
							      >	192.44.68.0/24
192.44.69.0/24							192.44.69.0/24
104.244.41.0/24						      |	103.252.112.0/23
188.64.228.0/24						      |	188.64.226.0/23
							      >	104.244.44.0/24
							      >	104.244.45.0/24
							      >	104.244.46.0/24

es gibt Überschneidungen dennoch enthalten beide Abfragen Ergebnisse die es auf der anderen Seite nicht gibt.

Mal als weitere Nebeninfo.

Grüsse,

UE
Image
Image
Image

shellshock
Posts: 13
Joined: April 18th, 2017, 5:11 am

Re: Netzwerk / Hosts per Terminal anlegen

Post by shellshock » May 8th, 2017, 6:14 pm

Interessante Beobachtung! Danke ummeegge.

Die Frage ist nun, welche Quelle ist genauer bzw. aktueller? Oder eventuell macht es Sinn auch mehrere Quellen einzubinden und dann wieder die doppelten Einträge zu entfernen.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests