Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider changes from janw-cz's and iglov's forks #4

Open
solardiz opened this issue Sep 30, 2021 · 4 comments
Open

Consider changes from janw-cz's and iglov's forks #4

solardiz opened this issue Sep 30, 2021 · 4 comments
Labels
enhancement New feature or request

Comments

@solardiz
Copy link
Member

https://github.com/janw-cz/scanlogd and its further fork https://github.com/iglov/scanlogd include significant changes, the rationale for some of which is unfortunately not explained - e.g., a commit message says "Fixed libpcap support", but it's never explained what was wrong with said support - it certainly works for some as-is, without those changes. @janw-cz and @iglov could want to send properly separated and reasoned PRs in here, or/and explain the changes in here.

@solardiz solardiz added the enhancement New feature or request label Sep 30, 2021
@iglov
Copy link

iglov commented Oct 1, 2021

Hey, @solardiz ! Sorry for a long time answer. Yep, as you can see i forked @janw-cz , just cuz there commits is newer. I have no idea what the "Fixed libpcap support" is :) And in my changes, i just added scanlogd.service and changed spec file to build scanlogd with libnids by default. So, I dont think my changes is useful and you don't need my changes in master branch :)

@janw-cz
Copy link

janw-cz commented Oct 1, 2021

Hi @solardiz,

I apologise for not being much descriptive in my commit comments.

I wanted to capture packets on all interfaces with libpcap. So I set the DEVICE to "any".

With the "any" device setting, the libpcap adds two bytes before the packet data to indicate interface number from which is the packet captured. I am not sure if this has changed with libpcap versions. I have Debian Bullseye (libpcap0.8 1.10.0-2) on ARM64.

With those two additional bytes, the packet was not parsed correctly and scanlogd did not work at all with libpcap and "any" device setting.

Other changes are:

  • a bugfix which is almost identical with the last commit in your repository (missing break statements inside case statement)
  • remains of my experiments when I was figuring out why does the capture work with one interface, but not with "any" (I should probably remove these changes):
    Replacing pcap_next with pcap_next_ex
    Changing the libpcap filter to pass only packets with SYN flag set.
  • I have enabled promiscuous mode, but now I believe that this is not necessary

I had thoughts about adding IPv6 support to scanlogd, so I have not invested my effort into libnids which does not support IPv6. (and is also not maintained for a long time)

BTW: I think that @iglov has improved integration of scanlogd with systemd, which is very nice, but I have not tested his changes yet.

I can cleanup and polish my changes and commit them into another repository for the pull request. My current fork is definitely not in a shape for a proper pull request, I just wanted to discuss if my changes could ever be pulled into the main scanlogd branch.

@janw-cz
Copy link

janw-cz commented Oct 1, 2021

That being said, I am very happy with scanlogd. I have not yet found any other port scan detection tool, which would detect SYN scan (nmap -sS). On the other hand, I am quite surprised, that scanlogd has not received much attention and popularity among the Linux community.

@janw-cz
Copy link

janw-cz commented Oct 10, 2021

I have made a clean clone of the openwall/scanlogd git and applied the fix for libpcap with "any" device setting. I have created a pull request with this change. During this process I have deleted my old fork, so @iglov fork lost its connection to my previous git clone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants