Closed baudm closed 9 years ago
Comment #1 originally posted by baudm on 2011-07-09T10:58:18.000Z:
I'm using the method ufw.parser.UFWCommandRule.get_command() to generate the corresponding command for a given rule. I investigated the issue and found out that this method does not give the proper command for "deny out" rules. I'll investigate more to find out why exactly.
Comment #2 originally posted by baudm on 2011-09-07T06:18:11.000Z:
Hello. I can no longer reproduce this bug. Can you post here concrete examples?
Comment #3 originally posted by baudm on 2011-09-08T21:24:24.000Z:
Hello.
x.x.x.x has to be substituted with valid IPv4 address:
# ufw deny out to x.x.x.x
# ufw status
Status: active
To Action From
-- ------ ----
x.x.x.x DENY OUT Anywhere
content of the exported file:
#!/bin/sh
ufw deny to x.x.x.x
(which is not the same - the exported rule would allow to "access" the host: ping, browse if it's a WWW server).
from ufw-gtk:
# | Action | Direction | Protocol | Source | Port/App | Destination | Port/App
------------------------------------------------------------------------------
1 | DENY | OUT | * | * | * | x.x.x.x | *
Thanks!
Comment #4 originally posted by baudm on 2011-09-09T03:11:39.000Z:
I see. I know understand what this is all about... Considering the following network setup:
A (x.x.x.x) <-- eth0 --> B <-- eth1 --> C
where B acts as a router/gateway between A and C, and where ufw is installed:
# ufw deny out to x.x.x.x
would deny all connections to A, including those originating from B itself.
This effectively "cuts off" communication to A at eth0.
On the other hand:
# ufw deny to x.x.x.x
would deny all connections to A, excluding those originating from B itself.
This effectively "cuts off" communication to A at eth1, which still allows B itself to connect to A.
If my observations are correct, ufw is operating under the assumption that it is running on a machine which acts as a router or gateway. This, I think, is the reason why it exports the DENY OUT rule as a DENY IN rule.
This is really an issue with the UFWCommandRule.get_command() method.
For now, I think can just ship a modified version of the get_command() method until it gets fixed in ufw itself.
Comment #5 originally posted by baudm on 2011-09-09T05:12:00.000Z:
You can follow the developments regarding this issue in the 'hotfix-rules_export' branch:
https://github.com/baudm/ufw-frontends/commits/hotfix-rules_export
Comment #6 originally posted by baudm on 2011-09-10T12:08:44.000Z:
OK, seen that, thanks.
Comment #7 originally posted by baudm on 2011-09-10T13:51:41.000Z:
Old link is broken. Please check this instead: https://github.com/baudm/ufw-frontends/tree/hotfix/rules-export
Btw, did it work for you?
Comment #8 originally posted by baudm on 2011-09-10T18:58:59.000Z:
I have applied the patch (generated from last commit of this branch) to 0.3.0 sources and it worked correctly.
What I have checked: deny in/out IP/port and reject in/out IP. All fine.
A small note: it now exports "IN" rules as "ufw
Original issue 16 created by baudm on 2011-06-25T20:19:40.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead? The IN and OUT rules are exported the same way. OUT rules are not exported correctly.
What version of the product are you using? On what operating system? 0.2.0
Please provide any additional information below.