5 ms·

Finally iptables works the same on every Linux distro

38 points by telmich 13y ago

covertgeek 13y ago
Haven't tried it for myself -- but looking at the code, it appears that the last rule needs to be changed to port 22 for SSH to work.
- ck2 13y ago
  SSH should be immediately moved off port 22 in virtually any install. The amount of toxic traffic hitting that port is scary.
  - gmuslera 13y ago
    If you think someone could get in thru the ssh port (exploiting an undisclosed vulnerability or with brute force password cracking) moving it elsewhere is not a long term solution. fail2ban is good to avoid brute force attacks, but portknocking with i.e. fwknop will be safer in more situations. If a service is not meant for the public then they shouldn't be able to even notice that is there.
    - MertsA 13y ago
      fail2ban and other programs that just grep a log file are a horrible idea as most of them can't properly parse a log entry and it's possible to inject an arbitrary ip address into the log file one way or another. I'm not sure if there are any outstanding exploits for the latest version of fail2ban right now but the whole concept of searching through log files that are in a format that can change at any time, aren't delimited properly, and subject to the sysadmin customizing is a precarious one at best. Even if fail2ban and others were perfect, all it would take is the sysadmin customizing the log format to include some random field and all the sudden it's possible for an attacker to block every IP address with one request. Source: http://seclists.org/fulldisclosure/2007/Jun/138 http://seclists.org/fulldisclosure/2007/Jun/138 A better alternative is something like pam_abl which only protects logins to a user on the system but with it ssh is essentially unbruteforceable.
      - yrro 13y ago
        Does pam_abl work when you're not using PAM for authentication--only for authorization ("account") and session management? e.g., when UsePAM is enabled, but ChallengeResponseAuthentication and PasswordAuthentication are disabled. I believe this is the problem with using pam_tally2. Then again, if you're only allowing PubkeyAuthentication then maybe you don't care about brute force login attempts so much.
  - thirsteh 13y ago
    If you're worried about that, it probably shouldn't be publicly accessible in the first place. Yes, moving ports helps, but it's not a real defense. It just lowers bandwidth costs and prevents some not-so-harmful attacks (from people who don't know whether what they've compromised has any value.) At the very least, use public-key authentication instead of password authentication for SSH.
    - erichurkman 13y ago
      One nice side bonus to moving to non-standard SSH ports? Your log files are a lot less noisy.
      - ck2 13y ago
        You then also can easily detect bad behavior by watching failed connect attempts to port 22.
  - pepve 13y ago
    It's indeed a large amount of traffic. But it's not scary. None of it will get through if your SSH software is up to date, you have it configured properly, and user accounts are managed sanely. The attacks to be scared of are those that are actually targeted at you. And they will find the port SSH is running on either way.
    - Shish2k 13y ago
      > None of it will get through if your SSH software is up to date, you have it configured properly, and user accounts are managed sanely. So in the majority of cases, traffic will get through? :P
  - kamaln7 13y ago
    Or perhaps firewall your server properly so only people who are meant to connect to port 22 can connect to it?
    - brokenparser 13y ago
      Oh I know, we could use iptables!
  - herge 13y ago
    Every time somebody suggests this, you should not say it's for security purposes, but to reduce the load on a server.
    - qu4z-2 13y ago
      And to reduce load on the person checking the logs.
  - D9u 13y ago
    Not scary if you disable password logins, implement PKI, and limit logins to specific addresses. I get a kick out of viewing all the failed attempts in /var/log/auth Added bonus is adding all those bad guy addresses to my blacklists.
  - est 13y ago
    passive port knocking should be standard.
ambrop7 13y ago
For complex setups you sooner or later have to dynamically add/remove rules, based on values only known at runtime (such as an IP address obtained by DHCP). Then, a simple list of rules doesn't suffice, and some kind of programming is needed. To solve such problems elegantly I designed my "NCD programming language" (link: https://code.google.com/p/badvpn/wiki/NCD https://code.google.com/p/badvpn/wiki/NCD ). The language has built-in backtracking, so in the case of iptables, the language itself makes sure any iptables rule that was added is also removed when that is necessary, in a manner not unlike exception handling in C++ etc. Link to iptables module: https://code.google.com/p/badvpn/source/browse/trunk/ncd/modules/net_iptables.c https://code.google.com/p/badvpn/source/browse/trunk/ncd/mod...
- mmastrac 13y ago
  This looks pretty cool. Does it run the script(s) in kernel space or user space?
  - ambrop7 13y ago
    The interpreter is a userspace program. You can run if from a terminal if you wish and use it as a general purpose scripting language (though it's not quite that useful in that regard, yet). Oh, and it also runs in the browser ;) http://badvpn.googlecode.com/svn/wiki/emncd.html http://badvpn.googlecode.com/svn/wiki/emncd.html
matt__rose 13y ago
umm, iptables is a part of the kernel, and is exactly the same, regardless of distribution. I've used a bunch of different distros and iptables is always the same. What is this guy talking about??
- jvehent 13y ago
  He's talking about wrappers. Wrappers are dist specific. Some people like to use UFW and so on. It's their choice. But real men call iptables directly.
  - antocv 13y ago
    Agreed. The post title is wrong, it should read "Another iptables frontend, this one aims for all distribution." And yes, real men use iptables directly. I never understood the need for wrappers, just makes it harder to debug and see whats really going on.
dsr_ 13y ago
Note that this requires a commitment to using cdist. cdist may be great, but it's not much different from puppet or chef or bcfg2 or whatever your favorite configuration management system is. Since iptables comes from upstream (and is closely linked to the kernel), distros running the same version of the kernel already have the same iptables quirks. (There aren't many.) The article discusses distributing an iptables config file and having it run on startup, a task which can be equally well handled by the other config management systems.
hkarthik 13y ago
Sounds like one of the reasons I was instructed to use Firehol by my system admin. http://en.wikipedia.org/wiki/FireHOL http://en.wikipedia.org/wiki/FireHOL
- IbJacked 13y ago
  Nice to run into someone else using firehol! I've been using it for years but it doesn't seem to get much love.
jvehent 13y ago
<plug> If you use Chef, check out AFW. https://github.com/jvehent/AFW https://github.com/jvehent/AFW </plug>
miah_ 13y ago
This is interesting, but I'd rather prefer something like Ript (a Ruby DSL for Iptables) than a very specific implementation along with its assumptions. https://github.com/bulletproofnetworks/ript https://github.com/bulletproofnetworks/ript So long as you can write Ruby, this works in Chef, Puppet, or whatever.

38 points by telmich 13y ago

Haven't tried it for myself -- but looking at the code, it appears that the last rule needs to be changed to port 22 for SSH to work.

ck2 13y ago
SSH should be immediately moved off port 22 in virtually any install. The amount of toxic traffic hitting that port is scary.
- gmuslera 13y ago
  If you think someone could get in thru the ssh port (exploiting an undisclosed vulnerability or with brute force password cracking) moving it elsewhere is not a long term solution. fail2ban is good to avoid brute force attacks, but portknocking with i.e. fwknop will be safer in more situations. If a service is not meant for the public then they shouldn't be able to even notice that is there.
  - MertsA 13y ago
    fail2ban and other programs that just grep a log file are a horrible idea as most of them can't properly parse a log entry and it's possible to inject an arbitrary ip address into the log file one way or another. I'm not sure if there are any outstanding exploits for the latest version of fail2ban right now but the whole concept of searching through log files that are in a format that can change at any time, aren't delimited properly, and subject to the sysadmin customizing is a precarious one at best. Even if fail2ban and others were perfect, all it would take is the sysadmin customizing the log format to include some random field and all the sudden it's possible for an attacker to block every IP address with one request. Source: http://seclists.org/fulldisclosure/2007/Jun/138 http://seclists.org/fulldisclosure/2007/Jun/138 A better alternative is something like pam_abl which only protects logins to a user on the system but with it ssh is essentially unbruteforceable.
    - yrro 13y ago
      Does pam_abl work when you're not using PAM for authentication--only for authorization ("account") and session management? e.g., when UsePAM is enabled, but ChallengeResponseAuthentication and PasswordAuthentication are disabled. I believe this is the problem with using pam_tally2. Then again, if you're only allowing PubkeyAuthentication then maybe you don't care about brute force login attempts so much.
- thirsteh 13y ago
  If you're worried about that, it probably shouldn't be publicly accessible in the first place. Yes, moving ports helps, but it's not a real defense. It just lowers bandwidth costs and prevents some not-so-harmful attacks (from people who don't know whether what they've compromised has any value.) At the very least, use public-key authentication instead of password authentication for SSH.
  - erichurkman 13y ago
    One nice side bonus to moving to non-standard SSH ports? Your log files are a lot less noisy.
    - ck2 13y ago
      You then also can easily detect bad behavior by watching failed connect attempts to port 22.
- pepve 13y ago
  It's indeed a large amount of traffic. But it's not scary. None of it will get through if your SSH software is up to date, you have it configured properly, and user accounts are managed sanely. The attacks to be scared of are those that are actually targeted at you. And they will find the port SSH is running on either way.
  - Shish2k 13y ago
    > None of it will get through if your SSH software is up to date, you have it configured properly, and user accounts are managed sanely. So in the majority of cases, traffic will get through? :P
- kamaln7 13y ago
  Or perhaps firewall your server properly so only people who are meant to connect to port 22 can connect to it?
  - brokenparser 13y ago
    Oh I know, we could use iptables!
- herge 13y ago
  Every time somebody suggests this, you should not say it's for security purposes, but to reduce the load on a server.
  - qu4z-2 13y ago
    And to reduce load on the person checking the logs.
- D9u 13y ago
  Not scary if you disable password logins, implement PKI, and limit logins to specific addresses. I get a kick out of viewing all the failed attempts in /var/log/auth Added bonus is adding all those bad guy addresses to my blacklists.
- est 13y ago
  passive port knocking should be standard.

ambrop7 13y ago

For complex setups you sooner or later have to dynamically add/remove rules, based on values only known at runtime (such as an IP address obtained by DHCP). Then, a simple list of rules doesn't suffice, and some kind of programming is needed. To solve such problems elegantly I designed my "NCD programming language" (link: https://code.google.com/p/badvpn/wiki/NCD https://code.google.com/p/badvpn/wiki/NCD ). The language has built-in backtracking, so in the case of iptables, the language itself makes sure any iptables rule that was added is also removed when that is necessary, in a manner not unlike exception handling in C++ etc. Link to iptables module: https://code.google.com/p/badvpn/source/browse/trunk/ncd/modules/net_iptables.c https://code.google.com/p/badvpn/source/browse/trunk/ncd/mod...

mmastrac 13y ago
This looks pretty cool. Does it run the script(s) in kernel space or user space?
- ambrop7 13y ago
  The interpreter is a userspace program. You can run if from a terminal if you wish and use it as a general purpose scripting language (though it's not quite that useful in that regard, yet). Oh, and it also runs in the browser ;) http://badvpn.googlecode.com/svn/wiki/emncd.html http://badvpn.googlecode.com/svn/wiki/emncd.html

matt__rose 13y ago

umm, iptables is a part of the kernel, and is exactly the same, regardless of distribution. I've used a bunch of different distros and iptables is always the same. What is this guy talking about??

jvehent 13y ago
He's talking about wrappers. Wrappers are dist specific. Some people like to use UFW and so on. It's their choice. But real men call iptables directly.
- antocv 13y ago
  Agreed. The post title is wrong, it should read "Another iptables frontend, this one aims for all distribution." And yes, real men use iptables directly. I never understood the need for wrappers, just makes it harder to debug and see whats really going on.

dsr_ 13y ago

Note that this requires a commitment to using cdist. cdist may be great, but it's not much different from puppet or chef or bcfg2 or whatever your favorite configuration management system is. Since iptables comes from upstream (and is closely linked to the kernel), distros running the same version of the kernel already have the same iptables quirks. (There aren't many.) The article discusses distributing an iptables config file and having it run on startup, a task which can be equally well handled by the other config management systems.

hkarthik 13y ago

Sounds like one of the reasons I was instructed to use Firehol by my system admin. http://en.wikipedia.org/wiki/FireHOL http://en.wikipedia.org/wiki/FireHOL

IbJacked 13y ago
Nice to run into someone else using firehol! I've been using it for years but it doesn't seem to get much love.

jvehent 13y ago

<plug> If you use Chef, check out AFW. https://github.com/jvehent/AFW https://github.com/jvehent/AFW </plug>

miah_ 13y ago

This is interesting, but I'd rather prefer something like Ript (a Ruby DSL for Iptables) than a very specific implementation along with its assumptions. https://github.com/bulletproofnetworks/ript https://github.com/bulletproofnetworks/ript So long as you can write Ruby, this works in Chef, Puppet, or whatever.