From Newsgroup: rocksolid.nodes.help

Hello!

What is a good way to identify the source of the Attempt to create:
lines in debug log?

I would like to identify the apache log strings to check if a f2b rule
is possible.

rocksolid Attempt to create:
/var/spool/rslight//de.admin.net-abuse.news
Fehlverhalten-data.db3 for: de.admin.net-abuse.news Fehlverhalt

This looks either like intended to destroy something or a bug.
--
kind regards
Marco

Send spam to 1723733944muell@cartoonies.org

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: rocksolid.nodes.help

On Thu, 15 Aug 2024 17:00:34 +0200, Marco Moock wrote:

Hello!

What is a good way to identify the source of the Attempt to create:
lines in debug log?

I would like to identify the apache log strings to check if a f2b rule
is possible.

rocksolid Attempt to create:
/var/spool/rslight//de.admin.net-abuse.news
Fehlverhalten-data.db3 for: de.admin.net-abuse.news Fehlverhalt

This looks either like intended to destroy something or a bug.

This was added to debug log to help me find causes (gaps in checking) of malicious activity. Meaning people trying SQL injections, which are obvious when you see them in the name of the file it tries to create.

If it's a real group name, it's most likely simply that this group is in
the Newsgroups header of a valid message, but you don't have the group that
it tries to create. This is not malicious, so not a good idea to block.

So, if the message header contains:
'Newsgroups: some.group,another.group'

and you have 'some.group', the message is accepted, but it can't also write
it to the article.db3 for 'another.group' because you don't have that
group. Not an error, just a notice.

You would need to ALSO check for obvious SQL statements in the line in debug.log before adding a blocking rule to fail2ban.

If we eventually find zero attempts at SQL injection in the debug.log, that means we are fully filtering these attmpts. If that proves to be true, I'll remove the notices from debug.log.

I hope that makes sense :)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: rocksolid.nodes.help

On 15.08.2024 um 08:50 Uhr Retro Guy wrote:

You would need to ALSO check for obvious SQL statements in the line
in debug.log before adding a blocking rule to fail2ban.

How can I identify the IP of that?
This would help me to find the lines in access apache log.

I would like to find out which action causes that, so I can find the
abusers and block them.
--
kind regards
Marco

Send spam to 1723704656muell@cartoonies.org

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: rocksolid.nodes.help

On Thu, 15 Aug 2024 18:15:49 +0000, Marco Moock wrote:

On 15.08.2024 um 08:50 Uhr Retro Guy wrote:

You would need to ALSO check for obvious SQL statements in the line
in debug.log before adding a blocking rule to fail2ban.

How can I identify the IP of that?
This would help me to find the lines in access apache log.

I would like to find out which action causes that, so I can find the
abusers and block them.

You should be able to see them entirely in the apache log. A filter
would need to look for SQL commands. My comment above is incorrect, you
do not need to ALSO check the rslight log. Don't know what I was
thinking.

So, a f2b filter regex that looks for common SQL commands should do it.
You don't need to bother with the rslight log for that.
--
Retro Guy
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: rocksolid.nodes.help

On 15.08.2024 um 18:47 Uhr Retro Guy wrote:

On Thu, 15 Aug 2024 18:15:49 +0000, Marco Moock wrote:

On 15.08.2024 um 08:50 Uhr Retro Guy wrote:

You would need to ALSO check for obvious SQL statements in the line
in debug.log before adding a blocking rule to fail2ban.

How can I identify the IP of that?
This would help me to find the lines in access apache log.

I would like to find out which action causes that, so I can find the abusers and block them.

You should be able to see them entirely in the apache log. A filter
would need to look for SQL commands. My comment above is incorrect,
you do not need to ALSO check the rslight log. Don't know what I was thinking.

So, a f2b filter regex that looks for common SQL commands should do
it. You don't need to bother with the rslight log for that.

I tried to find it, I can't find it.
I've grepped for various terms, I can't find something problematic.
--
kind regards
Marco

Send spam to 1723740441muell@cartoonies.org

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: rocksolid.nodes.help

On Fri, 16 Aug 2024 13:34:45 +0000, Marco Moock wrote:

On 15.08.2024 um 18:47 Uhr Retro Guy wrote:

On Thu, 15 Aug 2024 18:15:49 +0000, Marco Moock wrote:

On 15.08.2024 um 08:50 Uhr Retro Guy wrote:

You would need to ALSO check for obvious SQL statements in the line
in debug.log before adding a blocking rule to fail2ban.

How can I identify the IP of that?
This would help me to find the lines in access apache log.

I would like to find out which action causes that, so I can find the
abusers and block them.

You should be able to see them entirely in the apache log. A filter
would need to look for SQL commands. My comment above is incorrect,
you do not need to ALSO check the rslight log. Don't know what I was
thinking.

So, a f2b filter regex that looks for common SQL commands should do
it. You don't need to bother with the rslight log for that.

I tried to find it, I can't find it.
I've grepped for various terms, I can't find something problematic.

Maybe there is nothing problematic.

I'm not sure of the name of apache access log so using access.log as an example. Maybe just try to grep a few things:

grep -E "AND" access.log

Use a SQL command in the quotes, and use upper case.

I find stuff like:
208.131.130.90 - - [16/Aug/2024:05:34:35 +0000] "GET /computers/article-flat.php?group=%27nvOpzp;%20AND%201=1%20OR%20(%3C%27%22%3EiKO)),&id=%27nvOpzp;%20AND%201=1%20OR%20(%3C%27%22%3EiKO)),&first=%27nvOpzp;%20AND%201=1%20OR%20(%3C%27%22%3EiKO)),&last=%27nvOpzp;%20AND%201=1%20OR%20(%3C%27%22%3EiKO)),
HTTP/1.1" 404 1889 "-" "-"
--
Retro Guy
--- Synchronet 3.21a-Linux NewsLink 1.2