ubuntuusers.de

So....ich habe ne neue Regel mit der IP vom Hotel erstellt und versucht, auf meinen Server bei Strato zuzugreifen. Tcpdump gibt ne Ausgabe, die Regel also ist o.k.

 tcpdump -c 20 -vvveni venet0 host 124.120.XX.XXX
tcpdump: listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:45:29.411391 Out ethertype IPv4 (0x0800), length 200: (tos 0x10, ttl 64, id 34228, offset 0, flags [DF], proto TCP (6), length 184)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xcf87 (incorrect -> 0x1d01), seq 2082814752:2082814896, ack 1235253875, win 494, length 144
15:45:29.412344 Out ethertype IPv4 (0x0800), length 408: (tos 0x10, ttl 64, id 34229, offset 0, flags [DF], proto TCP (6), length 392)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd057 (incorrect -> 0xb9ba), seq 144:496, ack 1, win 494, length 352
15:45:29.656153  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 114, id 17518, offset 0, flags [DF], proto TCP (6), length 40)
    124.120.XX.XXX.17363 > 81.169.156.XX.XXX: Flags [.], cksum 0x1045 (correct), seq 1, ack 144, win 4320, length 0
15:45:29.656189 Out ethertype IPv4 (0x0800), length 392: (tos 0x10, ttl 64, id 34230, offset 0, flags [DF], proto TCP (6), length 376)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd047 (incorrect -> 0xa3f5), seq 496:832, ack 1, win 494, length 336
15:45:29.657288 Out ethertype IPv4 (0x0800), length 632: (tos 0x10, ttl 64, id 34231, offset 0, flags [DF], proto TCP (6), length 616)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd137 (incorrect -> 0xa7bf), seq 832:1408, ack 1, win 494, length 576
15:45:29.658278 Out ethertype IPv4 (0x0800), length 392: (tos 0x10, ttl 64, id 34232, offset 0, flags [DF], proto TCP (6), length 376)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd047 (incorrect -> 0xa18a), seq 1408:1744, ack 1, win 494, length 336
15:45:29.865046  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 114, id 17519, offset 0, flags [DF], proto TCP (6), length 40)
    124.120.XX.XXX.17363 > 81.169.156.XX.XXX: Flags [.], cksum 0x0f3d (correct), seq 1, ack 496, win 4232, length 0
15:45:29.865079 Out ethertype IPv4 (0x0800), length 392: (tos 0x10, ttl 64, id 34233, offset 0, flags [DF], proto TCP (6), length 376)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd047 (incorrect -> 0x3660), seq 1744:2080, ack 1, win 494, length 336
15:45:29.866381 Out ethertype IPv4 (0x0800), length 632: (tos 0x10, ttl 64, id 34234, offset 0, flags [DF], proto TCP (6), length 616)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd137 (incorrect -> 0xabfb), seq 2080:2656, ack 1, win 494, length 576
15:45:29.903142  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 114, id 17520, offset 0, flags [DF], proto TCP (6), length 40)
    124.120.XX.XXX.17363 > 81.169.156.XX.XXX: Flags [.], cksum 0x0a05 (correct), seq 1, ack 1744, win 4320, length 0
15:45:29.903192 Out ethertype IPv4 (0x0800), length 392: (tos 0x10, ttl 64, id 34235, offset 0, flags [DF], proto TCP (6), length 376)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd047 (incorrect -> 0xb8b0), seq 2656:2992, ack 1, win 494, length 336
15:45:29.904394 Out ethertype IPv4 (0x0800), length 632: (tos 0x10, ttl 64, id 34236, offset 0, flags [DF], proto TCP (6), length 616)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd137 (incorrect -> 0x996e), seq 2992:3568, ack 1, win 494, length 576
15:45:29.905339 Out ethertype IPv4 (0x0800), length 392: (tos 0x10, ttl 64, id 34237, offset 0, flags [DF], proto TCP (6), length 376)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd047 (incorrect -> 0x966f), seq 3568:3904, ack 1, win 494, length 336
15:45:29.906341 Out ethertype IPv4 (0x0800), length 392: (tos 0x10, ttl 64, id 34238, offset 0, flags [DF], proto TCP (6), length 376)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd047 (incorrect -> 0x98a5), seq 3904:4240, ack 1, win 494, length 336
15:45:30.149112  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 114, id 17521, offset 0, flags [DF], proto TCP (6), length 40)
    124.120.XX.XXX.17363 > 81.169.156.XX.XXX: Flags [.], cksum 0x0759 (correct), seq 1, ack 2656, win 4092, length 0
15:45:30.149144 Out ethertype IPv4 (0x0800), length 392: (tos 0x10, ttl 64, id 34239, offset 0, flags [DF], proto TCP (6), length 376)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd047 (incorrect -> 0xcde2), seq 4240:4576, ack 1, win 494, length 336
15:45:30.149481  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 114, id 17522, offset 0, flags [DF], proto TCP (6), length 40)
    124.120.XX.XXX.17363 > 81.169.156.XX.XXX: Flags [.], cksum 0x02e5 (correct), seq 1, ack 3568, win 4320, length 0
15:45:30.150163  In ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 114, id 17523, offset 0, flags [DF], proto TCP (6), length 40)
    124.120.XX.XXX.17363 > 81.169.156.XX.XXX: Flags [.], cksum 0x00ed (correct), seq 1, ack 4240, win 4152, length 0
15:45:30.150388 Out ethertype IPv4 (0x0800), length 1144: (tos 0x10, ttl 64, id 34240, offset 0, flags [DF], proto TCP (6), length 1128)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd337 (incorrect -> 0x4314), seq 4576:5664, ack 1, win 494, length 1088
15:45:30.151342 Out ethertype IPv4 (0x0800), length 392: (tos 0x10, ttl 64, id 34241, offset 0, flags [DF], proto TCP (6), length 376)
    81.169.156.XX.XXX > 124.120.XX.XXX.17363: Flags [P.], cksum 0xd047 (incorrect -> 0x4189), seq 5664:6000, ack 1, win 494, length 336
20 packets captured
20 packets received by filter
0 packets dropped by kernel

Werde dann jeweils, nachdem ich eine IP zugefügt habe, diese Regel in das Script eintragen, welches nach dem Reboot die Openvpn Forward Regel setzt 😉

@lubux:

was besagt eigentlich dieser iptables-Eintrag:

  15     1020 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID

erhalten bei:

 sudo iptables -nvx -L INPUT |grep DROP
Chain INPUT (policy DROP 0 packets, 0 bytes)
       0        0 DROP       tcp  --  venet0 *       175.193.107.122      0.0.0.0/0            tcp flags:0x02/0x02 state INVALID,NEW
       0        0 DROP       tcp  --  venet0 *       138.255.63.106       0.0.0.0/0            tcp flags:0x02/0x02 state INVALID,NEW
     110     6600 DROP       tcp  --  venet0 *       85.93.20.106         0.0.0.0/0            tcp flags:0x02/0x02 state INVALID,NEW
       0        0 DROP       tcp  --  venet0 *       185.110.132.159      0.0.0.0/0            tcp flags:0x02/0x02 state INVALID,NEW
       0        0 DROP       tcp  --  venet0 *       46.148.27.6          0.0.0.0/0            tcp flags:0x02/0x02 state INVALID,NEW
      15     1020 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
       0        0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:3306
       0        0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
       0        0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53

millerkhaolak schrieb:

Beim anlegen einer Regel mit

sudo ipset create drop_list_1 hash:ip family inet

bekomme ich nen Fehler:

ipset v6.29: Cannot open session to kernel.

Wie sind die Ausgaben von:

uname -a
cat /boot/config-$(uname -r) | grep -i ipset

?

millerkhaolak schrieb:

was besagt eigentlich dieser iptables-Eintrag:

  15     1020 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID

Naja, dass die Datenpakete nicht aus NEW-, RELATED- oder ESTABLISHED-Verbindungen stammen. Es können "Datenpaket-Konstrukte" sein, mit z. B. für stealth-scan (... oder so ähnlich) gesetzten Flags (d. h. untypisch).

uname -a
Linux xxxxx4.stratoserver.net 4.4.0-042stab127.2 #1 SMP Thu Jan 4 16:41:44 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux

cat /boot/config-$(uname -r) | grep -i ipset
cat: /boot/config-4.4.0-042stab127.2: No such file or directory

cat /boot/config-$(uname -a) | grep -i ipset
cat: /boot/config-Linux: No such file or directory
cat: xxxxx4.stratoserver.net: No such file or directory
cat: 4.4.0-042stab127.2: No such file or directory
cat: '#1': No such file or directory
cat: SMP: No such file or directory
cat: Thu: No such file or directory
cat: Jan: No such file or directory
cat: 4: No such file or directory
cat: '16:41:44': No such file or directory
cat: MSK: No such file or directory
cat: 2018: No such file or directory
cat: x86_64: No such file or directory
cat: x86_64: No such file or directory
cat: x86_64: No such file or directory
cat: GNU/Linux: No such file or directory

☹

lubux schrieb:

Naja, dass die Datenpakete nicht aus NEW-, RELATED- oder ESTABLISHED-Verbindungen stammen. Es können "Datenpaket-Konstrukte" sein, mit z. B. für stealth-scan (... oder so ähnlich) gesetzten Flags (d. h. untypisch).

Danke für die Erklärung 😉

millerkhaolak schrieb:

uname -a
Linux xxxxx4.stratoserver.net 4.4.0-042stab127.2 #1 SMP Thu Jan 4 16:41:44 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux

Ich denke dieser Kernel wird ipset evtl. nicht implementiert haben.

Z. B.:

:~$ cat /boot/config-$(uname -r) | grep -i ipset
CONFIG_NET_EMATCH_IPSET=m

cat /boot/config-$(uname -r) | grep -i ipset
cat: /boot/config-4.4.0-042stab127.2: No such file or directory

Das directory boot ist leer ☹

millerkhaolak schrieb:

... leer ...

Evtl. bei Strato nachfragen, warum ipset, mit diesem Kernel nicht verwendet werden kann.