1 p.m.
These are the rules being added that I do not care for:
# iptables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
Why is this taking place?
I do not have any other superuser script that would do this.
4:53 a.m.
On 30.10.2014 19:11, Tom Horsley wrote:
...
does. Also the default libvirtd service starts a bunch of
networking things for providing a default network that includes
some firewall tinkering (or used to, anyway).
$ rpm -qil libvirt-daemon-config-nwfilter
Only for virtual network, therefore use bridge and don't cry for last year's
snow.
poma
10:53 p.m.
On 10/31/14 11:37, Tim wrote:
Allegedly, on or about 31 October 2014, Ed Greshko sent:
> I've not used iptables service for a long time....
>
> I don't recall if starting certain services open ports on their own.
I've never seen that. That sort of (dynamic) behaviour is what
firewalld is supposed to do. I could see the sense in the *install*
routine for something like the named package, for example, also
installing firewall rules to allow its normal operation, but I've never
seen that, either.
Yes, of course you're right. Faulty gray matter.....
So used to using firewalld these days, and shorewall previously.
--
If you can't laugh at yourself, others will gladly oblige.
10:37 p.m.
Allegedly, on or about 31 October 2014, Ed Greshko sent:
I've not used iptables service for a long time....
I don't recall if starting certain services open ports on their own.
I've never seen that. That sort of (dynamic) behaviour is what
firewalld is supposed to do. I could see the sense in the *install*
routine for something like the named package, for example, also
installing firewall rules to allow its normal operation, but I've never
seen that, either.
--
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
ZNQR LBH YBBX
10:35 p.m.
On 10/31/14 11:29, jd1008 wrote:
On 10/30/2014 08:51 PM, Ed Greshko wrote:
> netstat -tnap | grep 53 | grep -i listen
> netstat -tnap | grep 67 | grep -i listen
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 3591/dnsmasq
tcp6 0 0 :::53 :::* LISTEN 3591/dnsmasq
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1670/cupsd
tcp6 0 0 ::1:631 :::* LISTEN 1670/cupsd
So, I will be stopping and disabling dnsmasq since it's "domain" is the
whole world.
I will also disable cupsd and enable and start it only when I need to print.
dnsmasq I could understand, although some find it of use. But not cupsd as the port it is
listening on is 631 as 1670 is just part of the process id and causing the match.
But, since I don't see anything on port 67 (I was expecting dhcpd) I don't think
the ports are getting opened by the starting of the process.
So, I don't expect disabling any services to solve your situation.
Like I said, I've not used iptables in a long time. Prior to firewalld I used
"shorewall" to manage my firewall rules.
If I think of something else, I'll let you know.
--
If you can't laugh at yourself, others will gladly oblige.
10:29 p.m.
On 10/30/2014 08:51 PM, Ed Greshko wrote:
netstat -tnap | grep 53 | grep -i listen
netstat -tnap | grep 67 | grep -i listen
tcp 0 0 0.0.0.0:53 0.0.0.0:*
LISTEN
3591/dnsmasq
tcp6 0 0 :::53 :::* LISTEN 3591/dnsmasq
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
1670/cupsd
tcp6 0 0 ::1:631 :::* LISTEN 1670/cupsd
So, I will be stopping and disabling dnsmasq since it's "domain" is the
whole world.
I will also disable cupsd and enable and start it only when I need to print.
9:51 p.m.
On 10/31/14 10:30, jd1008 wrote:
I disabled firewalld and rebooted. Still ...
# iptables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
I've not used iptables service for a long time....
I don't recall if starting certain services open ports on their own.
netstat -tnap | grep 53 | grep -i listen
netstat -tnap | grep 67 | grep -i listen
--
If you can't laugh at yourself, others will gladly oblige.
9:30 p.m.
On 10/30/2014 07:59 PM, Ed Greshko wrote:
On 10/31/14 09:51, jd1008 wrote:
> # systemctl status firewalld.service
> firewalld.service - firewalld - dynamic firewall daemon
> Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
> Active: inactive (dead) since Thu 2014-10-30 19:44:22 MDT; 4min 2s ago
> Main PID: 659 (code=killed, signal=TERM)
> CGroup: /system.slice/firewalld.service
>
> Oct 30 19:44:21 localhost.localdomain systemd[1]: Started firewalld - dynamic
firewall daemon.
> Oct 30 19:44:22 localhost.localdomain systemd[1]: Stopping firewalld - dynamic
firewall daemon...
> Oct 30 19:44:22 localhost.localdomain systemd[1]: Stopped firewalld - dynamic
firewall daemon.
>
> OK - I will disable it, but you stated earlier that it is not the culprit???
I made no statement about your environment. I made an observation about a working
environment on my test system in response to Tom's "god knows what it does"
statement.
> # systemctl status iptables.service
> iptables.service - IPv4 firewall with iptables
> Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled)
> Active: active (exited) since Thu 2014-10-30 19:46:19 MDT; 3min 41s ago
> Process: 2337 ExecStop=/usr/libexec/iptables/iptables.init stop (code=exited,
status=0/SUCCESS)
> Process: 2446 ExecStart=/usr/libexec/iptables/iptables.init start (code=exited,
status=0/SUCCESS)
> Main PID: 2446 (code=exited, status=0/SUCCESS)
>
> Oct 30 19:46:19 localhost.localdomain iptables.init[2446]: iptables: Applying
firewall rules: [ OK ]
> Oct 30 19:46:19 localhost.localdomain systemd[1]: Started IPv4 firewall with
iptables.
You shouldn't have both of those services enabled.
I disabled firewalld and rebooted. Still ...
# iptables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
.
.
.
8:59 p.m.
On 10/31/14 09:51, jd1008 wrote:
# systemctl status firewalld.service
firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
Active: inactive (dead) since Thu 2014-10-30 19:44:22 MDT; 4min 2s ago
Main PID: 659 (code=killed, signal=TERM)
CGroup: /system.slice/firewalld.service
Oct 30 19:44:21 localhost.localdomain systemd[1]: Started firewalld - dynamic firewall
daemon.
Oct 30 19:44:22 localhost.localdomain systemd[1]: Stopping firewalld - dynamic firewall
daemon...
Oct 30 19:44:22 localhost.localdomain systemd[1]: Stopped firewalld - dynamic firewall
daemon.
OK - I will disable it, but you stated earlier that it is not the culprit???
I made no statement about your environment. I made an observation about a working
environment on my test system in response to Tom's "god knows what it does"
statement.
# systemctl status iptables.service
iptables.service - IPv4 firewall with iptables
Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled)
Active: active (exited) since Thu 2014-10-30 19:46:19 MDT; 3min 41s ago
Process: 2337 ExecStop=/usr/libexec/iptables/iptables.init stop (code=exited,
status=0/SUCCESS)
Process: 2446 ExecStart=/usr/libexec/iptables/iptables.init start (code=exited,
status=0/SUCCESS)
Main PID: 2446 (code=exited, status=0/SUCCESS)
Oct 30 19:46:19 localhost.localdomain iptables.init[2446]: iptables: Applying firewall
rules: [ OK ]
Oct 30 19:46:19 localhost.localdomain systemd[1]: Started IPv4 firewall with iptables.
You shouldn't have both of those services enabled.
--
If you can't laugh at yourself, others will gladly oblige.
8:51 p.m.
On 10/30/2014 07:11 PM, Ed Greshko wrote:
On 10/31/14 09:04, jd1008 wrote:
> On 10/30/2014 05:12 PM, Ed Greshko wrote:
>> On 10/31/14 02:11, Tom Horsley wrote:
>>> On Thu, 30 Oct 2014 12:00:28 -0600
>>> jd1008 wrote:
>>>
>>>> Why is this taking place?
>>> Lots of things fiddle with iptables rules.
>>>
>>> If you have the new firewalld service running, God knows what it
>>> does. Also the default libvirtd service starts a bunch of
>>> networking things for providing a default network that includes
>>> some firewall tinkering (or used to, anyway).
>> FWIW, I'm working on a fresh install at the moment....doing some
"experimenting".
>>
>> Using firewalld, ports 53 (DNS) and 67 (bootp) are not open. Additionally, after
install of the bind and dhcp packages they remain not open.
>>
>> It is only when specifically configured to be opened are they. Also, when
configured by the firewall-config GUI, udp/tcp is open for port 53 but only udp is open
for 67.
>>
> Well, I have done nothing to cause this "recent" change.
> By "recent" I mean within the last few (4-5) days.
>
> So, something is doing this, but have no idea how to track it down.
>
Are you running iptables or firewalld?
systemctl status iptables.service
systemctl status firewalld.service
will tell you/us.
# systemctl status firewalld.service
firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
Active: inactive (dead) since Thu 2014-10-30 19:44:22 MDT; 4min 2s ago
Main PID: 659 (code=killed, signal=TERM)
CGroup: /system.slice/firewalld.service
Oct 30 19:44:21 localhost.localdomain systemd[1]: Started firewalld -
dynamic firewall daemon.
Oct 30 19:44:22 localhost.localdomain systemd[1]: Stopping firewalld -
dynamic firewall daemon...
Oct 30 19:44:22 localhost.localdomain systemd[1]: Stopped firewalld -
dynamic firewall daemon.
OK - I will disable it, but you stated earlier that it is not the culprit???
# systemctl status iptables.service
iptables.service - IPv4 firewall with iptables
Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled)
Active: active (exited) since Thu 2014-10-30 19:46:19 MDT; 3min 41s ago
Process: 2337 ExecStop=/usr/libexec/iptables/iptables.init stop
(code=exited, status=0/SUCCESS)
Process: 2446 ExecStart=/usr/libexec/iptables/iptables.init start
(code=exited, status=0/SUCCESS)
Main PID: 2446 (code=exited, status=0/SUCCESS)
Oct 30 19:46:19 localhost.localdomain iptables.init[2446]: iptables:
Applying firewall rules: [ OK ]
Oct 30 19:46:19 localhost.localdomain systemd[1]: Started IPv4 firewall
with iptables.
8:11 p.m.
On 10/31/14 09:04, jd1008 wrote:
On 10/30/2014 05:12 PM, Ed Greshko wrote:
> On 10/31/14 02:11, Tom Horsley wrote:
>> On Thu, 30 Oct 2014 12:00:28 -0600
>> jd1008 wrote:
>>
>>> Why is this taking place?
>> Lots of things fiddle with iptables rules.
>>
>> If you have the new firewalld service running, God knows what it
>> does. Also the default libvirtd service starts a bunch of
>> networking things for providing a default network that includes
>> some firewall tinkering (or used to, anyway).
> FWIW, I'm working on a fresh install at the moment....doing some
"experimenting".
>
> Using firewalld, ports 53 (DNS) and 67 (bootp) are not open. Additionally, after
install of the bind and dhcp packages they remain not open.
>
> It is only when specifically configured to be opened are they. Also, when configured
by the firewall-config GUI, udp/tcp is open for port 53 but only udp is open for 67.
>
Well, I have done nothing to cause this "recent" change.
By "recent" I mean within the last few (4-5) days.
So, something is doing this, but have no idea how to track it down.
Are you running iptables or firewalld?
systemctl status iptables.service
systemctl status firewalld.service
will tell you/us.
--
If you can't laugh at yourself, others will gladly oblige.
8:04 p.m.
On 10/30/2014 05:12 PM, Ed Greshko wrote:
On 10/31/14 02:11, Tom Horsley wrote:
> On Thu, 30 Oct 2014 12:00:28 -0600
> jd1008 wrote:
>
>> Why is this taking place?
> Lots of things fiddle with iptables rules.
>
> If you have the new firewalld service running, God knows what it
> does. Also the default libvirtd service starts a bunch of
> networking things for providing a default network that includes
> some firewall tinkering (or used to, anyway).
FWIW, I'm working on a fresh install at the moment....doing some
"experimenting".
Using firewalld, ports 53 (DNS) and 67 (bootp) are not open. Additionally, after install
of the bind and dhcp packages they remain not open.
It is only when specifically configured to be opened are they. Also, when configured by
the firewall-config GUI, udp/tcp is open for port 53 but only udp is open for 67.
Well, I have done nothing to cause this "recent" change.
By "recent" I mean within the last few (4-5) days.
So, something is doing this, but have no idea how to track it down.
When Linux is doing so many things behind the scenes (which is nothing new),
it does not help when things become visible and make one to think or say
things
about Linux that were, for quite some years, reserved for windows.
So, how do I track this down?
6:12 p.m.
On 10/31/14 02:11, Tom Horsley wrote:
On Thu, 30 Oct 2014 12:00:28 -0600
jd1008 wrote:
> Why is this taking place?
Lots of things fiddle with iptables rules.
If you have the new firewalld service running, God knows what it
does. Also the default libvirtd service starts a bunch of
networking things for providing a default network that includes
some firewall tinkering (or used to, anyway).
FWIW, I'm working on a fresh install at the moment....doing some
"experimenting".
Using firewalld, ports 53 (DNS) and 67 (bootp) are not open. Additionally, after install
of the bind and dhcp packages they remain not open.
It is only when specifically configured to be opened are they. Also, when configured by
the firewall-config GUI, udp/tcp is open for port 53 but only udp is open for 67.
--
If you can't laugh at yourself, others will gladly oblige.
1:46 p.m.
On 10/30/2014 12:11 PM, Tom Horsley wrote:
On Thu, 30 Oct 2014 12:00:28 -0600
jd1008 wrote:
> Why is this taking place?
Lots of things fiddle with iptables rules.
If you have the new firewalld service running, God knows what it
does. Also the default libvirtd service starts a bunch of
networking things for providing a default network that includes
some firewall tinkering (or used to, anyway).
# rpm -e firewalld
error: Failed dependencies:
firewalld >= 0.3.5-1 is needed by (installed)
anaconda-20.25.16-1.fc20.x86_64
firewalld = 0.3.11-3.fc20 is needed by (installed)
firewall-config-0.3.11-3.fc20.noarch
So, why do I need anaconda on an installed system? I thought it was only
useful for the installation media.
1:11 p.m.
On Thu, 30 Oct 2014 12:00:28 -0600
jd1008 wrote:
Why is this taking place?
Lots of things fiddle with iptables rules.
If you have the new firewalld service running, God knows what it
does. Also the default libvirtd service starts a bunch of
networking things for providing a default network that includes
some firewall tinkering (or used to, anyway).
3462
days inactive
3463
days old
14 comments
5 participants
participants (5)
-
Ed Greshko -
JD -
poma -
Tim -
Tom Horsley