Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
02-15-2006, 04:03 PM
|
#1
|
Senior Member
Registered: Feb 2004
Location: lost+found
Distribution: CentOS
Posts: 1,430
Rep:
|
Is there a way to drop connections?
I blocked 69.93.138.106 with apf -d and netstat still shows he is connected 166 times.
166 69.93.138.106
I tried restarting apache and that didnt work.
How can I completely block his connections?
|
|
|
02-15-2006, 07:54 PM
|
#3
|
Member
Registered: Sep 2002
Posts: 310
Rep: 
|
# ethX is your network card (eg: eth0)
iptables -I INPUT -i ethX -p tcp -s 69.93.138.106 -j DROP
iptables -I OUTPUT -o ethX -p tcp -d 69.93.138.106 -j DROP
|
|
|
02-17-2006, 10:52 AM
|
#4
|
Senior Member
Registered: Feb 2004
Location: lost+found
Distribution: CentOS
Posts: 1,430
Original Poster
Rep:
|
Quote:
Originally Posted by kvedaa
|
Where can I get that?
root@server1 [~]# tcpkill host 66.152.98.72
-bash: tcpkill: command not found
root@server1 [~]# locate tcpkill
root@server1 [~]#
|
|
|
02-20-2006, 04:10 AM
|
#5
|
Senior Member
Registered: Sep 2005
Location: Out
Posts: 3,307
Rep:
|
Its part of dsniff package:
http://monkey.org/~dugsong/dsniff/
edit:
As dsniff needs a lot of dependencies, it may be easier to use hping3.
Using hping3 you should be able to nuke your offender (or better yourself if he is firewalled or if you don't want him to see you nuking) by sending an icmp error packet. This should cut the connection. You will need (his ip adress,his remote TCP port,your ip adress, your destination TCP port:80)
Last edited by nx5000; 02-20-2006 at 04:31 AM.
|
|
|
02-20-2006, 01:17 PM
|
#6
|
Member
Registered: Jun 2005
Posts: 542
Rep:
|
It may be done easily with an iptables script since it is faster and machines may (maliciously) ignore packets. Use REJECT instead of DROP so both machines see either TCP RST's (reset) or ICMP UNREACH as soon as they try to engage in communication so they'll drop states in the network stack.
|
|
|
02-21-2006, 02:01 AM
|
#7
|
Senior Member
Registered: Sep 2005
Location: Out
Posts: 3,307
Rep:
|
Quote:
Originally Posted by primo
It may be done easily with an iptables script since it is faster
|
Yes this is the cleanest,I gave others just for fun
Quote:
Originally Posted by primo
machines may (maliciously) ignore packets.
|
Its why I said : send the icmp to your own host. If you don't maliciously ignore these packets, the connection will effectively be torn, at least from your part.
|
|
|
02-21-2006, 02:25 AM
|
#8
|
Member
Registered: Jun 2005
Posts: 542
Rep:
|
Quote:
Originally Posted by nx5000
Its why I said : send the icmp to your own host. If you don't maliciously ignore these packets, the connection will effectively be torn, at least from your part.
|
Well, it is an option if you don't want to use your own available bandwidth answering every malicious request, but sending the attacker these reset packets (when it doesn't matter that he sees them) has the benefit of preventing his network stack from retrying old TCP connections. Maybe the best option would be temporarily using REJECT for 1 or 2 minutes, then using DROP.
|
|
|
03-13-2007, 09:59 AM
|
#9
|
LQ Newbie
Registered: Mar 2007
Posts: 2
Rep:
|
dsniff update
It looks like dsniff has been ported to newer libraries and had some other updates from Debian. Apparently they passed those back upstream, but it's unclear to me what, if anything is being done with them there.
|
|
|
All times are GMT -5. The time now is 07:46 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|