FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Red Hat Install

 
 
LinkBack Thread Tools
 
Old 10-21-2008, 12:54 AM
Karl Pearson
 
Default IPTables limits?

I'm curious if there's a limit on how many iptables entries it takes to
hammer a system. Okay, a better question: When am I running the risk of
messing up my IP traffic if I add DROP entries in the INPUT rule of
iptables?


The machine in question acts as a small gateway for one subnet behind a
Smoothwall 3.0 gateway that is the gateway for it and the rest of the
network.


The machine is a single core AMD 64 3200+ with 2GB of ram running 32-bit
Fedora 8.


---
_/ _/ _/ _/_/_/ ____________ __o
_/ _/ _/ _/ _/ ____________ _-<._
_/_/ _/ _/_/_/ (_)/ (_)
_/ _/ _/ _/ ......................
_/ _/ arl _/_/_/ _/ earson KarlP@ourldsfamily.com
---
http://consulting.ourldsfamily.com
---

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 10-21-2008, 05:16 PM
Rick Stevens
 
Default IPTables limits?

Karl Pearson wrote:
I'm curious if there's a limit on how many iptables entries it takes to
hammer a system. Okay, a better question: When am I running the risk of
messing up my IP traffic if I add DROP entries in the INPUT rule of
iptables?


You do ask the damndest questions, Karl! :-)

I've never seen a document that describes any rule limits. It is a
kernel module, so one must assume there is some limit. It may be that
a spelunking sesion through the source might answer that.

I've got lots of drop entries on my rules and haven't had any issues,
but I'm always guided by the concept that the more rules a packet must
traverse, the slower the connection will be at startup. Therefore I
order my rules carefully putting the more generic rules at the top of
the list and the more specific ones at the bottom. That may not work
for you...every network is a little different (for example, we blacklist
entire /8 networks in some cases because of DOS or hack attacks from
those countries).

The machine in question acts as a small gateway for one subnet behind a
Smoothwall 3.0 gateway that is the gateway for it and the rest of the
network.


The machine is a single core AMD 64 3200+ with 2GB of ram running 32-bit
Fedora 8.


Should have plenty of headroom to do what you want with that.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- The gene pool could use a little chlorine. -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 10-21-2008, 05:34 PM
"Karl Pearson"
 
Default IPTables limits?

On Tue, October 21, 2008 11:16 am, Rick Stevens wrote:
> Karl Pearson wrote:
>> I'm curious if there's a limit on how many iptables entries it takes
>> to
>> hammer a system. Okay, a better question: When am I running the risk
>> of
>> messing up my IP traffic if I add DROP entries in the INPUT rule of
>> iptables?
>
> You do ask the damndest questions, Karl! :-)
>
> I've never seen a document that describes any rule limits. It is a
> kernel module, so one must assume there is some limit. It may be that
> a spelunking sesion through the source might answer that.
>
> I've got lots of drop entries on my rules and haven't had any issues,
> but I'm always guided by the concept that the more rules a packet must
> traverse, the slower the connection will be at startup. Therefore I
> order my rules carefully putting the more generic rules at the top of
> the list and the more specific ones at the bottom. That may not work
> for you...every network is a little different (for example, we blacklist
> entire /8 networks in some cases because of DOS or hack attacks from
> those countries).

I'd love a list of those IPs and how you inserted the rule. I also
wonder about DROP vs REJECT. I know the difference, but what's the
theory behind using one over the other? I have thought it is about them
knowing the IP is there vs just a hang. But, I'm wondering if the DROP
(hang) causes me any headaches in IP traffic limiting? I know, another
annoying question.

All my DROPs are in the first rule, so they are immediately acted on, or
in this case, DROPped.

I used to use sshblack, but the way the logfiles are written now make it
ineffective for inbound, however I wrote my own blacklist scripts which
I use with it, so it does do aging checks, which for DDNS is okay, I
think.

I have installed fail2ban, which blacklists for a shorter amount of
time, I suspect under the theory that ssh attacks are almost random, and
will pass.

>
>> The machine in question acts as a small gateway for one subnet behind
>> a
>> Smoothwall 3.0 gateway that is the gateway for it and the rest of the
>> network.
>>
>> The machine is a single core AMD 64 3200+ with 2GB of ram running
>> 32-bit
>> Fedora 8.

I suspected it might be okay, but since my desktop is a quad-core with
2GB of ram and 32-bit (Linux Mint on it) I wondered if it would have
enough horse power to keep the iptables rules happy.

Karl

>
> Should have plenty of headroom to do what you want with that.
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer ricks@nerd.com -
> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
> - -
> - The gene pool could use a little chlorine. -
> ----------------------------------------------------------------------
>
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list@redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-install-list
> To Unsubscribe Go To ABOVE URL or send a message to:
> redhat-install-list-request@redhat.com
> Subject: unsubscribe
>


---
_/ _/ _/ _/_/_/ ____________ __o
_/ _/ _/ _/ _/ ____________ _-<._
_/_/ _/ _/_/_/ (_)/ (_)
_/ _/ _/ _/ ......................
_/ _/ arl _/_/_/ _/ earson KarlP@ourldsfamily.com
---
http://consulting.ourldsfamily.com
---
"To mess up your Linux PC, you have to really work at it;
to mess up a microsoft PC you just have to work on it."
---


_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 10-21-2008, 06:12 PM
Rick Stevens
 
Default IPTables limits?

Karl Pearson wrote:

On Tue, October 21, 2008 11:16 am, Rick Stevens wrote:

Karl Pearson wrote:

I'm curious if there's a limit on how many iptables entries it takes
to
hammer a system. Okay, a better question: When am I running the risk
of
messing up my IP traffic if I add DROP entries in the INPUT rule of
iptables?

You do ask the damndest questions, Karl! :-)

I've never seen a document that describes any rule limits. It is a
kernel module, so one must assume there is some limit. It may be that
a spelunking sesion through the source might answer that.

I've got lots of drop entries on my rules and haven't had any issues,
but I'm always guided by the concept that the more rules a packet must
traverse, the slower the connection will be at startup. Therefore I
order my rules carefully putting the more generic rules at the top of
the list and the more specific ones at the bottom. That may not work
for you...every network is a little different (for example, we blacklist
entire /8 networks in some cases because of DOS or hack attacks from
those countries).


I'd love a list of those IPs and how you inserted the rule.


Oh, man, I'd have to go through our firewall configs to dig up the
addresses involved. As far as the rule insertion, it's pretty much
a standard iptables insert, but we add a "--syn" for TCP and just
simply block UDP. These are interim...eventually we migrate these
rules out to our Foundry or Cisco routers and remove them from the
individual servers.


I also
wonder about DROP vs REJECT. I know the difference, but what's the
theory behind using one over the other? I have thought it is about them
knowing the IP is there vs just a hang. But, I'm wondering if the DROP
(hang) causes me any headaches in IP traffic limiting? I know, another
annoying question.


We use DROP. If we're under attack or someone's probing, why let them
know they found a machine? If anything, a DROP is easier on the system
than a REJECT since all the system does is drop the connection...it
doesn't send anything back. And if the prober/attacker's connection
hangs at his end, good! Screw them in the first place. Attackers
and probers deserve absolutely no consideration in any way and should
be prosecuted in the same manner as someone trying to break into my home
or office.


All my DROPs are in the first rule, so they are immediately acted on, or
in this case, DROPped.

I used to use sshblack, but the way the logfiles are written now make it
ineffective for inbound, however I wrote my own blacklist scripts which
I use with it, so it does do aging checks, which for DDNS is okay, I
think.


For SSH issues, I have a standard ruleset. Here it is from the
/etc/sysconfig/iptables file:

# This rejects ssh attempts more than twice in 180 seconds...
# First, mark attempts as part of the "sshattack" group...
-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
# Optional: Include this line if you want to log these attacks...
#-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck
--seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: "
# Finally, reject the connection if more than one attempt is made in 180
seconds...
-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck
--seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset


So, you only get to try to SSH once every 3 minutes. You can tweak the
"--hitcount" value and "--seconds" value to customize it for your use.
It foils most of the script kiddies out there.


I have installed fail2ban, which blacklists for a shorter amount of
time, I suspect under the theory that ssh attacks are almost random, and
will pass.


Yeah, it works. Mine has minimal impact on the rulesets, but either
is fine.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- Death is nature's way of dropping carrier -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 10-21-2008, 06:55 PM
"Karl Pearson"
 
Default IPTables limits?

On Tue, October 21, 2008 12:12 pm, Rick Stevens wrote:
> Karl Pearson wrote:
>> On Tue, October 21, 2008 11:16 am, Rick Stevens wrote:
>>> Karl Pearson wrote:
>>>> I'm curious if there's a limit on how many iptables entries it takes
>>>> to
>>>> hammer a system. Okay, a better question: When am I running the risk
>>>> of
>>>> messing up my IP traffic if I add DROP entries in the INPUT rule of
>>>> iptables?
>>> You do ask the damndest questions, Karl! :-)
>>>
>>> I've never seen a document that describes any rule limits. It is a
>>> kernel module, so one must assume there is some limit. It may be
>>> that
>>> a spelunking sesion through the source might answer that.
>>>
>>> I've got lots of drop entries on my rules and haven't had any issues,
>>> but I'm always guided by the concept that the more rules a packet
>>> must
>>> traverse, the slower the connection will be at startup. Therefore I
>>> order my rules carefully putting the more generic rules at the top of
>>> the list and the more specific ones at the bottom. That may not work
>>> for you...every network is a little different (for example, we
>>> blacklist
>>> entire /8 networks in some cases because of DOS or hack attacks from
>>> those countries).
>>
>> I'd love a list of those IPs and how you inserted the rule.
>
> Oh, man, I'd have to go through our firewall configs to dig up the
> addresses involved. As far as the rule insertion, it's pretty much
> a standard iptables insert, but we add a "--syn" for TCP and just
> simply block UDP. These are interim...eventually we migrate these
> rules out to our Foundry or Cisco routers and remove them from the
> individual servers.
>
>> I also
>> wonder about DROP vs REJECT. I know the difference, but what's the
>> theory behind using one over the other? I have thought it is about
>> them
>> knowing the IP is there vs just a hang. But, I'm wondering if the DROP
>> (hang) causes me any headaches in IP traffic limiting? I know, another
>> annoying question.
>
> We use DROP. If we're under attack or someone's probing, why let them
> know they found a machine? If anything, a DROP is easier on the system
> than a REJECT since all the system does is drop the connection...it
> doesn't send anything back. And if the prober/attacker's connection
> hangs at his end, good! Screw them in the first place. Attackers
> and probers deserve absolutely no consideration in any way and should
> be prosecuted in the same manner as someone trying to break into my home
> or office.
>
>> All my DROPs are in the first rule, so they are immediately acted on,
>> or
>> in this case, DROPped.
>>
>> I used to use sshblack, but the way the logfiles are written now make
>> it
>> ineffective for inbound, however I wrote my own blacklist scripts
>> which
>> I use with it, so it does do aging checks, which for DDNS is okay, I
>> think.
>
> For SSH issues, I have a standard ruleset. Here it is from the
> /etc/sysconfig/iptables file:
>
> # This rejects ssh attempts more than twice in 180 seconds...
> # First, mark attempts as part of the "sshattack" group...
> -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
> # Optional: Include this line if you want to log these attacks...
> #-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck
> --seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: "
> # Finally, reject the connection if more than one attempt is made in 180
> seconds...
> -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck
> --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset

The iptables file doesn't exist, so is it checked only if it's there? I
have /etc/sysconfig/iptables-config which doesn't look like I ought to
mess with.

I like your rule better than using sshblack or fail2ban. it's simple and
doesn't require a daemon to be running all the time, other than the
already running iptables.

Thanks...

>
> So, you only get to try to SSH once every 3 minutes. You can tweak the
> "--hitcount" value and "--seconds" value to customize it for your use.
> It foils most of the script kiddies out there.
>
>> I have installed fail2ban, which blacklists for a shorter amount of
>> time, I suspect under the theory that ssh attacks are almost random,
>> and
>> will pass.
>
> Yeah, it works. Mine has minimal impact on the rulesets, but either
> is fine.
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer ricks@nerd.com -
> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
> - -
> - Death is nature's way of dropping carrier -
> ----------------------------------------------------------------------
>
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list@redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-install-list
> To Unsubscribe Go To ABOVE URL or send a message to:
> redhat-install-list-request@redhat.com
> Subject: unsubscribe
>


---
_/ _/ _/ _/_/_/ ____________ __o
_/ _/ _/ _/ _/ ____________ _-<._
_/_/ _/ _/_/_/ (_)/ (_)
_/ _/ _/ _/ ......................
_/ _/ arl _/_/_/ _/ earson KarlP@ourldsfamily.com
---
http://consulting.ourldsfamily.com
---
"To mess up your Linux PC, you have to really work at it;
to mess up a microsoft PC you just have to work on it."
---


_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 10-21-2008, 09:40 PM
Rick Stevens
 
Default IPTables limits?

Karl Pearson wrote:

On Tue, October 21, 2008 12:12 pm, Rick Stevens wrote:

Karl Pearson wrote:

On Tue, October 21, 2008 11:16 am, Rick Stevens wrote:

Karl Pearson wrote:

I'm curious if there's a limit on how many iptables entries it takes
to
hammer a system. Okay, a better question: When am I running the risk
of
messing up my IP traffic if I add DROP entries in the INPUT rule of
iptables?

You do ask the damndest questions, Karl! :-)

I've never seen a document that describes any rule limits. It is a
kernel module, so one must assume there is some limit. It may be
that
a spelunking sesion through the source might answer that.

I've got lots of drop entries on my rules and haven't had any issues,
but I'm always guided by the concept that the more rules a packet
must
traverse, the slower the connection will be at startup. Therefore I
order my rules carefully putting the more generic rules at the top of
the list and the more specific ones at the bottom. That may not work
for you...every network is a little different (for example, we
blacklist
entire /8 networks in some cases because of DOS or hack attacks from
those countries).

I'd love a list of those IPs and how you inserted the rule.

Oh, man, I'd have to go through our firewall configs to dig up the
addresses involved. As far as the rule insertion, it's pretty much
a standard iptables insert, but we add a "--syn" for TCP and just
simply block UDP. These are interim...eventually we migrate these
rules out to our Foundry or Cisco routers and remove them from the
individual servers.


I also
wonder about DROP vs REJECT. I know the difference, but what's the
theory behind using one over the other? I have thought it is about
them
knowing the IP is there vs just a hang. But, I'm wondering if the DROP
(hang) causes me any headaches in IP traffic limiting? I know, another
annoying question.

We use DROP. If we're under attack or someone's probing, why let them
know they found a machine? If anything, a DROP is easier on the system
than a REJECT since all the system does is drop the connection...it
doesn't send anything back. And if the prober/attacker's connection
hangs at his end, good! Screw them in the first place. Attackers
and probers deserve absolutely no consideration in any way and should
be prosecuted in the same manner as someone trying to break into my home
or office.


All my DROPs are in the first rule, so they are immediately acted on,
or
in this case, DROPped.

I used to use sshblack, but the way the logfiles are written now make
it
ineffective for inbound, however I wrote my own blacklist scripts
which
I use with it, so it does do aging checks, which for DDNS is okay, I
think.

For SSH issues, I have a standard ruleset. Here it is from the
/etc/sysconfig/iptables file:

# This rejects ssh attempts more than twice in 180 seconds...
# First, mark attempts as part of the "sshattack" group...
-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
# Optional: Include this line if you want to log these attacks...
#-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck
--seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: "
# Finally, reject the connection if more than one attempt is made in 180
seconds...
-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck
--seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset


The iptables file doesn't exist, so is it checked only if it's there? I
have /etc/sysconfig/iptables-config which doesn't look like I ought to
mess with.


/etc/sysconfig/iptables is the normal spot for rules to go in. The
/etc/sysconfig/iptables-config specifies what happens on startup and
shutdown. I did change the following parameters:

IPTABLES_SAVE_ON_STOP="yes"
IPTABLES_SAVE_ON_RESTART="yes"

The defaults are "no". Now, with those set up, I put my rules in
/etc/sysconfig/iptables and they're loaded with iptables starts up.

Consequently, if I do any iptables commands, the config changes I made
above will make the system save what is NOW in iptables into that file
so they'll be restored on the next boot or "service iptables restart"
command.

The format of the /etc/sysconfig/iptables file is different from the
normal command, as it's actually the input (or output) of the
iptables-save (or iptables-restore) command. Essentially, you introduce

a table (such as "nat" or "filter") with an "*" and the filter name.
For example,

*filter

introduces rules for the filter table. From this point in the file
until the next "*" or end of file, all rules affect the "filter" table.

To set the default policy for a chain, you use ":" followed by the
chain name, then the default policy. You can also use square brackets
to set the input and output counters ("[input-ctrutput-ctr]").
Example, to set a default policy of DROP for the INPUT chain in the
filter table and clear its input counter to 12 and its output to 0:

*filter
:INPUT DROP [12:0]

To add rules to it, use the normal iptables command syntax, but without
the actual iptables command and without the "-t tablename" stuff (since
you're in the section of the file for that table):

*filter
-A INPUT (insert regular rule here)
-A INPUT (insert regular rule here)

and so on. Blank lines and anything following a "#" are considered
comments.


I like your rule better than using sshblack or fail2ban. it's simple and
doesn't require a daemon to be running all the time, other than the
already running iptables.


It does have that charm as well. :-)

----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- When all else fails, try reading the instructions. -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 10-21-2008, 09:44 PM
Rick Stevens
 
Default IPTables limits?

I should have added that you can manually do your "iptables" commands
to get things the way you want, then as root you can:

iptables-save >/etc/sysconfig/iptables

to save what you have now. You can then edit the file and tweak
things as you wish, then either

iptables-restore </etc/sysconfig/iptables

or, if you've made the changes I mentioned in
/etc/sysconfig/iptables-config, use "service iptables restart" to read
them in from your modified file.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- Linux is like a wigwam...no windows, no gates...and apache inside! -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 10-22-2008, 07:41 AM
Andrew Kelly
 
Default IPTables limits?

On Tue, 2008-10-21 at 11:12 -0700, Rick Stevens wrote:
> Karl Pearson wrote:
> > On Tue, October 21, 2008 11:16 am, Rick Stevens wrote:
> >> Karl Pearson wrote:
> >>> I'm curious if there's a limit on how many iptables entries it takes
> >>> to
> >>> hammer a system. Okay, a better question: When am I running the risk
> >>> of
> >>> messing up my IP traffic if I add DROP entries in the INPUT rule of
> >>> iptables?
> >> You do ask the damndest questions, Karl! :-)
> >>
> >> I've never seen a document that describes any rule limits. It is a
> >> kernel module, so one must assume there is some limit. It may be that
> >> a spelunking sesion through the source might answer that.
> >>
> >> I've got lots of drop entries on my rules and haven't had any issues,
> >> but I'm always guided by the concept that the more rules a packet must
> >> traverse, the slower the connection will be at startup. Therefore I
> >> order my rules carefully putting the more generic rules at the top of
> >> the list and the more specific ones at the bottom. That may not work
> >> for you...every network is a little different (for example, we blacklist
> >> entire /8 networks in some cases because of DOS or hack attacks from
> >> those countries).
> >
> > I'd love a list of those IPs and how you inserted the rule.
>
> Oh, man, I'd have to go through our firewall configs to dig up the
> addresses involved. As far as the rule insertion, it's pretty much
> a standard iptables insert, but we add a "--syn" for TCP and just
> simply block UDP. These are interim...eventually we migrate these
> rules out to our Foundry or Cisco routers and remove them from the
> individual servers.
>
> > I also
> > wonder about DROP vs REJECT. I know the difference, but what's the
> > theory behind using one over the other? I have thought it is about them
> > knowing the IP is there vs just a hang. But, I'm wondering if the DROP
> > (hang) causes me any headaches in IP traffic limiting? I know, another
> > annoying question.
>
> We use DROP. If we're under attack or someone's probing, why let them
> know they found a machine? If anything, a DROP is easier on the system
> than a REJECT since all the system does is drop the connection...it
> doesn't send anything back. And if the prober/attacker's connection
> hangs at his end, good! Screw them in the first place. Attackers
> and probers deserve absolutely no consideration in any way and should
> be prosecuted in the same manner as someone trying to break into my home
> or office.
>
> > All my DROPs are in the first rule, so they are immediately acted on, or
> > in this case, DROPped.
> >
> > I used to use sshblack, but the way the logfiles are written now make it
> > ineffective for inbound, however I wrote my own blacklist scripts which
> > I use with it, so it does do aging checks, which for DDNS is okay, I
> > think.
>
> For SSH issues, I have a standard ruleset. Here it is from the
> /etc/sysconfig/iptables file:
>
> # This rejects ssh attempts more than twice in 180 seconds...
> # First, mark attempts as part of the "sshattack" group...
> -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
> # Optional: Include this line if you want to log these attacks...
> #-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck
> --seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: "
> # Finally, reject the connection if more than one attempt is made in 180
> seconds...
> -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck
> --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset
>
> So, you only get to try to SSH once every 3 minutes. You can tweak the
> "--hitcount" value and "--seconds" value to customize it for your use.
> It foils most of the script kiddies out there.

Unfortunately, it also foils legitimate accesses often enough. This is a
very effective set up, but it comes with the caveat that "connection
requests" are counted, and not "connection requests from IP address
such-and-such".
When I'm at work and need to access one of my boxes, no problem. I have
an accept rule for my LAN immediately in front of the gauntlet. But when
I'm at home and need to do something for whatever reason, I'm coming in
on a dynamic IP addy and almost always hit the wall because the scripts
have been there before me. It's not a show-stopper, but it gets annoying
having to first take a detour to a quieter box that is covered under the
ACCEPT rule.

Andy

> > I have installed fail2ban, which blacklists for a shorter amount of
> > time, I suspect under the theory that ssh attacks are almost random, and
> > will pass.
>
> Yeah, it works. Mine has minimal impact on the rulesets, but either
> is fine.
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer ricks@nerd.com -
> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
> - -
> - Death is nature's way of dropping carrier -
> ----------------------------------------------------------------------
>
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list@redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-install-list
> To Unsubscribe Go To ABOVE URL or send a message to:
> redhat-install-list-request@redhat.com
> Subject: unsubscribe

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 10-22-2008, 06:30 PM
Rick Stevens
 
Default IPTables limits?

Andrew Kelly wrote:

On Tue, 2008-10-21 at 11:12 -0700, Rick Stevens wrote:

Karl Pearson wrote:

On Tue, October 21, 2008 11:16 am, Rick Stevens wrote:

Karl Pearson wrote:

I'm curious if there's a limit on how many iptables entries it takes
to
hammer a system. Okay, a better question: When am I running the risk
of
messing up my IP traffic if I add DROP entries in the INPUT rule of
iptables?

You do ask the damndest questions, Karl! :-)

I've never seen a document that describes any rule limits. It is a
kernel module, so one must assume there is some limit. It may be that
a spelunking sesion through the source might answer that.

I've got lots of drop entries on my rules and haven't had any issues,
but I'm always guided by the concept that the more rules a packet must
traverse, the slower the connection will be at startup. Therefore I
order my rules carefully putting the more generic rules at the top of
the list and the more specific ones at the bottom. That may not work
for you...every network is a little different (for example, we blacklist
entire /8 networks in some cases because of DOS or hack attacks from
those countries).

I'd love a list of those IPs and how you inserted the rule.

Oh, man, I'd have to go through our firewall configs to dig up the
addresses involved. As far as the rule insertion, it's pretty much
a standard iptables insert, but we add a "--syn" for TCP and just
simply block UDP. These are interim...eventually we migrate these
rules out to our Foundry or Cisco routers and remove them from the
individual servers.


I also
wonder about DROP vs REJECT. I know the difference, but what's the
theory behind using one over the other? I have thought it is about them
knowing the IP is there vs just a hang. But, I'm wondering if the DROP
(hang) causes me any headaches in IP traffic limiting? I know, another
annoying question.

We use DROP. If we're under attack or someone's probing, why let them
know they found a machine? If anything, a DROP is easier on the system
than a REJECT since all the system does is drop the connection...it
doesn't send anything back. And if the prober/attacker's connection
hangs at his end, good! Screw them in the first place. Attackers
and probers deserve absolutely no consideration in any way and should
be prosecuted in the same manner as someone trying to break into my home
or office.


All my DROPs are in the first rule, so they are immediately acted on, or
in this case, DROPped.

I used to use sshblack, but the way the logfiles are written now make it
ineffective for inbound, however I wrote my own blacklist scripts which
I use with it, so it does do aging checks, which for DDNS is okay, I
think.

For SSH issues, I have a standard ruleset. Here it is from the
/etc/sysconfig/iptables file:

# This rejects ssh attempts more than twice in 180 seconds...
# First, mark attempts as part of the "sshattack" group...
-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
# Optional: Include this line if you want to log these attacks...
#-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck
--seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: "
# Finally, reject the connection if more than one attempt is made in 180
seconds...
-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck
--seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset


So, you only get to try to SSH once every 3 minutes. You can tweak the
"--hitcount" value and "--seconds" value to customize it for your use.
It foils most of the script kiddies out there.


Unfortunately, it also foils legitimate accesses often enough. This is a
very effective set up, but it comes with the caveat that "connection
requests" are counted, and not "connection requests from IP address
such-and-such".


No, it tracks the source IP. Two attempts from the same source IP
trigger the lockout.


When I'm at work and need to access one of my boxes, no problem. I have
an accept rule for my LAN immediately in front of the gauntlet. But when
I'm at home and need to do something for whatever reason, I'm coming in
on a dynamic IP addy and almost always hit the wall because the scripts
have been there before me. It's not a show-stopper, but it gets annoying
having to first take a detour to a quieter box that is covered under the
ACCEPT rule.


That works, but again, the ipt_recent module tracks source IPs.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- Memory is the second thing to go, but I can't remember the first! -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 10-23-2008, 11:52 AM
Andrew Kelly
 
Default IPTables limits?

On Wed, 2008-10-22 at 11:30 -0700, Rick Stevens wrote:
> Andrew Kelly wrote:
<snip>

> > Unfortunately, it also foils legitimate accesses often enough. This is a
> > very effective set up, but it comes with the caveat that "connection
> > requests" are counted, and not "connection requests from IP address
> > such-and-such".
>
> No, it tracks the source IP. Two attempts from the same source IP
> trigger the lockout.

Mea Culpa, Rick, you're absolutely right. I just discovered that my
rules weren't even using the recent mod. (Homer Simpson sound)

Thanks, man.

Andy

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 

Thread Tools




All times are GMT. The time now is 09:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org