4 ms·

iptables can limit the number of connections per ip in a "cheap" (fast/early) way. In fact is my #1 use of iptables since blocking ports where there are no serv

by fduran 13y ago

iptables can limit the number of connections per ip in a "cheap" (fast/early) way. In fact is my #1 use of iptables since blocking ports where there are no services doesn't do much.

pyre 13y ago
| blocking ports where there are no services doesn't | do much True, but it can be a useful 'just in-case' against things listening on ports that you were unaware of. It's obviously bad for you not to know about services that are listening on your box, but you could view it as a safety net.
- fduran 13y ago
  Agree, I also block all unused incoming ports as a safety net as you say.
  - oinksoft 13y ago
    Probably easier to just use a whitelist policy, no?
    - fduran 13y ago
      Of course; implementation of the idea is whitelist: allow used ports default policy deny all
SeoxyS 13y ago
A much more common use of iptables for me is to limit outside traffic to port 21, 80, and 447, while letting whitelisted internal hosts use every other ports, for other services used internally. We can then run those services without authentication, and have much less exposure in case of an attack (the only thing whose security we must trust is iptables, ssh, our HTTP web server.)
- count 13y ago
  Why would you run them without authentication? One mistake in your iptables shouldn't instantly compromise your operation... Best practice is 'defense in depth', not 'we'll just lock down the perimeter'.
ktheory 13y ago
Yeah, iptables works great for that. I also like nginx's limit_zone module. You can put limit_zone in the proxy stanza, and only throttle dynamic requests without throttling access to fast static files. We often use Rack::Attack to throttle particular HTTP paths differently. Say, the homepage isn't throttled, but the login action is. That layer 7 knowledge is Rack::Attack's main advantage. As I say in the README, Rack::Attack is complementary to iptables and the limit_zone module.

by fduran 13y ago

iptables can limit the number of connections per ip in a "cheap" (fast/early) way. In fact is my #1 use of iptables since blocking ports where there are no services doesn't do much.

pyre 13y ago

| blocking ports where there are no services doesn't | do much True, but it can be a useful 'just in-case' against things listening on ports that you were unaware of. It's obviously bad for you not to know about services that are listening on your box, but you could view it as a safety net.

fduran 13y ago
Agree, I also block all unused incoming ports as a safety net as you say.
- oinksoft 13y ago
  Probably easier to just use a whitelist policy, no?
  - fduran 13y ago
    Of course; implementation of the idea is whitelist: allow used ports default policy deny all

SeoxyS 13y ago

A much more common use of iptables for me is to limit outside traffic to port 21, 80, and 447, while letting whitelisted internal hosts use every other ports, for other services used internally. We can then run those services without authentication, and have much less exposure in case of an attack (the only thing whose security we must trust is iptables, ssh, our HTTP web server.)

count 13y ago
Why would you run them without authentication? One mistake in your iptables shouldn't instantly compromise your operation... Best practice is 'defense in depth', not 'we'll just lock down the perimeter'.

ktheory 13y ago

Yeah, iptables works great for that. I also like nginx's limit_zone module. You can put limit_zone in the proxy stanza, and only throttle dynamic requests without throttling access to fast static files. We often use Rack::Attack to throttle particular HTTP paths differently. Say, the homepage isn't throttled, but the login action is. That layer 7 knowledge is Rack::Attack's main advantage. As I say in the README, Rack::Attack is complementary to iptables and the limit_zone module.