Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum. |
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.
|
 |
|
04-03-2009, 03:20 PM
|
#16
|
LQ Guru
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870
|
Quote:
Originally Posted by anomie
If you are only blacklisting for certain services, and can add extra criteria to the -j CHECK_IP rule, all the better. For example, if you are only blacklisting those addresses to tcp port 22 (ssh), then add the appropriate criteria to the rule
|
Excellent point, anomie. Thanks for posting that.
Last edited by win32sux; 04-03-2009 at 03:28 PM.
|
|
|
04-14-2009, 09:41 PM
|
#17
|
Member
Registered: Apr 2009
Posts: 80
Original Poster
Rep:
|
I need to block all traffic from these and all is working well. I also run a transparent proxy. Is there a way to route port 80 request for these back to my webserver? This way it will give a 404 instead of taking the time to time-out.
|
|
|
04-14-2009, 11:04 PM
|
#18
|
LQ Guru
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870
|
Quote:
Originally Posted by fruitwerks
I need to block all traffic from these and all is working well. I also run a transparent proxy. Is there a way to route port 80 request for these back to my webserver? This way it will give a 404 instead of taking the time to time-out.
|
Yes, you can DNAT the packets. It's much quicker to just switch from DROP to REJECT, though. Plus it's an application-neutral method, unlike an HTTP status code.
Last edited by win32sux; 04-14-2009 at 11:05 PM.
|
|
|
04-15-2009, 12:43 PM
|
#19
|
Member
Registered: Apr 2009
Posts: 80
Original Poster
Rep:
|
ok, so you are suggesting to change all my drop statements to rejects? I think I had chosen drop for a specific reason... but I can't recall why it was so important. Using reject would cause a return ('fail') instead of a timeout?
Fun Stuff!
|
|
|
04-15-2009, 05:20 PM
|
#20
|
LQ Guru
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870
|
Quote:
Originally Posted by fruitwerks
ok, so you are suggesting to change all my drop statements to rejects?
|
Only because you mentioned you didn't want these clients to need to wait for a timeout.
Quote:
I think I had chosen drop for a specific reason... but I can't recall why it was so important. Using reject would cause a return ('fail') instead of a timeout?
|
Usually people go with DROP instead of REJECT when they want to be stealthy.
From man iptables:
Code:
REJECT
This is used to send back an error packet in response to the matched
packet: otherwise it is equivalent to DROP so it is a terminating TAR‐
GET, ending rule traversal. This target is only valid in the INPUT,
FORWARD and OUTPUT chains, and user-defined chains which are only
called from those chains. The following option controls the nature of
the error packet returned:
--reject-with type
The type given can be
icmp-net-unreachable
icmp-host-unreachable
icmp-port-unreachable
icmp-proto-unreachable
icmp-net-prohibited
icmp-host-prohibited or
icmp-admin-prohibited (*)
which return the appropriate ICMP error message (port-unreach‐
able is the default). The option tcp-reset can be used on rules
which only match the TCP protocol: this causes a TCP RST packet
to be sent back. This is mainly useful for blocking ident
(113/tcp) probes which frequently occur when sending mail to
broken mail hosts (which won’t accept your mail otherwise).
(*) Using icmp-admin-prohibited with kernels that do not support it
will result in a plain DROP instead of REJECT
Last edited by win32sux; 04-15-2009 at 05:24 PM.
|
|
|
All times are GMT -5. The time now is 01:05 PM.
|
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
|
|