Solved Many connections from amazonaws? And Abuseipdb config to block abusers.

@jamgames2 Just wondering about something. Could it be that this is not working as most of the reports are not cluster member reports?
So it won't report anything because that text is not present?
Maybe it need soms if/then construction? I don't know if it's wise to turn of CSF clustering, would also be a workaround.
 
I don't use CSF Cluster, so without cluster should be fine. Add some if/else condition before censor text could be helpful. Because I don't know about perl script too much, so it need some debug testing in many way.
 
my $comment = $message . "; Ports: " . $ports . "; Direction: " . $inout
. "; Trigger: " . $trigger . ";
$comment =~ s/Cluster member.*said,/***/g;

I just found your weird coding that showing to me.

Code:
my $comment = $message . "; Ports: " . $ports . "; Direction: " . $inout
    . "; Trigger: " . $trigger;
$comment =~ s/Cluster member.*said,/***/g;

it should be like this.
 
it should be like this.
It's exactly the same. Your line looks different (wider) because you used the forum's code tag.
I tested it by copying and pasting into notepad and it's exactly the same.

If you look post #37 you see that I used it correctly.

Or do you mean that your extra code needs to be on a seperate line?
 
I marks with red color. it wrong syntax ' . "; '

this will be same error as in PHP script be like

Code:
<?php
echo $message . ";
 
I've thought of that too, but I doubt that this is the case.
The firewall is blocking them afterwards, because there are too many connections made, and so generating the firewall message.
So before that time, it lets the connections through. So it seems it's some kind of attach on the 443 port without making a connection to some domain. Probably just attacking the ip on port 443.

Asked ChatGPT :D

And reason #1 and/or #2 sounds more probably for port scanning or connections to ports other than web server itself

The fact that IP 3.231.22.147 does not show up in your web server logs but is reported by CSF Firewall could be due to several reasons:
  1. Different logging levels: Web server logs and firewall logs have different logging levels and focus on different aspects of incoming connections. The web server logs typically record HTTP(S) requests, while the CSF Firewall logs monitor various types of connections at a lower level. It's possible that the IP address is connecting to your server on a different port or using a different protocol, which is not recorded in the web server logs.
  2. Connection attempts without requests: The IP address might be establishing connections without actually sending any HTTP(S) requests to your web server. This could explain why the firewall detects the connections, but there is no record in the web server logs. This could be a sign of malicious activity, such as port scanning or a reconnaissance attempt.
  3. Log rotation or archiving: Web server logs might have undergone rotation or archiving, causing older logs to be overwritten or moved to a different location. If the connections from the IP address occurred before the most recent log entries, you may need to examine older logs or archives to find the relevant information.
  4. Log filtering or misconfiguration: The web server logs could be configured to filter out specific IP addresses, connection types, or log levels, resulting in the absence of 3.231.22.147 in the logs. Double-check the log configurations for any filtering rules
edit: oh forgot your screenshot shows port 443 but they're in SYNC_RECV and TIME_WAIT states only right?

When CSF Firewall reports that IP 3.231.22.147 hit the CT limits for SYN_RECV and TIME_WAIT, it means that the IP address had a high number of connections in these two specific states.
  1. SYN_RECV: This state indicates that a connection request (SYN) has been received by the server, and the server has responded with an acknowledgment (SYN-ACK), but it is still waiting for the final acknowledgment (ACK) from the client. A high number of connections in SYN_RECV state could signify a SYN flood attack, which is a type of Denial of Service (DoS) attack. In this attack, the attacker sends a large number of SYN packets, causing the server to exhaust its resources while waiting for ACKs that never arrive.
  2. TIME_WAIT: This state occurs after a TCP connection has been closed, and the server is waiting for a period of time before completely releasing the connection's resources. This waiting period is necessary to ensure that any delayed packets from the closed connection do not interfere with new connections. A high number of connections in TIME_WAIT state could indicate that the IP address is rapidly opening and closing connections, which could be a sign of a scanning activity or an attempt to exhaust server resources.
So yeah SYN flood attack :)
 
Last edited:
And reason #1 and/or #2 sounds more probably for port scanning or connections to ports other than web server itself
In that case it must be #2 imho, since webservers may have different log levels, but I don't find it in the system log either, which almost registers any kind of connection attempt.

I've looked up the syn_recv (which are mostly not that many) and the time_wait explanations before, which is why I came to my conclusion mainly also because even the syslog did not mention the connection.

So yeah SYN flood attack :)
Exacly. :)

@jamgames2 I have it like this now like you said:
Code:
my $comment = $message . "; Ports: " . $ports . "; Direction: " . $inout . "; Trigger: " . $trigger;
$comment =~ s/Cluster member.*said,/***/g;
but the script is still not reporting at all for some reason. The script on one server without adjustment is reporting. Maybe it indeed needs the condition that it will report also if the cluster text is not present.
Maybe @zEitEr knows why it's not working? I thought he's also good at scripting.
 
maybe you could paste full code here, remove your "key" or sensitive data from the code. so @zEitEr can help you. Sometime if not see full code, I don't know what's wrong with code.
 
If you clarify what is it for, probably I could suggest a fix.
Oke the script will post ip's to the abuseipdb database.
But we also use cluster. If a cluster reports, it reports the hostname and ip address too of the reporting server (like in post #28) and we don't want that.

I'm using exactly this script as mentioned here (click):
Code:
#!/usr/bin/perl
# This file was written as an executable to be used in the auto report function
# of csf and lfd. By replacing $YOUR_API_KEY below with your abuseipdb api key,
# allows you to use this code to integrate your csf system with abuseipdb.com
use strict;
use warnings;
use HTTP::Tiny;
use JSON;

# Gather the information from the commandline passed by lfd
my $ports = $ARGV[1];
my $inout = $ARGV[3];
my $message = $ARGV[5];
my $logs = $ARGV[6];
my $trigger = $ARGV[7];
my $comment = $message . "; Ports: " . $ports . "; Direction: " . $inout
    . "; Trigger: " . $trigger . "; Logs: " . $logs;
my $ua = HTTP::Tiny->new;

my $url = 'https://api.abuseipdb.com/api/v2/report';

my $data = {
    ip => $ARGV[0],
    comment => $comment,
    categories => 14
};

my %options = (
   "headers", {
       "Key" => "$YOUR_API_KEY",
       "Accept" => "application/json"
   },
);

my $response = $ua->post_form($url, $data, \%options);
my $json = JSON->new;
my $output = $json->pretty->encode($json->decode($response->{'content'}));

if ($response->{'status'} == 200){
    print "Report Succesful!\n" . $output;
} elsif ($response->{'status'} == 429) {
    print $output;
} elsif ($response->{'status'} == 422) {
    print $output;
} elsif ($response->{'status'} == 401) {
    print $output;
}

So what I want to achieve is to have the report made. Which is functioning. But if the report comes from the clustering server I don't want to have it show full hostname and ip but maybe something like this:
Cluster member 95.xxxxxx (FI/Finland/server.xxxxx.nl) said,
and then the rest of the report, instead of
Cluster member 12.34.56.78 (FI/Finland/hostname.domain.nl) said, [/icode]
like it is shown now.
 
it shouldn't have any issued with original script, could you show us your currently script that you write?

also you can debug script by
Code:
yourscript.pl "1.2.3.4" "test_port" "nouse" "test_inout" "nouse" "Cluster member 1.2.3.4 (XX/Xxxxxx/hostname.domain.nl) said," "test_log" "test_trigger"
So if you test like this, you could see debug error output from script.
 
OK, a very short test

Perl:
#!/usr/bin/perl

my $message = 'lfd - Cluster member XXX.XXX.XXX.XXX (CA/Canada/web0.myserver.com) said, TEMPDENY 203.0.113.1, Reason:[Not provided - 203.0.113.1 (-)]';
my $comment = $message . "; Ports: " . $ports . "; Direction: " . $inout . "; Trigger: " . $trigger;
$comment =~ s/Cluster member.*said,/***/g;
print $comment;

Gives the following output:

Bash:
$ ./perl.test
lfd - *** TEMPDENY 203.0.113.1, Reason:[Not provided - 203.0.113.1 (-)]; Ports: ; Direction: ; Trigger:

so the unwanted text is removed by the script fine.

Your script:

Perl:
#!/usr/bin/perl
# This file was written as an executable to be used in the auto report function
# of csf and lfd. By replacing $YOUR_API_KEY below with your abuseipdb api key,
# allows you to use this code to integrate your csf system with abuseipdb.com
use strict;
use warnings;
use HTTP::Tiny;
use JSON;

# Gather the information from the commandline passed by lfd
my $ports = $ARGV[1];
my $inout = $ARGV[3];
my $message = $ARGV[5];
my $logs = $ARGV[6];
my $trigger = $ARGV[7];
my $comment = $message . "; Ports: " . $ports . "; Direction: " . $inout . "; Trigger: " . $trigger . "; Logs: " . $logs;
my $ua = HTTP::Tiny->new;

$comment =~ s/Cluster member.*said,/***/g;

my $url = 'https://api.abuseipdb.com/api/v2/report';

my $data = {
    ip => $ARGV[0],
    comment => $comment,
    categories => 14
};

my %options = (
   "headers", {
       "Key" => "YOUR_API_KEY",
       "Accept" => "application/json"
   },
);

my $response = $ua->post_form($url, $data, \%options);
my $json = JSON->new;
my $output = $json->pretty->encode($json->decode($response->{'content'}));

if ($response->{'status'} == 200){
    print "Report Succesful!\n" . $output;
} elsif ($response->{'status'} == 429) {
    print $output;
} elsif ($response->{'status'} == 422) {
    print $output;
} elsif ($response->{'status'} == 401) {
    print $output;
}

seems to work fine too, even though it gives:

JSON:
{
   "errors" : [
      {
         "detail" : "Authentication failed. Your API key is either missing, incorrect, or revoked. Note: The APIv2 key differs from the APIv1 key.",
         "status" : 401
      }
   ]
}
 
could you show us your currently script that you write?
I just posted the script that I use, because I use the original script.

Except I changed this (also @zEitEr):
Code:
my $comment = $message . "; Ports: " . $ports . "; Direction: " . $inout
    . "; Trigger: " . $trigger . "; Logs: " . $logs;
to this:
Code:
my $comment = $message . "; Ports: " . $ports . "; Direction: " . $inout . "; Trigger: " . $trigger;
$comment =~ s/Cluster member.*said,/***/g;
so I removed the logs and added what you said, and ofcourse my key, nothing more.

So if you test like this, you could see debug error output from script.
Where?
I checked at abuseipdb and this is what it was showing at the reports section.

Code:
***; Ports: test_port; Direction: test_inout; Trigger: test_trigger
so that seems to work. However I thought it would state "Cluster member *** said ***, but maybe I'm mistaken, but at least it works via commandine.

On console I've seen this output:
Code:
./abuseipdb_report.pl  "1.2.3.4" "test_port" "nouse" "test_inout" "nouse" "Cluster member 1.2.3.4 (XX/Xxxxxx/hostname.domain.nl) said," "test_log" "test_trigger"
Report Succesful!
{
   "data" : {
      "ipAddress" : "1.2.3.4",
      "abuseConfidenceScore" : XX
   }
}

I masked the confidence score.

So from commandline it seems to work and report to abuseipdb. Strange. Because I had some ip's this morning and they were not reported, maybe CSF is doing something with the script which makes it not function?
Strange.
 
So from commandline it seems to work and report to abuseipdb. Strange. Because I had some ip's this morning and they were not reported, maybe CSF is doing something with the script which makes it not function?

You might check /var/log/lfd.log Probably there are more clues on the issue.
 
Probably there are more clues on the issue.
Nothing unfortunately.

Last thing in there recently is this in the lfd.log file (I masked my server's ip and hostname):
Code:
Mar 27 17:31:38 server23 lfd[12884]: Cluster member 17.xxxxx (DE/Germany/server.domain.com) said, TEMPDENY 35.178.80.104, Reason:[*Port Scan* detected from 35.178.80.104 (GB/United Kingdom/ec2-35-178-80-104.eu-west-2.compute.amazonaws.com). 11 hits in the last 155 seconds] - *Blocked in csf* for 43200 secs [LF_CLUSTER]

And no report in abuseipdb of it.
As soon as I remove that custom line, the report will be made, but then it will contain the full ip and hostname of the cluster member.

So it must be CSF doing something odd with the script, causing the replace command not to work.
 
I just doublechecked in /etc/lfd.log file and it had 3 entry's about the same ip.
Cluster report of portscan by Chinese ip -> nothing
Port scan by current server -> working
Cluster tempdeny notice -> nothing.

So I checked other cluster reports and no cluster reports are made.
So the script is working, but it's seems to remove the cluster report totally instead of only skipping the text.
 
Ehmz... in fact is this error a good solution too.
I can have my servers report themselves and keep clustering on, and cluster reports will not be made at all.
So this way they both give their local reports and cluster reports are ignored by both. Should not be working like this, but in fact I can use it like that.
 
I just doublechecked in /etc/lfd.log file and it had 3 entry's about the same ip.


I'm sure you checked the correct file /var/log/lfd.log, and that's only a typo.


So I checked other cluster reports and no cluster reports are made.

You might try and test it with

Code:
csf -cd 127.0.0.2 "Any text is coming here"

to test the script and see your reports.

From https://docs.abuseipdb.com/#test-ip-addresses :

Reporting 127.0.0.2 will simulate a short term rate limit. This is useful for application testing.
 
You might try and test it with
It was indeed a typo, was /var/log/lfd.log indeed.

I did the test:
Code:
csf -cd 127.0.0.2 "Any text is coming here"
Sent request to 95.xx.xx.xx, replied: [Received]

And from /var/log/lfd.log from the receiving server:
Mar 27 18:30:05 serverXX lfd[23910]: *Error*: csf output: deny failed: [127.0.0.2] is one of this servers addresses!

Wasn't 127.0.0.2 used for RBL stuff? So testing with that won't work.

Same error when trying with 127.0.0.3.

I do have others in there like this one from a couple of minutes ago on the other server (same script):
Code:
Mar 27 18:30:08 serverXX lfd[26286]: Cluster member 95.XX.XX.XX (FI/Finland/serverXX.domain.com) said, TEMPDENY 119.203.143.84, Reason:[119.203.143.84 (KR/South Korea/-), 5 distributed smtpauth attacks on account [sales] in the last 900 secs] - *Blocked in csf* for 43200 secs [LF_CLUSTER]

I masked my ip and hostname myself.

So server A reported to cluster server B, but now the ip 119.203.143.84 is not reported at all at Abuseipdb, by either one of them. Very odd.
 
Back
Top