IPtables - new vs new, established, related
up vote
6
down vote
favorite
I'm «pretty» new to IPtables, or I have used IPtables a few years, but never with advanced features. I understand the concept of stateful IPtables rules, but recently I discovered that some people only use NEW as state, not NEW,ESTABLISHED,RELATED as I would do, and has always done.
Let's take an example, let's assume that I would allow only outgoing HTTP[S] traffic to pass through the firewall. I know I would also need to allow outgoing DNS traffic in a real world scenario, but this is just an example. I would have written the iptable rules like this:
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A INPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Is this correct? I wonder because I have seen people who have written the same firewall rules like this:
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A INPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW -j ACCEPT
What is the difference between NEW and NEW,ESTABLISHED,RELATED for an outgoing rule? Is it enough just to write NEW and let the firewall do some mysterious magic? Or is it necessary to write NEW,ESTABLISHED,RELATED?
http iptables
edited Oct 20 '15 at 1:53
Thomas Dickey
51.4k594164
asked Jul 12 '15 at 14:48
BufferOverflow
213211
migrated from security.stackexchange.com Jul 13 '15 at 19:05
This question came from our site for information security professionals.
add a comment |
up vote
6
down vote
favorite
I'm «pretty» new to IPtables, or I have used IPtables a few years, but never with advanced features. I understand the concept of stateful IPtables rules, but recently I discovered that some people only use NEW as state, not NEW,ESTABLISHED,RELATED as I would do, and has always done.
Let's take an example, let's assume that I would allow only outgoing HTTP[S] traffic to pass through the firewall. I know I would also need to allow outgoing DNS traffic in a real world scenario, but this is just an example. I would have written the iptable rules like this:
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A INPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Is this correct? I wonder because I have seen people who have written the same firewall rules like this:
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A INPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW -j ACCEPT
What is the difference between NEW and NEW,ESTABLISHED,RELATED for an outgoing rule? Is it enough just to write NEW and let the firewall do some mysterious magic? Or is it necessary to write NEW,ESTABLISHED,RELATED?
http iptables
edited Oct 20 '15 at 1:53
Thomas Dickey
51.4k594164
asked Jul 12 '15 at 14:48
BufferOverflow
213211
migrated from security.stackexchange.com Jul 13 '15 at 19:05
This question came from our site for information security professionals.
As a note, the line is most commonly written this way:-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT. This change essentially turnsiptablesinto a stateful firewall. Instead of having to define each TCP connection properly, this line essentially allows all traffic that has already been processed (and allowed) byiptables.
– prateek61
Jun 28 '16 at 2:44
add a comment |
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I'm «pretty» new to IPtables, or I have used IPtables a few years, but never with advanced features. I understand the concept of stateful IPtables rules, but recently I discovered that some people only use NEW as state, not NEW,ESTABLISHED,RELATED as I would do, and has always done.
Let's take an example, let's assume that I would allow only outgoing HTTP[S] traffic to pass through the firewall. I know I would also need to allow outgoing DNS traffic in a real world scenario, but this is just an example. I would have written the iptable rules like this:
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A INPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Is this correct? I wonder because I have seen people who have written the same firewall rules like this:
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A INPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW -j ACCEPT
What is the difference between NEW and NEW,ESTABLISHED,RELATED for an outgoing rule? Is it enough just to write NEW and let the firewall do some mysterious magic? Or is it necessary to write NEW,ESTABLISHED,RELATED?
http iptables
edited Oct 20 '15 at 1:53
Thomas Dickey
51.4k594164
asked Jul 12 '15 at 14:48
BufferOverflow
213211
I'm «pretty» new to IPtables, or I have used IPtables a few years, but never with advanced features. I understand the concept of stateful IPtables rules, but recently I discovered that some people only use NEW as state, not NEW,ESTABLISHED,RELATED as I would do, and has always done.
Let's take an example, let's assume that I would allow only outgoing HTTP[S] traffic to pass through the firewall. I know I would also need to allow outgoing DNS traffic in a real world scenario, but this is just an example. I would have written the iptable rules like this:
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A INPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Is this correct? I wonder because I have seen people who have written the same firewall rules like this:
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A INPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW -j ACCEPT
What is the difference between NEW and NEW,ESTABLISHED,RELATED for an outgoing rule? Is it enough just to write NEW and let the firewall do some mysterious magic? Or is it necessary to write NEW,ESTABLISHED,RELATED?
http iptables
http iptables
edited Oct 20 '15 at 1:53
Thomas Dickey
51.4k594164
asked Jul 12 '15 at 14:48
BufferOverflow
213211
edited Oct 20 '15 at 1:53
Thomas Dickey
51.4k594164
asked Jul 12 '15 at 14:48
BufferOverflow
213211
edited Oct 20 '15 at 1:53
Thomas Dickey
51.4k594164
edited Oct 20 '15 at 1:53
Thomas Dickey
51.4k594164
edited Oct 20 '15 at 1:53
Thomas Dickey
51.4k594164
51.4k594164
asked Jul 12 '15 at 14:48
BufferOverflow
213211
asked Jul 12 '15 at 14:48
BufferOverflow
213211
asked Jul 12 '15 at 14:48
BufferOverflow
213211
213211
migrated from security.stackexchange.com Jul 13 '15 at 19:05
This question came from our site for information security professionals.
migrated from security.stackexchange.com Jul 13 '15 at 19:05
This question came from our site for information security professionals.
As a note, the line is most commonly written this way:-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT. This change essentially turnsiptablesinto a stateful firewall. Instead of having to define each TCP connection properly, this line essentially allows all traffic that has already been processed (and allowed) byiptables.
– prateek61
Jun 28 '16 at 2:44
add a comment |
As a note, the line is most commonly written this way:-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT. This change essentially turnsiptablesinto a stateful firewall. Instead of having to define each TCP connection properly, this line essentially allows all traffic that has already been processed (and allowed) byiptables.
– prateek61
Jun 28 '16 at 2:44
As a note, the line is most commonly written this way:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT. This change essentially turns iptables into a stateful firewall. Instead of having to define each TCP connection properly, this line essentially allows all traffic that has already been processed (and allowed) by iptables.– prateek61
Jun 28 '16 at 2:44
As a note, the line is most commonly written this way:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT. This change essentially turns iptables into a stateful firewall. Instead of having to define each TCP connection properly, this line essentially allows all traffic that has already been processed (and allowed) by iptables.– prateek61
Jun 28 '16 at 2:44
add a comment |
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
The second configuration will not work (try it!).
Since your default policy is DROP on the OUTPUT chain, the third packet of the TCP three-way-handshake will be blocked by the firewall, as that one does not fall under NEW, so the connection will never be established.
It would work if your default OUTPUT policy would be ACCEPT, or you had some other OUTPUT rule afterwards which would allow ESTABLISHED and RELATED state.
In conclusion, the first ruleset is the correct one, if you want to have DROP as your default policy.
answered Jul 14 '15 at 9:02
katti
55949
Thanks for the answer. That was what I thought, but i got a little bit confused when I saw someone write it with onlyNEW. I thought maybe IPtables creates some sort of records of established connection, and it was then unecessary to useESTABLISHED.
– BufferOverflow
Jul 14 '15 at 13:59
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
The second configuration will not work (try it!).
Since your default policy is DROP on the OUTPUT chain, the third packet of the TCP three-way-handshake will be blocked by the firewall, as that one does not fall under NEW, so the connection will never be established.
It would work if your default OUTPUT policy would be ACCEPT, or you had some other OUTPUT rule afterwards which would allow ESTABLISHED and RELATED state.
In conclusion, the first ruleset is the correct one, if you want to have DROP as your default policy.
answered Jul 14 '15 at 9:02
katti
55949
Thanks for the answer. That was what I thought, but i got a little bit confused when I saw someone write it with onlyNEW. I thought maybe IPtables creates some sort of records of established connection, and it was then unecessary to useESTABLISHED.
– BufferOverflow
Jul 14 '15 at 13:59
add a comment |
up vote
3
down vote
accepted
The second configuration will not work (try it!).
Since your default policy is DROP on the OUTPUT chain, the third packet of the TCP three-way-handshake will be blocked by the firewall, as that one does not fall under NEW, so the connection will never be established.
It would work if your default OUTPUT policy would be ACCEPT, or you had some other OUTPUT rule afterwards which would allow ESTABLISHED and RELATED state.
In conclusion, the first ruleset is the correct one, if you want to have DROP as your default policy.
answered Jul 14 '15 at 9:02
katti
55949
Thanks for the answer. That was what I thought, but i got a little bit confused when I saw someone write it with onlyNEW. I thought maybe IPtables creates some sort of records of established connection, and it was then unecessary to useESTABLISHED.
– BufferOverflow
Jul 14 '15 at 13:59
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
The second configuration will not work (try it!).
Since your default policy is DROP on the OUTPUT chain, the third packet of the TCP three-way-handshake will be blocked by the firewall, as that one does not fall under NEW, so the connection will never be established.
It would work if your default OUTPUT policy would be ACCEPT, or you had some other OUTPUT rule afterwards which would allow ESTABLISHED and RELATED state.
In conclusion, the first ruleset is the correct one, if you want to have DROP as your default policy.
answered Jul 14 '15 at 9:02
katti
55949
The second configuration will not work (try it!).
Since your default policy is DROP on the OUTPUT chain, the third packet of the TCP three-way-handshake will be blocked by the firewall, as that one does not fall under NEW, so the connection will never be established.
It would work if your default OUTPUT policy would be ACCEPT, or you had some other OUTPUT rule afterwards which would allow ESTABLISHED and RELATED state.
In conclusion, the first ruleset is the correct one, if you want to have DROP as your default policy.
answered Jul 14 '15 at 9:02
katti
55949
edited Jul 14 '15 at 9:08
answered Jul 14 '15 at 9:02
katti
55949
answered Jul 14 '15 at 9:02
katti
55949
answered Jul 14 '15 at 9:02
katti
55949
55949
Thanks for the answer. That was what I thought, but i got a little bit confused when I saw someone write it with onlyNEW. I thought maybe IPtables creates some sort of records of established connection, and it was then unecessary to useESTABLISHED.
– BufferOverflow
Jul 14 '15 at 13:59
add a comment |
Thanks for the answer. That was what I thought, but i got a little bit confused when I saw someone write it with onlyNEW. I thought maybe IPtables creates some sort of records of established connection, and it was then unecessary to useESTABLISHED.
– BufferOverflow
Jul 14 '15 at 13:59
Thanks for the answer. That was what I thought, but i got a little bit confused when I saw someone write it with only
NEW. I thought maybe IPtables creates some sort of records of established connection, and it was then unecessary to use ESTABLISHED.– BufferOverflow
Jul 14 '15 at 13:59
Thanks for the answer. That was what I thought, but i got a little bit confused when I saw someone write it with only
NEW. I thought maybe IPtables creates some sort of records of established connection, and it was then unecessary to use ESTABLISHED.– BufferOverflow
Jul 14 '15 at 13:59
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f215757%2fiptables-new-vs-new-established-related%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
As a note, the line is most commonly written this way:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT. This change essentially turnsiptablesinto a stateful firewall. Instead of having to define each TCP connection properly, this line essentially allows all traffic that has already been processed (and allowed) byiptables.– prateek61
Jun 28 '16 at 2:44