[opensuse] Portkocking problem
Hello - I am experiencing a problem with port knocking and am in need of some guidance from someone with a deeper understanding of the Linux/OpenSuSE architecture than I have. I have a computer with 2 NIC cards defined as eth0 and eth1. I am running 2 knockd daemons using nearly identical configuration files that define the knock sequences needed to open a port. The IP addresses for each card are on the same internal private subnet and assigned by a DHCPD server. When I send a knock sequence from my laptop to this system on it's eth0 interface all works fine. But when I send the same knock sequence to the eth1 interface it generally fails, although every once in awhile, as I am trying to figure out what is going on, it will work one time and then again fails on subsequent tests. I don't know what I am doing that causes these occasional successes. I have tried bringing down and back up the eth1 interface with ifup and ifdown, and tried restarting the firewalld, network, and knockd services. I have also tried putting both interfaces on the same (INTERNAL) zone (not what I really want to do, but this eliminates the possibility that placing each interface in separate zones could be causing problems.) I fired up wireshark on my target computer to monitor the eth1 interface (and the eth0 interface to see if there were any differences that might give me a clue) and wireshark does indeed show the arrival of the knock packets coming from my laptop, on both interfaces. So I know that I am sending the knocks OK and that they are indeed arriving on the appropriate interfaces. So I next inserted the following rule into the head of the INPUT chain of the iptables to monitor what it is seeing - *iptables -w -I INPUT 1 -s 192.168.10.10 -j LOG; tail -n-0 -f /var/log/messages|stdbuf -o0 grep 192.168.10.10* (192.168.10.10 is the IP address of my laptop) and while this does show the knocks coming in on eth0, it fails to show any knocks coming in on eth1 (except occasionally as I mentioned above). Does this command look correct? In particular I am not really sure where the LOG chain will send its output, I am guessing it is to the messages log file. (I have turned back on logging to the messages log file since I prefer using text files rather than the journal log which I find is too difficult to work with) I imagine that wireshark is directly monitoring eth1 by making low level calls to the eth1 driver and I would have expected iptables to be doing the same, but apparently not. So what lies between the low level driver for eth1 that wireshark is apparently using, and the beginning of the iptables chain that is blocking these port knock packets from reaching the iptables chains? Anyone with ideas? As always much appreciated and thanks in advance for taking the time to help me out! Marc.... -- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
28.07.2020 19:18, Marc Chamberlin пишет:
Hello - I am experiencing a problem with port knocking and am in need of some guidance from someone with a deeper understanding of the Linux/OpenSuSE architecture than I have. I have a computer with 2 NIC cards defined as eth0 and eth1. I am running 2 knockd daemons using nearly identical configuration files that define the knock sequences needed to open a port. The IP addresses for each card are on the same internal private subnet and assigned by a DHCPD server. When I send a knock sequence from my laptop to this system on it's eth0 interface all works fine. But when I send the same knock sequence to the eth1 interface it generally fails, although every once in awhile, as I am trying to figure out what is going on, it will work one time and then again fails on subsequent tests. I don't know what I am doing that
The most obvious reason would be that your system sends reply from different interface (there could be only one effective route to any network) and your software you are using to "knock" does not like it.
causes these occasional successes. I have tried bringing down and back up the eth1 interface with ifup and ifdown, and tried restarting the firewalld, network, and knockd services. I have also tried putting both interfaces on the same (INTERNAL) zone (not what I really want to do, but this eliminates the possibility that placing each interface in separate zones could be causing problems.)
I fired up wireshark on my target computer to monitor the eth1 interface (and the eth0 interface to see if there were any differences that might give me a clue) and wireshark does indeed show the arrival of the knock packets coming from my laptop, on both interfaces. So I know that I am sending the knocks OK and that they are indeed arriving on the appropriate interfaces. So I next inserted the following rule into the head of the INPUT chain of the iptables to monitor what it is seeing -
*iptables -w -I INPUT 1 -s 192.168.10.10 -j LOG; tail -n-0 -f /var/log/messages|stdbuf -o0 grep 192.168.10.10*
(192.168.10.10 is the IP address of my laptop) and while this does show the knocks coming in on eth0, it fails to show any knocks coming in on eth1 (except occasionally as I mentioned above). Does this command look correct?
iptables part yes.
In particular I am not really sure where the LOG chain will send its output, I am guessing it is to the messages log file.
Did you try to read manual page or other documentation before guessing? It sends output to kernel log buffer.
(I have turned back on logging to the messages log file since I prefer using text files rather than the journal log which I find is too difficult to work with)
Check your logging software configuration. You do not say what distribution you are using, what version, what log program fills in /var/log/messages so there is not much more to say.
I imagine that wireshark is directly monitoring eth1 by making low level calls to the eth1 driver and I would have expected iptables to be doing the same, but apparently not. So what lies between the low level driver for eth1 that wireshark is apparently using, and the beginning of the iptables chain that is blocking these port knock packets from reaching the iptables chains?
Much more plausible explanation is that these messages are filtered out by your log program.
Anyone with ideas? As always much appreciated and thanks in advance for taking the time to help me out! Marc....
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/07/2020 18.18, Marc Chamberlin wrote: ...
*iptables -w -I INPUT 1 -s 192.168.10.10 -j LOG; tail -n-0 -f /var/log/messages|stdbuf -o0 grep 192.168.10.10*
(192.168.10.10 is the IP address of my laptop) and while this does show the knocks coming in on eth0, it fails to show any knocks coming in on eth1 (except occasionally as I mentioned above). Does this command look correct? In particular I am not really sure where the LOG chain will send its output, I am guessing it is to the messages log file. (I have turned back on logging to the messages log file since I prefer using text files rather than the journal log which I find is too difficult to work with)
In the typical openSUSE configuration, they go to /var/log/firewall Try "dmesg" -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
28.07.2020 19:18, Marc Chamberlin пишет:
Hello - I am experiencing a problem with port knocking and am in need of some guidance from someone with a deeper understanding of the Linux/OpenSuSE architecture than I have. I have a computer with 2 NIC cards defined as eth0 and eth1. I am running 2 knockd daemons using nearly identical configuration files that define the knock sequences needed to open a port. The IP addresses for each card are on the same internal private subnet and assigned by a DHCPD server. When I send a knock sequence from my laptop to this system on it's eth0 interface all works fine. But when I send the same knock sequence to the eth1 interface it generally fails, although every once in awhile, as I am trying to figure out what is going on, it will work one time and then again fails on subsequent tests. I don't know what I am doing that The most obvious reason would be that your system sends reply from different interface (there could be only one effective route to any network) and your software you are using to "knock" does not like it. Thanks Andrei for responding! Maybe I need you to say more or explain how I should configure the routes. I thought I was addressing this in
On 7/28/20 10:47 AM, Andrei Borzenkov wrote: the ifconfig files for each interface. In /etc/sysconfig/network/ifcfg-eth0 I have set this parameter - DHCLIENT_SET_DEFAULT_ROUTE='yes' and for ifcfg-eth1 I set it - DHCLIENT_SET_DEFAULT_ROUTE='no' I read that this is what I am suppose to do from Google searches. I do not set any default route parameters in the YaST2->Network module. The dhcpd server is configured to set the same IP address as the default route for all the systems on the network. Perhaps I am misinterpreting what you are trying to say?
causes these occasional successes. I have tried bringing down and back up the eth1 interface with ifup and ifdown, and tried restarting the firewalld, network, and knockd services. I have also tried putting both interfaces on the same (INTERNAL) zone (not what I really want to do, but this eliminates the possibility that placing each interface in separate zones could be causing problems.)
I fired up wireshark on my target computer to monitor the eth1 interface (and the eth0 interface to see if there were any differences that might give me a clue) and wireshark does indeed show the arrival of the knock packets coming from my laptop, on both interfaces. So I know that I am sending the knocks OK and that they are indeed arriving on the appropriate interfaces. So I next inserted the following rule into the head of the INPUT chain of the iptables to monitor what it is seeing -
*iptables -w -I INPUT 1 -s 192.168.10.10 -j LOG; tail -n-0 -f /var/log/messages|stdbuf -o0 grep 192.168.10.10*
(192.168.10.10 is the IP address of my laptop) and while this does show the knocks coming in on eth0, it fails to show any knocks coming in on eth1 (except occasionally as I mentioned above). Does this command look correct? iptables part yes.
In particular I am not really sure where the LOG chain will send its output, I am guessing it is to the messages log file. Did you try to read manual page or other documentation before guessing? It sends output to kernel log buffer.
Yes I do try to RTFMs before asking questions, ;-) and I did my best to grok the man pages, and yes I did read that output from kernel logging is sent to the "kernel log file" Trouble is that I do not find a kern.log file in /var/log so I assumed that like most other things which get logged, the log messages from the kernel end up in /var/log/messages. I guess I am wrong to make that assumption, but can you tell me how to activate and direct the kernel log messages to /var/log/kern.log? Most of the documentation I find, in Google searches, seem to imply this is done by default in other distros, and apparently in OpenSuSE it is not? I don't find any documentation when I search for "opensuse kernel log file configuration" that seems relevant. On a lark, I did try to start the kernel logging service - klogd - thinking that might be what is needed to see the kernel log messages in a separate file, but it refuses to start. I get the following message which I do not grok -
systemctl start klogd Failed to start klogd.service: Operation refused, unit klogd.service may be requested by dependency only (it is configured to refuse manual start/stop).
(I have turned back on logging to the messages log file since I prefer using text files rather than the journal log which I find is too difficult to work with)
Check your logging software configuration. You do not say what distribution you are using, what version, what log program fills in /var/log/messages so there is not much more to say.
Sorry, I guess I didn't think that was going to be relevant. On the system I am testing, I am running OpenSuSE Leap 15.0 using rsyslogd 8.33.1 for my logging service.'
I imagine that wireshark is directly monitoring eth1 by making low level calls to the eth1 driver and I would have expected iptables to be doing the same, but apparently not. So what lies between the low level driver for eth1 that wireshark is apparently using, and the beginning of the iptables chain that is blocking these port knock packets from reaching the iptables chains?
Much more plausible explanation is that these messages are filtered out by your log program.
Hmmm, OK, I need more help here then, I dunno how to configure filtering, didn't even know that was possible.
Anyone with ideas? As always much appreciated and thanks in advance for taking the time to help me out! Marc....
-- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/Attached is my public key to be used for encryption and sending encrypted email to marc@marcchamberlin.com./)
On 28/07/2020 22.41, Marc Chamberlin wrote:
On 7/28/20 10:47 AM, Andrei Borzenkov wrote:
28.07.2020 19:18, Marc Chamberlin пишет:
...
In particular I am not really sure where the LOG chain will send its output, I am guessing it is to the messages log file. Did you try to read manual page or other documentation before guessing? It sends output to kernel log buffer.
Yes I do try to RTFMs before asking questions, ;-) and I did my best to grok the man pages, and yes I did read that output from kernel logging is sent to the "kernel log file" Trouble is that I do not find a kern.log file in /var/log so I assumed that like most other things which get logged, the log messages from the kernel end up in /var/log/messages. I guess I am wrong to make that assumption, but can you tell me how to activate and direct the kernel log messages to /var/log/kern.log? Most of the documentation I find, in Google searches, seem to imply this is done by default in other distros, and apparently in OpenSuSE it is not? I don't find any documentation when I search for "opensuse kernel log file configuration" that seems relevant.
Because in openSUSE the kernel messages go to /var/log/messages by default, except the firewall related messages that go to /var/log/firewall. IF syslog is enabled, which I think it is currently by default, but nor sure. AND if you are using SuSEfirewall2. If you are using the new firewall daemon, the log is disabled by default and you have to activate it in the firewall configuration, I think.
On a lark, I did try to start the kernel logging service - klogd - thinking that might be what is needed to see the kernel log messages in a separate file, but it refuses to start. I get the following message which I do not grok -
No need.
Check your logging software configuration. You do not say what distribution you are using, what version, what log program fills in /var/log/messages so there is not much more to say.
Sorry, I guess I didn't think that was going to be relevant. On the system I am testing, I am running OpenSuSE Leap 15.0 using rsyslogd 8.33.1 for my logging service.'
Good. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
On 7/28/20 2:04 PM, Carlos E. R. wrote:
Because in openSUSE the kernel messages go to /var/log/messages by default, except the firewall related messages that go to /var/log/firewall.
IF syslog is enabled, which I think it is currently by default, but nor sure.
AND if you are using SuSEfirewall2. If you are using the new firewall daemon, the log is disabled by default and you have to activate it in the firewall configuration, I think.
Hi Carlos, I am using firewalld on my systems and yes there is a configuration parameter with an awful reverse or negative intonation called LogDenied. It is not well documented in the man page and is confusing. Currently it is set - LogDenied=off To my untrained eyes this implies that everything will be logged by default as I have never changed it, so this is the way it came with the distribution. If you are correct and this setting is disabling logging then IMHO someone really needs to rethink what to call this parameter. (Should I be consulting Harry Potter? Or is this a classical example of an engineer who wrote firewalld was so deep in his world that he forgot that he was communicating with muggles? Just a bit of retorical humor for the humor impaired...) I will try setting it to ALL to see if that helps.... Marc...
28.07.2020 23:41, Marc Chamberlin пишет:
(I have turned back on logging to the messages log file since I prefer using text files rather than the journal log which I find is too difficult to work with)
Check your logging software configuration. You do not say what distribution you are using, what version, what log program fills in /var/log/messages so there is not much more to say.
Sorry, I guess I didn't think that was going to be relevant. On the system I am testing, I am running OpenSuSE Leap 15.0 using rsyslogd 8.33.1 for my logging service.'
On Leap 15.1 default rsylog.conf has # # firewall messages into separate file and stop their further processing # if ($syslogfacility-text == 'kern') and \ ($msg contains 'IN=' and $msg contains 'OUT=') \ then { -/var/log/firewall stop } In any case, you still have journal whether you like it or not, and journal stores everything. Check kernel log (dmesg), check journal - are messages there?
I imagine that wireshark is directly monitoring eth1 by making low level calls to the eth1 driver and I would have expected iptables to be doing the same, but apparently not. So what lies between the low level driver for eth1 that wireshark is apparently using, and the beginning of the iptables chain that is blocking these port knock packets from reaching the iptables chains?
Much more plausible explanation is that these messages are filtered out by your log program.
Hmmm, OK, I need more help here then, I dunno how to configure filtering, didn't even know that was possible.
Seriously? Even ancient syslogd supported storing different kinds of messages in different files.
On 29/07/2020 06.34, Andrei Borzenkov wrote:
28.07.2020 23:41, Marc Chamberlin пишет:
...
On Leap 15.1 default rsylog.conf has
# # firewall messages into separate file and stop their further processing # if ($syslogfacility-text == 'kern') and \ ($msg contains 'IN=' and $msg contains 'OUT=') \ then { -/var/log/firewall stop }
In any case, you still have journal whether you like it or not, and journal stores everything. Check kernel log (dmesg), check journal - are messages there?
Journal can be configured to discard all :-P I did so for some time in this computer, I think. But re-enabled it because systemctl was not happy about it. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 29/07/2020 02.36, Marc Chamberlin wrote:
On 7/28/20 2:04 PM, Carlos E. R. wrote:
Because in openSUSE the kernel messages go to /var/log/messages by default, except the firewall related messages that go to /var/log/firewall.
IF syslog is enabled, which I think it is currently by default, but nor sure.
AND if you are using SuSEfirewall2. If you are using the new firewall daemon, the log is disabled by default and you have to activate it in the firewall configuration, I think.
Hi Carlos, I am using firewalld on my systems and yes there is a configuration parameter with an awful reverse or negative intonation called LogDenied. It is not well documented in the man page and is confusing. Currently it is set - LogDenied=off To my untrained eyes this implies that everything will be logged by default as I have never changed it, so this is the way it came with the distribution. If you are correct and this setting is disabling logging then IMHO someone really needs to rethink what to call this parameter. (Should I be consulting Harry Potter? Or is this a classical example of an engineer who wrote firewalld was so deep in his world that he forgot that he was communicating with muggles? Just a bit of retorical humor for the humor impaired...) I will try setting it to ALL to see if that helps....
:-) I don't have it installed on this computer (yet!), but yes, that should do it. Guessing, as I can't look, it can log accepted packages (connections?) and/or denied packages. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 7/29/20 12:19 AM, Carlos E. R. wrote:
On 29/07/2020 06.34, Andrei Borzenkov wrote:
28.07.2020 23:41, Marc Chamberlin пишет:
...
On Leap 15.1 default rsylog.conf has
# # firewall messages into separate file and stop their further processing # if ($syslogfacility-text == 'kern') and \ ($msg contains 'IN=' and $msg contains 'OUT=') \ then { -/var/log/firewall stop }
In any case, you still have journal whether you like it or not, and journal stores everything. Check kernel log (dmesg), check journal - are messages there?
Journal can be configured to discard all :-P
I did so for some time in this computer, I think. But re-enabled it because systemctl was not happy about it.
Carlos, Andrie, all - I ran the following command to monitor dmesg - dmesg -H -w | grep DST=192.168.10.51 | grep DPT=12 to filter out the knocks and yes the kernel log is showing the knocks (although somewhat delayed quite a bit after they are sent) yet my logging of what iptables sees, the messages file, and the knockd logs do not show these knocks. The one other symptom that is also puzzling is that after I restart all the services sometimes the knock sequence does work ONE time, and then they stop working. The following shows what is in the INPUT chain of iptables - Chain INPUT (policy ACCEPT) target prot opt source destination LOG all -- 192.168.10.10 anywhere LOG level warning ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere INPUT_direct all -- anywhere anywhere INPUT_ZONES_SOURCE all -- anywhere anywhere INPUT_ZONES all -- anywhere anywhere LOG all -- anywhere anywhere ctstate INVALID LOG level warning prefix "STATE_INVALID_DROP: " DROP all -- anywhere anywhere ctstate INVALID LOG all -- anywhere anywhere LOG level warning prefix "FINAL_REJECT: " REJECT all -- anywhere anywhere reject-with icmp-host-prohibited which should capture and log the knocks comping from my laptop. Still stumped, Marc... -- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/Attached is my public key to be used for encryption and sending encrypted email to marc@marcchamberlin.com./)
On 7/31/20 2:48 PM, Marc Chamberlin wrote:
On 7/29/20 12:19 AM, Carlos E. R. wrote:
On 29/07/2020 06.34, Andrei Borzenkov wrote:
28.07.2020 23:41, Marc Chamberlin пишет: ...
On Leap 15.1 default rsylog.conf has
# # firewall messages into separate file and stop their further processing # if ($syslogfacility-text == 'kern') and \ ($msg contains 'IN=' and $msg contains 'OUT=') \ then { -/var/log/firewall stop }
In any case, you still have journal whether you like it or not, and journal stores everything. Check kernel log (dmesg), check journal - are messages there? Journal can be configured to discard all :-P
I did so for some time in this computer, I think. But re-enabled it because systemctl was not happy about it.
Carlos, Andrie, all - I ran the following command to monitor dmesg -
dmesg -H -w | grep DST=192.168.10.51 | grep DPT=12
to filter out the knocks and yes the kernel log is showing the knocks (although somewhat delayed quite a bit after they are sent) yet my logging of what iptables sees, the messages file, and the knockd logs do not show these knocks. The one other symptom that is also puzzling is that after I restart all the services sometimes the knock sequence does work ONE time, and then they stop working.
The following shows what is in the INPUT chain of iptables -
Chain INPUT (policy ACCEPT) target prot opt source destination LOG all -- 192.168.10.10 anywhere LOG level warning ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere INPUT_direct all -- anywhere anywhere INPUT_ZONES_SOURCE all -- anywhere anywhere INPUT_ZONES all -- anywhere anywhere LOG all -- anywhere anywhere ctstate INVALID LOG level warning prefix "STATE_INVALID_DROP: " DROP all -- anywhere anywhere ctstate INVALID LOG all -- anywhere anywhere LOG level warning prefix "FINAL_REJECT: " REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
which should capture and log the knocks comping from my laptop.
Still stumped, Marc...
Ping? :-) Anyone got an idea as to why the kernel log (dmesg) see's my portknocks, yet iptables and knockd don't? Thanks in advance, Marc...
On 05/08/2020 03.27, Marc Chamberlin wrote:
On 7/31/20 2:48 PM, Marc Chamberlin wrote:
On 7/29/20 12:19 AM, Carlos E. R. wrote:
On 29/07/2020 06.34, Andrei Borzenkov wrote:
28.07.2020 23:41, Marc Chamberlin пишет: ...
On Leap 15.1 default rsylog.conf has
# # firewall messages into separate file and stop their further processing # if ($syslogfacility-text == 'kern') and \ ($msg contains 'IN=' and $msg contains 'OUT=') \ then { -/var/log/firewall stop }
In any case, you still have journal whether you like it or not, and journal stores everything. Check kernel log (dmesg), check journal - are messages there? Journal can be configured to discard all :-P
I did so for some time in this computer, I think. But re-enabled it because systemctl was not happy about it.
Carlos, Andrie, all - I ran the following command to monitor dmesg -
dmesg -H -w | grep DST=192.168.10.51 | grep DPT=12
to filter out the knocks and yes the kernel log is showing the knocks (although somewhat delayed quite a bit after they are sent)
The delay could be due to the pipe handling (the buffering).
yet my logging of what iptables sees, the messages file, and the knockd logs do not show these knocks. The one other symptom that is also puzzling is that after I restart all the services sometimes the knock sequence does work ONE time, and then they stop working.
The following shows what is in the INPUT chain of iptables -
Chain INPUT (policy ACCEPT) target prot opt source destination LOG all -- 192.168.10.10 anywhere LOG level warning ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere INPUT_direct all -- anywhere anywhere INPUT_ZONES_SOURCE all -- anywhere anywhere INPUT_ZONES all -- anywhere anywhere LOG all -- anywhere anywhere ctstate INVALID LOG level warning prefix "STATE_INVALID_DROP: " DROP all -- anywhere anywhere ctstate INVALID LOG all -- anywhere anywhere LOG level warning prefix "FINAL_REJECT: " REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
which should capture and log the knocks comping from my laptop.
Still stumped, Marc...
Ping? :-) Anyone got an idea as to why the kernel log (dmesg) see's my portknocks, yet iptables and knockd don't? Thanks in advance, Marc...
Sorry, no ideas. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
05.08.2020 04:27, Marc Chamberlin пишет:
Ping? :-) Anyone got an idea as to why the kernel log (dmesg) see's my portknocks, yet iptables and knockd don't?
dmesg does not "see" anything. It displays content of kernel log buffer. If you see your knocks in dmesg something logged them into kernel log. And this "something" *is* iptables. I have no idea how knockd works, but general rule is that multiple active physical interfaces with different addresses on the same L2 network do not have any advantage but may cause subtle issues. May be this is one of them. ... hmm ... briefly looking at knockd it apparently listens on one interface only. Why do you expect it to work with two different interfaces simultaneously?
05.08.2020 04:27, Marc Chamberlin пишет:
Ping? :-) Anyone got an idea as to why the kernel log (dmesg) see's my portknocks, yet iptables and knockd don't? dmesg does not "see" anything. It displays content of kernel log buffer. If you see your knocks in dmesg something logged them into kernel log. And this "something" *is* iptables.
I have no idea how knockd works, but general rule is that multiple active physical interfaces with different addresses on the same L2 network do not have any advantage but may cause subtle issues. May be this is one of them.
... hmm ... briefly looking at knockd it apparently listens on one interface only. Why do you expect it to work with two different interfaces simultaneously? I have two separate knockd services running, one for each interface (knockd which defaults to eth0, and knockd@eth1). This works on other systems I have, so apparently something is messed up on this one computer... If dmesg is reporting what iptables is reporting then I guess my attempt at logging everything on the INPUT iptables chain is not working right. I will take another look at it. Thanks Andrei for your help, I will report back if I find anything interesting, I think my setup should work and this is just plain weird that it isn't... I am
On 8/5/20 12:03 PM, Andrei Borzenkov wrote: thinking of just using one NIC and assign the second IP address as a virtual address to it also, to see if that makes a difference. Marc... -- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/Attached is my public key to be used for encryption and sending encrypted email to marc@marcchamberlin.com./)
05.08.2020 22:49, Marc Chamberlin пишет:
I have two separate knockd services running, one for each interface (knockd which defaults to eth0, and knockd@eth1). This works on other systems I have, so apparently something is messed up on this one computer...
Or something is messed up on network path to this computer. Stop both knockd. Start tcpdump or dumpcap/tshark/wireshark/... on both interfaces, do not put interfaces in promiscuous mode to match what knockd does (option -p for tcpdump/dumpcap/tshark). Start packet capture on client used to knock. Try to knock on both addresses. Make sure to capture full sequence from the very beginning. Do it once with firewall stopped, and once with firewall active. If possible, do simultaneous packet capture on your switch. Intelligent switches often offer port mirroring feature where you can duplicate all traffic to/from one port to another port, so you can connect to mirror port and capture traffic. This allows you to see what actually happens on port in question. Compare results. Make them available if you have questions.
participants (4)
-
Andrei Borzenkov
-
Carlos E. R.
-
Carlos E. R.
-
Marc Chamberlin