1.2 mio IP Bereiche laden

[bit-teufel]

Hallo,

Ich habe mir alle frei zugänglichen IP Bereichs Listen von der Seite http://www.iblocklist.com/lists.php geladen
dann alle IP Bereiche mit "sed" rausgefiltert und in eine Datei/Script geschrieben.
Der Inhalt sie wie folgt aus:
#!/bin/sh
iptables -A AntiP2P -m iprange --src-range 1.1.1.0-1.1.1.255 -j DROP
iptables -A AntiP2P -m iprange --src-range 1.2.3.0-1.2.3.255 -j DROP
iptables -A AntiP2P -m iprange --src-range 27.0.64.0-27.0.95.255 -j DROP
iptables -A AntiP2P -m iprange --src-range 27.50.48.0-27.50.63.255 -j DROP
und das jetzt 1.2 mio mal .....
Das laden des Script dauert aber länger als 3 Tage.
Gibt es die Möglichkeit die zu blockierdenen IP Bereiche schneller zu laden ?

Vielen Dank im Voraus
B.-D.

 

[foexle]

°° .....

wäre es nicht einfacher einfach alles zu DROPen und nur die gewünschten IP-Adressen frei zu geben ? ....

 

[bit-teufel]

Das wäre sicherlich einfacher. Aber warum einfach wenn es auch schwer geht.
Gibt es da keine andere Möglichkeit außer die Bereiche mittels iptables zu laden ?
oder eine Technik mit der man die Bereiche schneller laden kann als mit einen Script in dem dann steht "iptables -A AntiP2P -m iprange --src-range 27.0.64.0-27.0.95.255 -j DROP" usw. ?

 

[rikola]

'man iptables', nach 'range' gesucht und ein paar mal (3x!) 'n' fuer 'next' gedrueckt sollte Deine Frage eigentlich beantworten.

 

[saeckereier]

Also wenn du 1,2 Millionen IP-Adressen in den Speicher laden willst, dann wird das sicherlich so oder so dauern. Das der Paketfilter dann auch noch performant ist zweifel ich einfach mal an. Daher sollte die Frage erlaubt sein, warum willst du das tun? Über eine Hashtabelle oder ähnliches liesse sich das vielleicht machen, aber dafür kenne ich kein passendes Modul. Ich kenne allerdings auch die netfilter interne Struktur nicht. eines deiner Problem dürfte wohl schon sein, dass iptables Kommando 1,2 Millionen mal zu starten, das alleine wird Zeit kosten.

rikola, was meinst du, ich finde nix entsprechendes in der man-page..

 

[saeckereier]

Weitere Möglichkeiten wären übrigens das Modul recent für iptables, dann kann man einzelne IPs über ein /sys/... Interface hinzufügen oder iptables-restore eine geeignete Datei zu präsentieren. Oder BSD zu nehmen, dessen Paketfilter kann sowas.

 

[bit-teufel]

Mit "iptables-restore" klappt es schon viel besser. Ich kann in einen Rutsch (ca. 20 Sek.) über 300.000 IPtables Regeln laden.
Danach bricht iptables-restore leider ab.
Fehlermeldung: "iptables: Memory allocation problem"
und unter /var/log/messages: "Nov 17 10:54:11 vmware kernel: vmap allocation for size 85110784 failed: use vmalloc=<size> to increase size."

Die Kiste ist mit 2GB Ram ausgestattet.
Gibt es die Möglichkeit mehr RAM für IPtables frei zu machen ? Oder eine andere Lösung ?

 

[rikola]

Oder eine andere Lösung ?

Vielleicht ergibt sich die ja, wenn Du die Frage von saeckereier beantwortest, weshalb Du das ueberhaupt machen moechtest.

 

[rikola]

rikola, was meinst du, ich finde nix entsprechendes in der man-page..

Ich hatte es so verstanden, dass ein Bereich in src-range angegeben werden sollte, und dazu liefert mir die man-page von iptables unter Debian stable:

iprange
This matches on a given arbitrary range of IP addresses.

[!] --src-range from[-to]
Match source IP in the specified range.

und so wie ich die Frage verstanden habe, stellt dies die Antwort dar, naemlich dass man in src-range tatsaechlich einen Bereich anstatt nur einer einzelnen IP-Adresse angeben kann. Aber ich sehe gerade, dass das dem TO bereits bekannt ist und ich die Frage falsch gelesen habe. Muss mich entschuldigen!

 

[bit-teufel]

Um das Thema nochmal aufzuwärmen. Mit IPtables 1,2 Mio Adress Regeln einzulesen funktioniert jetzt tadellos,
nur geht dann die Performance des Server derart in den Keller, das es unmöglich wird auf der Kiste zu arbeiten.
Nach längerem Suchen bin ich auf "ipset" gestoßen http://ipset.netfilter.org/ .
Die Befehle sind fast genau wie bei IPtables. Um die vielen Regeln einzulesen verwende ich folgenden Befehl:
"cat antip2p.txt | ipset --restore" und der Inhalt von "antip2p.txt" sieht so aus:

# Generated by ipset 4.5 on Tue Dec 7 17:37:56 2010
-N baum iptreemap --gc 300
-A baum 4.18.162.102-4.18.162.102
-A baum 4.36.44.3-4.36.44.3
-A baum 4.38.98.140-4.38.98.140
-A baum 4.53.2.12-4.53.2.15
und das ganze jetzt 1,2 mio. mal
COMMIT
#Completed on Tue Dec 7 17:37:58 2010

Jetzt erscheint allerdings ein neues Problem. Bei ca. 4 tausend Regeln stürtzt ipset ab.
"cat /var/log/messages" gibt folgenden Fehler aus:

Dec 9 11:35:04 imperator kernel: ipset: page allocation failure. order:0, mode:0x20
Dec 9 11:35:04 imperator kernel: Pid: 6898, comm: ipset Not tainted 2.6.36-default #1
Dec 9 11:35:04 imperator kernel: Call Trace:
Dec 9 11:35:04 imperator kernel: [<c0a7d132>] ? printk+0xf/0x11
Dec 9 11:35:04 imperator kernel: [<c01d1a99>] __alloc_pages_nodemask+0x47b/0x4e7
Dec 9 11:35:04 imperator kernel: [<c01f4bf4>] ? cache_alloc_refill+0x327/0x4b7
Dec 9 11:35:04 imperator kernel: [<c01f4b5a>] cache_alloc_refill+0x28d/0x4b7
Dec 9 11:35:04 imperator kernel: [<c01f5689>] kmem_cache_alloc+0x71/0xfc
Dec 9 11:35:04 imperator kernel: [<c0a7f577>] ? _raw_spin_lock_irq+0x2f/0x32
Dec 9 11:35:04 imperator kernel: [<c0f18720>] ? isapnp_init+0xff/0xbec
Dec 9 11:35:04 imperator kernel: [<c4d49d5e>] ? iptreemap_uadd+0x48f/0x571 [ip_set_iptreemap]
Dec 9 11:35:04 imperator kernel: [<c4d49c63>] iptreemap_uadd+0x394/0x571 [ip_set_iptreemap]
Dec 9 11:35:04 imperator kernel: [<c0f2d120>] ? ip_auto_config+0x1aa/0xe67
Dec 9 11:35:04 imperator kernel: [<c0f2d140>] ? ip_auto_config+0x1ca/0xe67
Dec 9 11:35:04 imperator kernel: [<c4ceb3dc>] ip_set_addip+0x29/0x54 [ip_set]
Dec 9 11:35:04 imperator kernel: [<c4cec158>] ip_set_sockfn_get+0x75d/0x819 [ip_set]
Dec 9 11:35:04 imperator kernel: [<c0f2d120>] ? ip_auto_config+0x1aa/0xe67
Dec 9 11:35:04 imperator kernel: [<c0865184>] nf_sockopt+0xdd/0x105
Dec 9 11:35:04 imperator kernel: [<c08651bf>] nf_getsockopt+0x13/0x15
Dec 9 11:35:04 imperator kernel: [<c089dd30>] ip_getsockopt+0x63/0x89
Dec 9 11:35:04 imperator kernel: [<c08b58cc>] raw_getsockopt+0x1f/0x94
Dec 9 11:35:04 imperator kernel: [<c0817494>] sock_common_getsockopt+0x13/0x18
Dec 9 11:35:04 imperator kernel: [<c0815bd3>] sys_getsockopt+0x60/0x7e
Dec 9 11:35:04 imperator kernel: [<c081717f>] sys_socketcall+0x149/0x1a6
Dec 9 11:35:04 imperator kernel: [<c012f358>] sysenter_do_call+0x12/0x28
Dec 9 11:35:04 imperator kernel: Mem-Info:
Dec 9 11:35:04 imperator kernel: DMA per-cpu:
Dec 9 11:35:04 imperator kernel: CPU 0: hi: 0, btch: 1 usd: 0
Dec 9 11:35:04 imperator kernel: Normal per-cpu:
Dec 9 11:35:04 imperator kernel: CPU 0: hi: 6, btch: 1 usd: 0
Dec 9 11:35:04 imperator kernel: HighMem per-cpu:
Dec 9 11:35:04 imperator kernel: CPU 0: hi: 186, btch: 31 usd: 24
Dec 9 11:35:05 imperator kernel: active_anon:5842 inactive_anon:5537 isolated_anon:0
Dec 9 11:35:05 imperator kernel: active_file:9466 inactive_file:19319 isolated_file:0
Dec 9 11:35:05 imperator kernel: unevictable:0 dirty:67 writeback:0 unstable:0
Dec 9 11:35:05 imperator kernel: free:75019 slab_reclaimable:1348 slab_unreclaimable:5652
Dec 9 11:35:05 imperator kernel: mapped:4980 shmem:28 pagetables:208 bounce:0
Dec 9 11:35:05 imperator kernel: DMA free:284kB min:248kB low:308kB high:372kB active_anon:0kB inactive_anon:0kB active_file:4kB inactive_file:444kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15868kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:36kB slab_unreclaimable:476kB kernel_stack:8kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Dec 9 11:35:05 imperator kernel: lowmem_reserve[]: 0 47 492 492
Dec 9 11:35:05 imperator kernel: Normal free:284kB min:764kB low:952kB high:1144kB active_anon:0kB inactive_anon:0kB active_file:5140kB inactive_file:5556kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:48760kB mlocked:0kB dirty:64kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:5356kB slab_unreclaimable:22132kB kernel_stack:1464kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Dec 9 11:35:05 imperator kernel: lowmem_reserve[]: 0 0 3555 3555
Dec 9 11:35:05 imperator kernel: HighMem free:299508kB min:444kB low:2232kB high:4020kB active_anon:23368kB inactive_anon:22148kB active_file:32720kB inactive_file:71276kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:455160kB mlocked:0kB dirty:204kB writeback:0kB mapped:19920kB shmem:112kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:832kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Dec 9 11:35:05 imperator kernel: lowmem_reserve[]: 0 0 0 0
Dec 9 11:35:05 imperator kernel: DMA: 1*4kB 1*8kB 3*16kB 5*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 284kB
Dec 9 11:35:05 imperator kernel: Normal: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 284kB
Dec 9 11:35:05 imperator kernel: HighMem: 1*4kB 2*8kB 0*16kB 1*32kB 1*64kB 1*128kB 1*256kB 2*512kB 3*1024kB 14*2048kB 65*4096kB = 299508kB
Dec 9 11:35:05 imperator kernel: 28813 total pagecache pages
Dec 9 11:35:05 imperator kernel: 0 pages in swap cache
Dec 9 11:35:05 imperator kernel: Swap cache stats: add 0, delete 0, find 0/0
Dec 9 11:35:05 imperator kernel: Free swap = 1052252kB
Dec 9 11:35:05 imperator kernel: Total swap = 1052252kB
Dec 9 11:35:05 imperator kernel: 131067 pages RAM
Dec 9 11:35:05 imperator kernel: 114686 pages HighMem
Dec 9 11:35:05 imperator kernel: 5659 pages reserved
Dec 9 11:35:05 imperator kernel: 36149 pages shared
Dec 9 11:35:05 imperator kernel: 33930 pages non-shared

Wieß jemand rat ?

Vielen Dank im Voraus
B.-D.

 

[rikola]

Ohne jetzt Kernelprogrammierer zu sein wuerde ich mal darauf tippen, dass ipset mehr Speicher anfordern muss, um all die Regeln zu speichern, als der Kernel - aus welchen Gruenden auch immer - ihm zugesteht. Da wirst Du wahrscheinlich nicht viel machen koennen.

 

[T-Virus]

Hatte diesen Thread mal eine Zeit lang beobachtet.
Dein Problem wird immer sein, dass du 1,2 Mio IP Adressen einladen und im Speicher halten musst.
Wie oben schon erwähnt wäre es wirklich sinnvoller einfaches alles zu sperren und nur benötigte Adressen freizugeben.
Oder du filters die 1,2 Mio Adressen so, dass du dann bestimmte Bereiche hast die du dann sperren musst.
Dies wäre vernünftiger als 1,2 Mio Adressen sperren zu wollen was scheinbar schon am einlesen scheitert...

T-Virus

 

[saeckereier]

Naja, 1,2 Mio Adressen belegen auch nur ein paar MB Hauptspeicher, abhängig davon wie sie abgelegt werden ist das also durchaus machbar. Ich denke aber auch, dass es daran scheitert, dass weder der Kernel noch ipsets auf so große Mengen ausgelegt sind.. Schreib doch mal die ipsets Mailingliste an..

 

[T-Virus]

Stimmt...
Hab bei meiner Milchmädchen Rechnung wohl aus MB GB gemacht :o)
Ansonsten kann es nur an der Menge liegen.
Würde trotzdem zum einfacheren Weg, siehe oben, raten.

T-Virus

 

[saeckereier]

Naja, wir haben seit Beginn an des Threads x-mal erwähnt, dass es sinnvoll wäre mal zu erzählen, warum man das tun will und das es sicherlich auch andere Lösungen geben kann. Wenn er das nicht preisgeben will, können wir halt auch nix anderes raten.

 

[bit-teufel]

Hallo Zusammen,

ich experimentiere gerade/immernoch mit IPset (v6.12.1) herum .
Das Problem mit dem geringen Speicher existiert auch in der aktuellen Version.
Ich habe auf meiner Büchse 100 GB Speicher davon 1GB normal RAM und 100GB SWAP.

free -m
total used free shared buffers cached
Mem: 986 151 835 0 4 50
-/+ buffers/cache: 96 890
Swap: 107832 0 107832

Also eigentlich sollte der RAM+SWAP für 2^32 IPadressen ausreichen ?

IPset stürtzt jetzt aber bei ca. 16 mio Adressen ab.
May 2 10:38:34 xenvm kernel: [ 2206.656155] ipset: page allocation failure: order:0, mode:0x20
May 2 10:38:34 xenvm kernel: [ 2206.656162] Pid: 4378, comm: ipset Not tainted 3.1.7-default #1
May 2 10:38:34 xenvm kernel: [ 2206.656167] Call Trace:
May 2 10:38:34 xenvm kernel: [ 2206.656180] [<ffffffff81100ace>] warn_alloc_failed+0xee/0x160
May 2 10:38:34 xenvm kernel: [ 2206.656187] [<ffffffff811049c9>] __alloc_pages_nodemask+0x629/0x860
May 2 10:38:34 xenvm kernel: [ 2206.656195] [<ffffffff81141891>] kmem_getpages+0x51/0x150
May 2 10:38:34 xenvm kernel: [ 2206.656200] [<ffffffff81142293>] fallback_alloc+0x163/0x220
May 2 10:38:34 xenvm kernel: [ 2206.656206] [<ffffffff81141fc1>] ? cache_grow+0x2a1/0x2c0
May 2 10:38:34 xenvm kernel: [ 2206.656212] [<ffffffff81142072>] ____cache_alloc_node+0x92/0x150
May 2 10:38:34 xenvm kernel: [ 2206.656220] [<ffffffff81d07a07>] ? cache_alloc_refill+0x19e/0x1e5
May 2 10:38:34 xenvm kernel: [ 2206.656226] [<ffffffff8114294d>] __kmalloc+0x16d/0x1f0
May 2 10:38:34 xenvm kernel: [ 2206.656233] [<ffffffff81a4855f>] ? hash_ip4_elem_add.constprop.12+0x6f/0xc0
May 2 10:38:34 xenvm kernel: [ 2206.656239] [<ffffffff81a4855f>] hash_ip4_elem_add.constprop.12+0x6f/0xc0
May 2 10:38:34 xenvm kernel: [ 2206.656245] [<ffffffff81a48c19>] ? hash_ip4_resize+0xf9/0x260
May 2 10:38:34 xenvm kernel: [ 2206.656250] [<ffffffff81a48c63>] hash_ip4_resize+0x143/0x260
May 2 10:38:34 xenvm kernel: [ 2206.656255] [<ffffffff81a46505>] ? hash_ip4_uadt+0x195/0x260
May 2 10:38:34 xenvm kernel: [ 2206.656262] [<ffffffff81a4108b>] call_ad+0xbb/0x260
May 2 10:38:34 xenvm kernel: [ 2206.656269] [<ffffffff81d28969>] ? _raw_spin_lock+0x9/0x10
May 2 10:38:34 xenvm kernel: [ 2206.656276] [<ffffffff81734020>] ? nla_parse+0x90/0xe0
May 2 10:38:34 xenvm kernel: [ 2206.656281] [<ffffffff81a41503>] ip_set_uadd+0x203/0x2b0
May 2 10:38:34 xenvm kernel: [ 2206.656288] [<ffffffff81b17fff>] ? in6_dump_addrs.isra.27+0xdf/0x190
May 2 10:38:34 xenvm kernel: [ 2206.656295] [<ffffffff81a142cf>] nfnetlink_rcv_msg+0x1ef/0x230
May 2 10:38:34 xenvm kernel: [ 2206.656301] [<ffffffff81a1410a>] ? nfnetlink_rcv_msg+0x2a/0x230
May 2 10:38:34 xenvm kernel: [ 2206.656306] [<ffffffff81a140e0>] ? nfnl_lock+0x20/0x20
May 2 10:38:34 xenvm kernel: [ 2206.656312] [<ffffffff81a10d69>] netlink_rcv_skb+0xa9/0xd0
May 2 10:38:34 xenvm kernel: [ 2206.656318] [<ffffffff819a2f1a>] ? __alloc_skb+0x4a/0x230
May 2 10:38:34 xenvm kernel: [ 2206.656323] [<ffffffff81a14010>] nfnetlink_rcv+0x10/0x20
May 2 10:38:34 xenvm kernel: [ 2206.656328] [<ffffffff81a10678>] netlink_unicast+0x2a8/0x2f0
May 2 10:38:34 xenvm kernel: [ 2206.656333] [<ffffffff819a2f4e>] ? __alloc_skb+0x7e/0x230
May 2 10:38:34 xenvm kernel: [ 2206.656339] [<ffffffff81a1098a>] netlink_sendmsg+0x2ca/0x360
May 2 10:38:34 xenvm kernel: [ 2206.656345] [<ffffffff81999836>] sock_sendmsg+0x106/0x120
May 2 10:38:34 xenvm kernel: [ 2206.656351] [<ffffffff819988be>] ? sock_destroy_inode+0x2e/0x40
May 2 10:38:34 xenvm kernel: [ 2206.656357] [<ffffffff8116ffc7>] ? destroy_inode+0x37/0x60
May 2 10:38:34 xenvm kernel: [ 2206.656363] [<ffffffff8199c5a9>] sys_sendto+0xf9/0x130
May 2 10:38:34 xenvm kernel: [ 2206.656370] [<ffffffff8117492b>] ? mntput_no_expire+0x2b/0xe0
May 2 10:38:34 xenvm kernel: [ 2206.656376] [<ffffffff811749fa>] ? mntput+0x1a/0x30
May 2 10:38:34 xenvm kernel: [ 2206.656381] [<ffffffff8115860e>] ? __fput+0x13e/0x200
May 2 10:38:34 xenvm kernel: [ 2206.656388] [<ffffffff81d30912>] system_call_fastpath+0x16/0x1b

Zum Thema warum ich das mache, ist das unter http://www.iblocklist.com/lists.php immer realtiv aktuelle Spamer IPs oder andere suboptimale IP Ranges aufgelistet werden
und ich genau diese Sperren will. Die Liste ist natürlich dynmaisch, weshalb sich die IPs relativ stark ändern und ich somit auch keine Statischen Subnetze sperren will, zumal
das Format der unter http://www.iblocklist.com/lists.php angeboten Listen nur auf IP Ragnes basiert. Und diese Flexibilät kann man nur wie IPset herstellen.

Aber zurück zum Thema, weshalb das Programm bei 16 Mio Adressen abstzürtzt.
Ich habe auch folgende Parameter ausprobiert:
ulimit -c unlimited
ulimit -d unlimited
ulimit -e unlimited
ulimit -f unlimited
ulimit -i unlimited
ulimit -l unlimited
ulimit -m unlimited
ulimit -n unlimited
ulimit -n 9999
ulimit -q unlimited
ulimit -r unlimited
ulimit -s unlimited
ulimit -t unlimited
ulimit -u unlimited
ulimit -v unlimited
ulimit -x unlimited
echo 1 > /proc/sys/vm/overcommit_memory
und unter "/boot/grub/menu.lst" -> vmalloc auf 5000M gesetzt,
um eventuell mehr Speicher allokieren zu können. Leider ohne Erfolg.
Irgendwie hat es den Eindruck das das Porgramm gar nicht den SWAP Speicher benutzt sondern nur den RAM.
Ist das ein Bug im Programm ? kennt jemand die Grenzen von IPset ?
Wie kann IPset sagen das es bitte den SWAP mitbenutzen soll ? ggf. auch duch Änderungen im Programmcode ?

Gibt es eine äquivalente alternative zu IPset in Bezug auf das Speichern von X Mio bzw. 4294967295 IP Adressen ?

Vielen Dank im Voraus
B.-D.