Re: [gentoo-user] Re: scripted iptables-restore
On 2013-10-17 10:30 PM, Walter Dnes waltd...@waltdnes.org wrote: I apologize. That is arguably a two factor system. When you said ssh key and password, I jumped to delusions, assuming that it was a standard ssh connection with the option of either key or password. Side question... So, wouldn't the simplest two-factor authentication be an SSH key that required a password?
Re: [gentoo-user] Re: scripted iptables-restore
On 18/10/2013 12:23, Tanstaafl wrote: On 2013-10-17 10:30 PM, Walter Dnes waltd...@waltdnes.org wrote: I apologize. That is arguably a two factor system. When you said ssh key and password, I jumped to delusions, assuming that it was a standard ssh connection with the option of either key or password. Side question... So, wouldn't the simplest two-factor authentication be an SSH key that required a password? No, there is no way to verify that a user has enabled a passphrase on an ssh key. Passphrases are designed to be used by the user to protect the user's private key and cannot be controlled by the listening sshd. The reason this is two factor is that hop 1 is a Unix host and like all good sysadmins I enable key auth only. The next hop is the Cisco routers and believe it or not, most of them are telnet only. Yes, you heard right: telnet. Recent Cisco firmware supports ssh but a) it kills the poor PowerPC cpu with 10 concurrent connections and b) costs a lot of license money. Ingenious measures are in place to mitigate the risk of telnet, it is certainly nothing like running telnetd over the open internet. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: scripted iptables-restore
On 2013-10-18 7:19 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 18/10/2013 12:23, Tanstaafl wrote: On 2013-10-17 10:30 PM, Walter Dnes waltd...@waltdnes.org wrote: I apologize. That is arguably a two factor system. When you said ssh key and password, I jumped to delusions, assuming that it was a standard ssh connection with the option of either key or password. Side question... So, wouldn't the simplest two-factor authentication be an SSH key that required a password? No, there is no way to verify that a user has enabled a passphrase on an ssh key. No... I mean... If I create an SSH key that requires a password (ie, not a 'blank' password), then when I use this ssh key to connect to the system it was created for, and it asks for the password... This is, as far as I can see, a poor man's 'two-factor' authentication, is it not?
Re: [gentoo-user] Re: scripted iptables-restore
On 18/10/2013 16:05, Tanstaafl wrote: On 2013-10-18 7:19 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 18/10/2013 12:23, Tanstaafl wrote: On 2013-10-17 10:30 PM, Walter Dnes waltd...@waltdnes.org wrote: I apologize. That is arguably a two factor system. When you said ssh key and password, I jumped to delusions, assuming that it was a standard ssh connection with the option of either key or password. Side question... So, wouldn't the simplest two-factor authentication be an SSH key that required a password? No, there is no way to verify that a user has enabled a passphrase on an ssh key. No... I mean... If I create an SSH key that requires a password (ie, not a 'blank' password), then when I use this ssh key to connect to the system it was created for, and it asks for the password... This is, as far as I can see, a poor man's 'two-factor' authentication, is it not? I think you are misunderstanding how ssh keys work. You do not create an SSH key that requires a password, instead the user sets up private key encryption locally with a secret. To use the key it must be unlocked (decrypted) and only then can ssh use it. This is completely under the USER's control, who is free to protect or not protect the private key as they feel like. sshd on the server is unable to enforce or influence this in any way. Secondly, the statement use this ssh key to connect to the system it was created for is nonsensical. A key pair has two components - public and private keys, and the only thing sshd cares about is whether the user connecting has the matching private key to the public one sshd can read locally. The user is free to use that public key on as many or as few servers as he feels like, and again sshd is in no position to enforce or influence this. It is completely up to the user what he does with his keys. Perhaps you mean that on the server end the user's account has a password defined and sshd is configured to use PAM. The PAM config could require that the user authenticates successfully with ssh keys AND with the Unix password before logging the user in. This can be done, but it is not a common configuration and does not ship out the box. It will also confuse the living daylights out of the average user who at least in my world is unable to differentiate between a local ssh prompt for a key passphrase, and a remote telnet prompt for a password... -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: scripted iptables-restore
On 17/10/2013 01:21, Walter Dnes wrote: On Mon, Oct 14, 2013 at 10:45:10PM +0200, Alan McKinnon wrote Access to my backend network is two-factor - ssh keys and decent passwords. That is *NOT* Two-factor authentication. See http://en.wikipedia.org/wiki/Multi-factor_authentication for the details. Executive summary... Two-factor authentication requires you to present two authentication factors each time. I.e. it's A *AND* B. Your setup is A *OR* B. The usual implimentations include 2 factors... 1) userID+password 2) a small credit-card-sized unit that generates random-looking multi-digit numbers that change every minute. In order to logon the user must enter both the userID+password combo *AND* the current number on the token card. It's a poor choice of words on my part. We do have that exact two-factor system to access the network via VPN, but that's just a portal. Accessing the actual backend network is a two stage process: ssh key to the jump host, then password to get onto the actual destination. So it's two factor as a generic English language phrase, not two factor as a technical description of an exact thing. Keep in mind that English is a highly overloaded language :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: scripted iptables-restore
On Thu, Oct 17, 2013 at 08:59:15AM +0200, Alan McKinnon wrote Accessing the actual backend network is a two stage process: ssh key to the jump host, then password to get onto the actual destination. So it's two factor as a generic English language phrase, not two factor as a technical description of an exact thing. Keep in mind that English is a highly overloaded language :-) I apologize. That is arguably a two factor system. When you said ssh key and password, I jumped to delusions, assuming that it was a standard ssh connection with the option of either key or password. Does the jump host restrict you to logging on to the account corresponding to the key? I.e. would John Smith got to the jump host with his key, could he log in to the Jane Doe account, or only John Smith. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: scripted iptables-restore
On 18/10/2013 04:30, Walter Dnes wrote: On Thu, Oct 17, 2013 at 08:59:15AM +0200, Alan McKinnon wrote Accessing the actual backend network is a two stage process: ssh key to the jump host, then password to get onto the actual destination. So it's two factor as a generic English language phrase, not two factor as a technical description of an exact thing. Keep in mind that English is a highly overloaded language :-) I apologize. That is arguably a two factor system. When you said ssh key and password, I jumped to delusions, assuming that it was a standard ssh connection with the option of either key or password. Does the jump host restrict you to logging on to the account corresponding to the key? I.e. would John Smith got to the jump host with his key, could he log in to the Jane Doe account, or only John Smith. I built it myself, so I done did it rite :-) It's very much one key to one user and the only jump host the general user (i.e. customer support) can use is the main advertised one. Infrastructure people and my friends in NetOps have other ways of getting into the network but those are very restricted access. When building this, we found something interesting - dudes were sharing keys. The mind boggles as to why anyone thought this a good idea but that's what they were doing. I suspect some people found ssh-keygen and/or PuTTY too difficult to wrap their wits around. But the fix was simple - with 700+ users and 250+ hosts to manage, we do user deployment centrally with no way to bypass it. The database field containing the public key string was given a unique index. No more duplicate keys :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: scripted iptables-restore
On Mon, Oct 14, 2013 at 10:45:10PM +0200, Alan McKinnon wrote Access to my backend network is two-factor - ssh keys and decent passwords. That is *NOT* Two-factor authentication. See http://en.wikipedia.org/wiki/Multi-factor_authentication for the details. Executive summary... Two-factor authentication requires you to present two authentication factors each time. I.e. it's A *AND* B. Your setup is A *OR* B. The usual implimentations include 2 factors... 1) userID+password 2) a small credit-card-sized unit that generates random-looking multi-digit numbers that change every minute. In order to logon the user must enter both the userID+password combo *AND* the current number on the token card. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-user] Re: scripted iptables-restore
Michael Orlitzky mich...@orlitzky.com wrote: Port knocking is cute, but imparts no extra security. It does, for instance if you use it to protect sshd and sshd turns out to be vulnerable; remember e.g. the security disaster with Debian. A better, secure way to achieve the same goal is with OpenVPN. Using yet another service with possible holes to protect a sshd? In this case, I would like port knocking at least for this OpenVPN. In this case, the absolute worst that could happen is that an attacker gains access to every open port on your system. While this is bad, it's not a clever new vulnerability: it's all of the old ones that were already there. It is exactly the kind of attacks for which one usually uses iptables. You are right, iptables is just one extra step of security, so the worst thing which can happen is that this step is useless. However, if you are willing to risk this only because of your own lazyness in scripting then why do you setup iptables in the first place? If there are insecure daemons listening on public addresses The problem is that nobody can be sure that some daemon is safe. Even presumably safe services turn out to be victims of new kind of attacks, occassionally.
[gentoo-user] Re: scripted iptables-restore (was: Where to put advanced routing configuration?)
Pandu Poluan pa...@poluan.info wrote: Thanks, Martin! I was about to create my own preprocessor, but I'll check out yours first. If it's what I had planned, may I contribute, too? Sure, patches are welcome.
[gentoo-user] Re: scripted iptables-restore
William Kenworthy bi...@iinet.net.au wrote: If you are going to go to this bother ... why not use shorewall, create When I checked for scripts creating rules, none fulfilled my needs. (I do not know whether I checked shorewall at this time). For instance, instead of dropping most packets, I want to reject them properly, only with a rate-limit to avoid DOS. Then there is the mentioned port knocking, some forwarding etc. pp. a custom configuration for each site (including any changes to services) and and have your script just copy them in and restart the various services including shorewall? Instead of managing dozens of configurations manually, I think it is easier to have one script which creates an appropriate custom configuration on all my machines, depending on certain files in /etc and other tests. That's why I always run my firewall script on startup (or if I severely change the configuration). I use a simple script with autosetup using network-manager network-manager is on my university's laptop (with Ubuntu - not my decision), but on any safe machine (running Gentoo) I refuse to install the gaping security hole polkit which unfortunately is a hard dependency of network-manager. As soon as polkit is on an machine on which you use a browser, it makes no sense to spend time pretending to make it secure: Barring your back door even more when the front door of your house was removed is rather pointless...
Re: [gentoo-user] Re: scripted iptables-restore
On 14/10/13 20:08, Martin Vaeth wrote: William Kenworthy bi...@iinet.net.au wrote: If you are going to go to this bother ... why not use shorewall, create When I checked for scripts creating rules, none fulfilled my needs. (I do not know whether I checked shorewall at this time). For instance, instead of dropping most packets, I want to reject them properly, only with a rate-limit to avoid DOS. Then there is the mentioned port knocking, some forwarding etc. pp. a custom configuration for each site (including any changes to services) and and have your script just copy them in and restart the various services including shorewall? Instead of managing dozens of configurations manually, I think it is easier to have one script which creates an appropriate custom configuration on all my machines, depending on certain files in /etc and other tests. That's why I always run my firewall script on startup (or if I severely change the configuration). Been there, done that, after the various disasters of editing/sed'iting in place config files I took the cowards way out - at least when it all goes wrong its now easy to fix, and is a LOT less fragile, especially after upgrades :) Its also a lot harder to do once you get to some of the weirder environments with conflicting requirements. Keep in mind that shorewall or similar wont handle all the parts needed to make this work ... vpn's, services etc will need scripting as well, but they certainly make the firewall part easier and more secure. Also, if you are editing iptables scripts yourself have a look at shorewall, monmotha or most other professional scripts - can you guarantee you are covering as many bases as these do? - I always shudder when I see someone put together a few rules and think its as good as something thats stood the test of time and review. Or think of it this way, you are using port knocking and trying for extreme defence in depth, but use a home brew firewall ... I dont see anything strange about your requirements and think they should be within the capability of most firewall setups and a knowledgeable admin. I totally agree on network manager - its a pita. In this cae its a left over from an abortive attempt to like gnome3 ... I am now using LXDE but everytime I try and strip more gnome out of the system it either breaks or reinstalls the gnomey bits Ive just removed :( Maybe a reinstall during the Christmas break - prezzies! BillK
Re: [gentoo-user] Re: scripted iptables-restore
On 10/14/2013 07:49 AM, Martin Vaeth wrote: Michael Orlitzky mich...@orlitzky.com wrote: Port knocking is cute, but imparts no extra security. It does, for instance if you use it to protect sshd and sshd turns out to be vulnerable; remember e.g. the security disaster with Debian. A better, secure way to achieve the same goal is with OpenVPN. Using yet another service with possible holes to protect a sshd? In this case, I would like port knocking at least for this OpenVPN. The sensitive parts of OpenVPN are audited regularly, and it uses SSL -- public key auth to exchange a symmetric key, both of which use tried-and-true algorithms/code. Port knocking on the other hand is just security through obscurity, and is visible over the wire (or over the air, most likely, if you're on a laptop). Obscurity does provide some benefit, but it gets dismissed because we tend to ignore the constant factor when talking about these things. A problem is solved if it's easy to exponentially increase the amount of work an attacker has to do. For an analogy, a somewhat-related issue is that of salting passwords. Typically one stores the salt in the database in clear text, and this tends to freak people out. Doesn't that make it easier for an attacker to brute force your passwords? Well, yes, but the salt isn't meant to stop a brute force attack. It's meant to stop rainbow table attacks. The way you stop brute force attacks is to use an algorithm with a variable number of rounds that can slow itself down (see: bcrypt). Hiding the salt would just be security through obscurity. You always assume that the attacker knows the details of your algorithm, including the constants. So while hiding the salt would make it a tiny bit harder to brute force, we ignore it in favor of the thing that makes it exponentially harder (variable rounds). Similarly, putting port knocking in front of OpenVPN is like putting a padlock on the bank vault. If someone is going to break OpenVPN, port knocking ain't gonna stop them. It is exactly the kind of attacks for which one usually uses iptables. You are right, iptables is just one extra step of security, so the worst thing which can happen is that this step is useless. However, if you are willing to risk this only because of your own lazyness in scripting then why do you setup iptables in the first place? All of my iptables scripts, even the big ones, run in under a second and get executed 2 or 3 times a year. There's some saying about a baby and bath water. It's not laziness I'm advocating, just simplicity. Simple, understandable code is more likely to be correct than clever code. And in this case, incorrect iptables code is more of a threat than the tiny race condition.
Re: [gentoo-user] Re: scripted iptables-restore
On 2013-10-13 4:07 PM, Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote: Like passwords, these sequences should better not stay the same for too long... Forced changing of passwords (and I imagine the same can be said for port-knocking sequences, which I've never implemented, but am intrigued by, although I tend to avoid security-through-obscurity schemes) periodically as a way to 'better security' is one of those myths that just never seem to go away. Enforce strong passwords and a policy that no one is to ever write a password down and put it in any publicly accessible place, and educate users how not to fall for phishing attacks, is the single most effective way to keep things secure. Then only change a password if/when an account is compromised. This combined with intelligent rate-limiting (with notifications/warnings to admins if/when a users account exceeds them) is all you need. In fact I go one step further... I assign passwords, and do not even allow users to change them. I have always done this, and we have people in this office that have had the same email password (on the same gentoo server) for 12+ years. I know that I'm probably the exception to this rule, and it is more luck than anything else, but we have never had an email account hacked (knock on wood). I'm certainly not saying we are immune, but the claim that passwords should be forcibly changed for no reason other than the passage of some arbitrary amount of time is just plain dumb.
[gentoo-user] Re: scripted iptables-restore
Michael Orlitzky mich...@orlitzky.com wrote: On 10/14/2013 07:49 AM, Martin Vaeth wrote: Using yet another service with possible holes to protect a sshd? In this case, I would like port knocking at least for this OpenVPN. The sensitive parts of OpenVPN are audited regularly, and it uses SSL -- public key auth to exchange a symmetric key, both of which use tried-and-true algorithms/code. So its completely as well-audited and secure as openssh was when the Debian disaster happened. Also IIRC there are currently some timing attacks against certain SSL modes, and who knows when some clever hacker finds another possibility nobody thought of up to now. Port knocking on the other hand is just security through obscurity As is every password. and is visible over the wire This is why you have to change it regularly. Actually, if you change it whenever you used it, you have a rather strong method, essentially only vulnerable if the man-in-the-middle is able to cut your connection, and even then he has only very limited time to attack the actual service which is protected by it. problem is solved if it's easy to exponentially increase the amount of work an attacker has to do. And exactly for this reason the solution is always only a theory - for very particularly specified problems. For practical machines, it is good to have this *in addition* to other safety measurements: Experience shows that rather often there are some new ideas or bugs which can be used to avoid the exponential amount by something not covered by the original theory. Obscurity does provide some benefit, but it gets dismissed because we tend to ignore the constant factor when talking about these things. This is reasonable for theory, but in practice the constant factor can be more important. Even more if it needs human intervention. Hiding the salt would just be security through obscurity. And yet it is stupid if you do not do it and give away a huge constant factor for no advantage. Similarly, putting port knocking in front of OpenVPN is like putting a padlock on the bank vault. If someone is going to break OpenVPN, port knocking ain't gonna stop them. No. Port knocking is more like putting your bank vault into a wooden box. If some new attack against SSL or the OpenVPN implementation is found, it is like somebody has a key to your vault. If you are a highly important target, this will not save you, but if human resources are needed to break whatever you did for obscurity, it makes in practice the crucial difference. It's not laziness I'm advocating, just simplicity. Simple, understandable code is more likely to be correct than clever code. And in this case, incorrect iptables code is more of a threat than the tiny race condition. You have a strange mentality: One the one hand you are afraid that a rather primitive translation of one syntax into another leads to unexpected effects, and on the other hand you trust much more complex things like SSL and OpenVPN which could much easier allow unexpected things with even the slightest attempt to secure them further if you can.
[gentoo-user] Re: scripted iptables-restore
Tanstaafl tansta...@libertytrek.org wrote: Like passwords, these sequences should better not stay the same for too long... Forced changing of passwords I agreee: To do this to protect *other* users will not work. It's a different thing if you use it for protection of your own data...
Re: [gentoo-user] Re: scripted iptables-restore
On 10/14/2013 02:49 PM, Martin Vaeth wrote: Hiding the salt would just be security through obscurity. And yet it is stupid if you do not do it and give away a huge constant factor for no advantage. (I'll just agree to disagree about the rest.) Keeping the salt secret makes your application more complex. Rather than SELECT hash, salt FROM users WHERE..., you now have to SELECT hash FROM users WHERE... and then pull the salt from somewhere else. (Where? The filesystem? Do you encrypt that? How?) What's stupid is going to all that effort for a 2x improvement when you could twiddle a bit and get a 340282366920938463463374607431768211456x improvement.
Re: [gentoo-user] Re: scripted iptables-restore
On 2013-10-14 2:52 PM, Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote: Tanstaafl tansta...@libertytrek.org wrote: Like passwords, these sequences should better not stay the same for too long... Forced changing of passwords I agreee: To do this to protect *other* users will not work. It's a different thing if you use it for protection of your own data... True to an extent... but only if the frequency of changing the password doesn't result in you doing something dumb to help you remember the current password of the day - like writing it on a post-it and sticking it underneath the keyboard... ;) One of many reasons why I use a password manager (I prefer the Passwordmaker firefox extension, even with all it warts - it only stores settings, not the passwords themselves)... But there are still only a couple of (critical) passwords I change frequently (what I call frequently - every 3-6 months or more)...
Re: [gentoo-user] Re: scripted iptables-restore
On 14/10/2013 21:17, Michael Orlitzky wrote: On 10/14/2013 02:49 PM, Martin Vaeth wrote: Hiding the salt would just be security through obscurity. And yet it is stupid if you do not do it and give away a huge constant factor for no advantage. (I'll just agree to disagree about the rest.) Keeping the salt secret makes your application more complex. Rather than SELECT hash, salt FROM users WHERE..., you now have to SELECT hash FROM users WHERE... and then pull the salt from somewhere else. (Where? The filesystem? Do you encrypt that? How?) What's stupid is going to all that effort for a 2x improvement when you could twiddle a bit and get a 340282366920938463463374607431768211456x improvement. Keep in mind the actual original purpose of a salted hash. If two users happen to use the same password[1], the hashes are the same and this is revealed to anyone who can read /etc/passwd[2] i.e everyone. Salt obscures this 1-to-1 mapping and does it in a way that it is not computationally worth while to try get around it for the general case[3]. It's not quite the same thing as security by obscurity - that is hiding something in a place you think no-one will think of looking but usually turns out to be viable to try and guess. Salt works because brute force now doesn't need just one expensive calculation, it needs many thousands of expensive calculations. If the actual problem is that salt is inadequate, the solution is not to try and hide it, but to use a more complex hashing algorithm with larger salt. It's a race between white and black hats - they build bigger and better rainbow tables, we implement bigger and better hashes. The constraint is how much cpu grunt is available for purchase at a realistic cost. [1] This is not uncommon. The domain size of all possible passwords for a implementation is very very large. Human psychology says that the actual domain size of passwords people will pick is a tiny fraction of the whole. Hence salt. [2] Nowadays we use shadow, but the development of salt pre-dates shadow -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: scripted iptables-restore
On 14/10/2013 20:23, Tanstaafl wrote: On 2013-10-13 4:07 PM, Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote: Like passwords, these sequences should better not stay the same for too long... Forced changing of passwords (and I imagine the same can be said for port-knocking sequences, which I've never implemented, but am intrigued by, although I tend to avoid security-through-obscurity schemes) periodically as a way to 'better security' is one of those myths that just never seem to go away. Enforce strong passwords and a policy that no one is to ever write a password down and put it in any publicly accessible place, and educate users how not to fall for phishing attacks, is the single most effective way to keep things secure. Then only change a password if/when an account is compromised. Here here. I fully agree, and I have a use case to back you up. Yes, it's anecdotal and just my use case, but at least it's factual :-) Access to my backend network is two-factor - ssh keys and decent passwords. I generate the passwords in code, they have high randomity but rememberable and I refuse to implement password expiry. People with sensitive and powerful accounts have enough head smarts to know when to tell me quietly they need a reset done, and everyone is happy with this. they don't mind that I see their passwords once in plaintext, as I can make the password anything I want anytime I want. The user's security against me comes via the HR department backed up by employment law. We have pentesters that exhaustively test stuff every few months. I insist they have full access to my data, supervised by the very trusted Risk guy, as I want them to find any weakness as opposed to the bad guys finding them. In 5 years they have cracked one password once out of many hundreds. One. It's an isolated case and I know how it happened - I trusted someone and bent one rule once. Contrast the scheme used by Windows. It uses every one of these best practice tricks inccluding expiring every 30 days, password length, complexity, special chars etc. With every audit it gets blown wide open, usually within a few hours. reason: human being are almost uniformly bad at selecting and maintaining passwords. I break all the best practice rules and have never have a systemic compromise in 5 years despite awesome tools weilded by real pros with clue throwing the book at it. Hmmm. The other system that does obey best practice gets ripped to pieces with trivial ease by the same guys. Hmmm. I can pull this off because a) few people dare go up against me and my facts :-) and b) it's a controlled environment. Obviously this couldn't work on a public service like say gmail. This combined with intelligent rate-limiting (with notifications/warnings to admins if/when a users account exceeds them) is all you need. In fact I go one step further... I assign passwords, and do not even allow users to change them. I have always done this, and we have people in this office that have had the same email password (on the same gentoo server) for 12+ years. I know that I'm probably the exception to this rule, and it is more luck than anything else, but we have never had an email account hacked (knock on wood). I'm certainly not saying we are immune, but the claim that passwords should be forcibly changed for no reason other than the passage of some arbitrary amount of time is just plain dumb. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: scripted iptables-restore
On 10/14/2013 04:31 PM, Alan McKinnon wrote: Keep in mind the actual original purpose of a salted hash. If two users happen to use the same password[1], the hashes are the same and this is revealed to anyone who can read /etc/passwd[2] i.e everyone. Ah, the single-entry rainbow table =)
[gentoo-user] Re: scripted iptables-restore
Michael Orlitzky mich...@orlitzky.com wrote:
On 10/13/2013 06:08 AM, Martin Vaeth wrote:
5. You can't script iptables-restore!
Well, actually you can script iptables-restore.
For those who are interested:
net-firewall/firewall-mv from the mv overlay
(available over layman) now provides a separate
firewall-scripted.sh
which can be conveniently used for such scripting.
[...]
If you have a million rules and you need to wipe/reload them all
frequently you're probably doing something wrong to begin with.
I don't know how this is related with the discussion.
The main advantage of using iptables-restore is avoidance of
race conditions. A secondary advantage is a speed improvement;
in my case, the machine boots about 2 seconds faster which can
be a considerable advantage if you start virtual machines.
With bash [...]
(I would use a POSIX shell because it is considerably faster,
but this need not be discussed here.)
That's why I said that it can be scripted
(which was my motivation to write firewall-scripted.sh):
firewall-scripted.sh (or some similar script) gives you exactly
the same advantages, but without races, and faster.
In your example:
function static_nat() {
iptables -t nat -A PREROUTING -d ${2} -j DNAT --to ${1}
iptables -t nat -A POSTROUTING -s ${1} -j SNAT --to ${2}
}
Essentially, you just have to replace iptables by FwmvTables 4.
If you are too lazy to use a text editor or to replace iptables
by a variable (like $iptables) you can do this even by
defining the function:
iptables() {
FwmvTables 4 ${@}
}
Then you just put in front of your script the line
. firewall-scripted.sh
and in the end (or before you call exit):
FwmvSet 4
That's it...
I'm not saying you can't do all of this with iptables-restore, just that
you're punishing yourself for little benefit if you do.
*Using* firewall-scripted.sh is as convenient as using iptables directly
(you just replace one command and add two lines to your script).
Of course, the disadvantage is that some day firewall-scripted.sh might
break with iptables (and that maybe the script still has bugs...).
As I said, it would be better if something similar would be provided
by iptables itself. But the advantages are clear.
Re: [gentoo-user] Re: scripted iptables-restore
On 10/13/2013 11:19 AM, Martin Vaeth wrote: [...] If you have a million rules and you need to wipe/reload them all frequently you're probably doing something wrong to begin with. I don't know how this is related with the discussion. The main advantage of using iptables-restore is avoidance of race conditions. A secondary advantage is a speed improvement; in my case, the machine boots about 2 seconds faster which can be a considerable advantage if you start virtual machines. I was just reiterating that there's not much benefit to save/restore if you're doing things properly (pontification alert!). I should say first of all that save/restore is perfect for reboots. If you're not *changing* anything, of course save/restore is better, and suffers none of the problems that I mentioned: you don't read it, the output is fed directly as input, no errors should occur... The bash script is used a couple times a year, and really is there to serve as the specification for what your firewall should do. For example, I'm rebuilding our MX today. I checked the config out of git, ran iptables-config (our script), ran /etc/init.d/iptables save, and the firewall is up and running. When will I run the script again? The next time I rebuild the server? That's certainly the last time I ran it. We have firewalls that change more often, but not so frequently that the speed would be a problem if it were 1000x slower. The MX firewall is actually updated many times per day and accumulates many rules, but they're inserted/deleted in-place by fail2ban, so a full wipe/reload doesn't occur. If you have frequently-changing permanent rules -- say, lots of static NAT entries going in/out for new employees -- then you should be doing insert/delete instead of a full reload just the same. But, add the rule to your iptables script (with a comment!) so that you have it on the record. Once every six months or so, run the thing to make sure nobody made a copy/paste error. Race conditions don't really seem that serious to me. Of course, if you're using iptables for both authorization and authentication, then you're already doing something wrong, and you should fix that instead of trying to make the broken thing run faster. But if not, who cares if you're vulnerable to a brute force attack for 2 seconds? If you're worried about that, implement a password policy. The firewall is the last layer of defense-in-depth; if the absence of a firewall gives you nightmares, the absence of a firewall is not your problem. All of security is a trade-off, and in my opinion, having human-friendly, easily-readable rules (with error checking) will prevent more problems over time than does eliminating the race condition.
[gentoo-user] Re: scripted iptables-restore
Michael Orlitzky mich...@orlitzky.com wrote: [...] If you have a million rules and you need to wipe/reload them all frequently you're probably doing something wrong to begin with. I don't know how this is related with the discussion. The main advantage of using iptables-restore is avoidance of race conditions. A secondary advantage is a speed improvement; in my case, the machine boots about 2 seconds faster which can be a considerable advantage if you start virtual machines. I was just reiterating that there's not much benefit to save/restore if you're doing things properly (pontification alert!). For a laptop of a scientist like me this is not true at all - it must often be connected in a different environment with different local nets etc. Also for other things (like portknocking using the recent module) you need rather complex rules which are better rewritten by a script, especially if the length of a portknocking sequence changes. Like passwords, these sequences should better not stay the same for too long... Race conditions don't really seem that serious to me. Maybe, but I am not sure: There might be situations where it might be possible to keep a port open even when the rule is rewritten later on; then you need an open system only once... So, I could imagine that with some clever hacks an attacker might keep ports open and then do another attack later on. I am not an experienced hacker to know such attacks, but I know that races can be very subtle and provide attack vectors nobody has ever thought off. All of security is a trade-off, and in my opinion, having human-friendly, easily-readable rules (with error checking) It is easy to switch to one method for testing and then back when everything works: If you write $iptables ... throughout you just have to set iptables=iptables or iptables=FvwmTables 4 respectively. In fact, the firewall-mv script does this (with a different mechanism) depending on a commandline switch. Moreover, I observed that the error checking works with iptables-restore as well as with iptables: It shows you almost the same errors, including a line number. So the only difference is that you have to count the lines in the testing output instead of directly seeing the command...
Re: [gentoo-user] Re: scripted iptables-restore
On 14/10/13 04:07, Martin Vaeth wrote: Michael Orlitzky mich...@orlitzky.com wrote: [...] If you have a million rules and you need to wipe/reload them all frequently you're probably doing something wrong to begin with. I don't know how this is related with the discussion. The main advantage of using iptables-restore is avoidance of race conditions. A secondary advantage is a speed improvement; in my case, the machine boots about 2 seconds faster which can be a considerable advantage if you start virtual machines. I was just reiterating that there's not much benefit to save/restore if you're doing things properly (pontification alert!). For a laptop of a scientist like me this is not true at all - it must often be connected in a different environment with different local nets etc. Also for other things (like portknocking using the recent module) you need rather complex rules which are better rewritten by a script, especially if the length of a portknocking sequence changes. Like passwords, these sequences should better not stay the same for too long... ... If you are going to go to this bother ... why not use shorewall, create a custom configuration for each site (including any changes to services) and and have your script just copy them in and restart the various services including shorewall? I have a number of networks from hotspots to places where I need combinations of vpns, web servers and asterisk available for demonstrations in lecture theatres through to travelling and using hotel networks. The iptables save feature gets a bit difficult to use with complex setups and if you are doing something dynamic with the rules (fail2ban for instance) it can save inappropriate rules which need manual culling. I use a simple script with autosetup using network-manager (yuk, horrible thing!) to detect known gateways and trigger the script with that argument for either wifi or cable as appropriate (or setup for anonymous hotspot for unknown wifi, basic dhcp if unknown cable) - this is on a macbook air if that matters. BillK
Re: [gentoo-user] Re: scripted iptables-restore
On 10/13/2013 04:07 PM, Martin Vaeth wrote: I was just reiterating that there's not much benefit to save/restore if you're doing things properly (pontification alert!). For a laptop of a scientist like me this is not true at all - it must often be connected in a different environment with different local nets etc. Sure, but do the rules change? Is there a better ruleset that accomplishes the same thing with fewer (or universal) rules? How many rules do you have at the location requiring the most rules? Most laptops should be OK with the following: iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT iptables -A INPUT -p ALL -i lo -j ACCEPT iptables -A INPUT -p ALL -m conntrack \ --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p ALL -m conntrack \ --ctstate INVALID -j DROP ALLOWED_ICMP=0 3 4 8 11 12 for icmp_type in $ALLOWED_ICMP; do iptables -A INPUT -p icmp --icmp-type $icmp_type -j ACCEPT done And creative setups should only require a few more rules. This all takes under (1/10) of a second on my laptop. Also for other things (like portknocking using the recent module) you need rather complex rules which are better rewritten by a script, especially if the length of a portknocking sequence changes. Like passwords, these sequences should better not stay the same for too long... Port knocking is cute, but imparts no extra security. A better, secure way to achieve the same goal is with OpenVPN. And that doesn't require you to play games with your firewall. If you use your laptop at hotels, universities, and conferences, you'll have a much happier time connecting to OpenVPN on tcp/443 (which nobody can block) than you will trying to connect directly. Race conditions don't really seem that serious to me. Maybe, but I am not sure: There might be situations where it might be possible to keep a port open even when the rule is rewritten later on; then you need an open system only once... So, I could imagine that with some clever hacks an attacker might keep ports open and then do another attack later on. I am not an experienced hacker to know such attacks, but I know that races can be very subtle and provide attack vectors nobody has ever thought off. In this case, the absolute worst that could happen is that an attacker gains access to every open port on your system. While this is bad, it's not a clever new vulnerability: it's all of the old ones that were already there. If there are insecure daemons listening on public addresses, you should fix them instead of worrying about race conditions on the firewall. Otherwise, every machine on your LAN becomes an attack vector, and that's a much greater risk especially if your coworkers/friends use Windows. And if we're still talking about laptops, the LAN is usually anybody nearby.
