I'm using a commando to check wich IPS are openning a large amount of connections to my server and kill them (to reduce synflood attack effects).
The command is the following one:
It works when I run ./tcpdrop.sh, but when I try to add it to crontab it gives me the following error:
I have tried already to add an alias tcpdrop=/usr/sbin/tcpdrop, but had no success.
I think a way to make it work is, instead of outputing "tcpdrop", it would output /usr/sbin/tcpdrop, but I don't know how to change the "sed" command to add the whole path of tcpdrop.
Another question I need to solve is how to ignore certain IP addresses, like 67.43.2.1. I tried to include the IP on the egrep -v '^(172\.16|192\.168|127\.0)' command, like egrep -v '^(172\.16|192\.168|127\.0|67.43.2.1)'but didn't work.
I think it's better to block the IP's with iptables (or the ufw front end to iptables) then just killing the connections. Presumably someone that's trying to attack your system would just reconnect, probably automatically since the attack is almost certainly scripted. So if you don't block them from connecting, you'll just see the same origins come right back in again.
I am using PF to block the connections. These are my configuration lines:
The problem is that the IPs in "blocked" table continue to open connections to my server, and it keeps the state as "SYN_SENT", flooding the server. That's why I need the tcpdrop script.
I don't know if I'm setting the firewall wrong, but seems like the only way to drop the open connections to my server.
Got it... But unless I'm missing something, once an IP is on your firewall's block list any packets received will be ignored. So the only "SYN_SENT" connections will be the ones setup before the firewall rule was added. Are those sticking around long enough to cause a problem? Since it's a fixed number can't you just leave them to timeout on their own?
Maybe there are PF rules (I'm not familiar with that package) that would implement the maximum connection per-IP logic you want. Meaning, can you add broad rule that won't allow any untrusted IP to have more than 70 connections at once?
Then you wouldn't need to kill the ones that do manage to get through before the firewall kicks in.
Also, does PF have a way to show the current list of blocked IP's? If so then you do need to kill processes that managed to get setup, you could run that PF command to generate a list of bad IP's, then use something like "lsof" to find all the open sockets connected to that IP then kill those processes. I think it might be simpler than figuring out which IP's to target by counting the number of connections each one has.
I'm new to utilities like socat and netcat and I'm not clear if they will do what I need.
I have a "compileDeployStartWebServer.sh" script and a "StartBrowser.sh" script that are started by emacs/elisp at the same time in two different processes.
I'm using Cygwin bash on Windows 10.
My... (3 Replies)
Hello all,
I am facing a weird issue while executing a code below -
#!/bin/bash
cd /wload/baot/home/baotasa0/sandboxes_finance/ext_ukba_bde/pset
sh UKBA_publish.sh UKBA 28082015 3
if
then
echo "Param file conversion for all the areas are completed, please check in your home directory"... (2 Replies)
I am trying to call a script(callingscript.sh) from a master script(masterscript.sh) to get string type value from calling script to master script. I have used scripts mentioned below.
#masterscript.sh
./callingscript.sh
echo $fileExist
#callingscript.sh
echo "The script is called"... (2 Replies)
I am using blow script :--
#!/bin/bash
FIND=$(ps -elf | grep "snmp_trap.sh" | grep -v grep) #check snmp_trap.sh is running or not
if
then
# echo "process found"
exit 0;
else
echo "process not found"
exec /home/Ketan_r /snmp_trap.sh 2>&1 & disown -h ... (1 Reply)
Hi guys
I have a shell script that executes sql statemets and sends the output to a file.the script takes in parameters executes sql and sends the result to an output file.
#!/bin/sh
echo " $2 $3 $4 $5 $6 $7
isql -w400 -U$2 -S$5 -P$3 << xxx
use $4
go
print"**Changes to the table... (0 Replies)