firewalld change default target - centos

From firewalld man page:
–permanent [–zone=zone] --set-target=target
Set the target of a permanent zone. target is one of: default, ACCEPT, DROP, REJECT
The default target is REJECT. Is it possible to change the default target to DROP? If not, why does a default option exist if it is always REJECT?
I am using CentOS 7.4
I understand that I can configure firewalld any way I'd like without being able to change the default target, but I'd like to know how to change it if possible.

On firewalld(1) and its targets as of 2020:
possible POLICY TARGETS (for traffic from one specific zone to another)
CONTINUE
ACCEPT
DROP
REJECT
policies are only in firewalld>=0.9.0
possible ZONE TARGETS (for traffic entering/leaving zones, where the predefined target named "DEFAULT" can actually be used)
DEFAULT
ACCEPT
DROP
REJECT
TARGET: "DEFAULT"
REJECT
allow ICMP
if ingress zone is default, forwardings will follow egress zone target
zone drifting may be applied depending on global setting
The target in a zone is the destination target packets will be sent to if no other zone rules match, and can be
ACCEPT
DROP
REJECT
or be... DEFAULT
"DEFAULT" is basically a simple REJECT plus other sane things for a more sensible default setting, its name choice is somewhat unlucky.
The accepted answer is somewhat misleading as it talks about redefining the target "DEFAULT".
However the question should rather aim at wether setting a different default target in a zone is possible, which it perfectly is:
firewall-cmd --permanent --zone=YOUR_ZONE_HERE --set-target=ACCEPT
firewall-cmd --reload
#some different oneliners to verify your config
#1.
(firewall-cmd --list-all;for i in $(firewall-cmd --get-active-zones|grep -v "^\s");do firewall-cmd --list-all --zone=$i;done)|grep -v ':\s*$'
#2.
fwstatus() { _fwstate=$(firewall-cmd --state 2>&1);printf "FIREWALLD=%s\n" "${_fwstate}";[[ "not running" == ${_fwstate} ]]&&return;_panicstate=$(firewall-cmd --query-panic);if [[ "on" == "${_panicstate}" ]];then printf "\e[41;1m";else printf "\e[32;1m";fi;printf "PANIC MODE=%s\e[m\n" "${_panicstate}";printf "LOCKDOWN=%s\n\n" "$(firewall-cmd --query-lockdown)";_defaultzone=$(firewall-cmd --get-default-zone);firewall-cmd --list-all-zones|sed 's/^'"$_defaultzone"'/& (default)/'|sed -n '/^'"$_defaultzone"'\|active/,/^$/p'|grep -v -e ':\s*$' -e icmp-block-inversion|awk 'NF>0'|grep --color -e$ -e^\\w.\\+;}&&fwstatus ## show full firewalling state,only works when firewalld is running
#3.
firewall-cmd --zone=YOUR_ZONE_HERE --list-all

It is not possible to change the default target - it's hardcoded. It's possible "default" was included so we could potentially introduce a "--set-default-target" option in the future, but I'm just speculating.
https://github.com/firewalld/firewalld/issues/252

Related

In docker-compose, what is the effect/purpose of `dns-search: .`

I am looking at the stackstorm docker-compose file, and within it almost all containers have a line dns_search: . According to docker-compose documentation, dns_search is for the purpose of configuring search domains.
I am used to seeing this in context of transparently adding a domain to unqualified short domains. For example if I add dns_search: mydomain.com, I would expect "host1" to transparently resolve as "host1.mydomain.com".
I have never seen this set as a single dot . before. What is the effect/purpose of doing this configuration?
I'm posting the answer from the Stackstorm Git project issue see comment/"dns_search: .". Paraphrasing: it was useful in old versions of Docker before 2017, before the ndots configuration was available. Nowadays that configuration has no impact, and in fact has been removed from the stackstorm docker-compose file.
I believe this is because all domain names end in . under the hood, but browsers and other software abstracts this out.
For example. under the hood www.google.com is actually www.google.com.
So, in the docker-compose file, this would essentially be saying "Find me any domain"
A bit more detail on why there's an extra dot, if you're interested:
Domain name resolution is heirachical, reading right to left, with each block, separated by a ., being a step in the process. A DNS resolver will first find a source of ., which will be able to return the address for a resolver for the next block, until it reaches the final block, where it returns the full DNS record.
Extending EdwardTeach's answer:
#ytjohn effectively said they did in the past because putting dns_search: . configures the DNS search domains to be only . instead of inheriting the host ones. I can't confirm that because I didn't test it.
Now, I tested what docker-compose does today, and in a container, cat /etc/resolve.conf returns:
nameserver 127.0.0.11
options ndots:0
Where options ndots:0 is (from resolv.conf docs):
ndots:n
Sets a threshold for the number of dots which must
appear in a name given to res_query(3) (see
resolver(3)) before an initial absolute query will
be made. The default for n is 1, meaning that if
there are any dots in a name, the name will be
tried first as an absolute name before any search
list elements are appended to it. The value for
this option is silently capped to 15.
With ndots:0, all domains will be attempted using the absolute name first, only then using the search list.
How I came to this conclusion
The Github comment:
If you don't set this dns_search: ., then whatever the host has in search in their /etc/resolv.conf will get put into your container's /etc/resolv.conf.
This doesn't happen. My host has search domain[0]: broadband (macOS command: scutil --dns), and in docker containers, it doesn't show broadband (linux command: cat /etc/resolv.conf). Instead, it says options ndots:0
dns_search docs:
dns defines custom DNS search domains to set on container network interface configuration. Can be a single value or a list.
What is a DNS search domain?
It is the DNS service used to resolve hostnames that are not fully qualified, e.g. hostname will try hostname.example.com then hostname.website.com if your search domains list was example.com, website.com. More information on https://superuser.com/a/184366
In another repo (crossdock), their dockerfile had the comment:
`dns_search: . # Ensures unified DNS config.`

What is SystemD's default value for LimitNOFILE (on CentOS7)

It seems like a very easy question but I couldn't find, what the default for services in SystemD for LimitNOFILE is.
Is there a file with global defaults?
#/etc/security/limits.conf
#This file sets the resource limits for the users logged in via PAM.
#It does not affect resource limits of the system services.
#if your program startup via systemctl
#config /etc/systemd/system.conf
DefaultLimitNOFILE=
systemd imposes no such limit by default. however pam_limits generally does, configuration file is /etc/security/limits.conf
The default config is in /etc/systemd/system.conf, and the default value is DefaultLimitNOFILE=1024:524288.

How to detect a couple of pings transmitted from a virtual machine to another by using Snort, which is integrated in AlienVault?

For the record: I did the following instruction (found them on a website)
I enabled snort sensors (snort_syslog and snortunified).
In alienvault: ~# nano /etc/snort/rules/local.rules
I did the following rule
alert icmp 192.168.1.130 192.168.1.120 -> any any
(msg:"blablabla"; sid:1000004)
Save and exit
After that I did:
alienvault:~# perl /usr/share/ossim/scripts/create_sidmap.pl /etc/snort/rules/
alienvault:~# /etc/init.d/ossim-server restart
For some reasons nothing happens in AlienVault interface in SIEM when I ping 192.168.1.120 from 192.168.1.130.
Any ideas??
I don't know wether it is still relevant but in my opinion there is a mistake in your Snort rule:
The rule in Snort cannot consist of two IP-adresses in the first part of the rule header.
At the point where you declared the IP '192.168.1.120' you have to declare a port.
The solution you need looks like the following (if i get you right):
alert icmp 192.168.120 any -> 192.168.1.130 any (msg:"blablabla"; sid:1000004)
And also the other way:
alert icmp 192.168.1.130 any -> 192.168.1.120 any (msg:"blablabla"; sid:1000005)
For writing rules in the correct syntax take a look at the manual of snort: http://manual.snort.org/node29.html#SECTION00423000000000000000
I hope that this can help you.
/Chris

Configuring FQDN for GCE instance on startup

I am trying to start a google compute engine (GCE) instance with a pre-configured FQDN. We are intending to run an application that is licensed based on the contents of /etc/hosts.
I am starting the instances using the Google Cloud SDK utility - gcloud.
I have tried setting the "hostname" key using the metadata option like so:
gcloud compute instances create mynode (standard opts) --metadata hostname=mynode.example.com
Whenever I log into the developer console, under computer, instances, I can see hostname under "Custom metadata". This appears to be a new, custome key - it has no impact on what:
http://metadata.google.internal/computeMetadata/v1/instance/hostname
returns.
I have also tried setting "instance/hostname" like the below, which causes a parsing error when using gcloud.
--metadata instance/hostname=mynode.example.com
I have successfully used the startup scripts functionality of the metadata server to run a startup script that parses the new, internal IP address of the newly created instance, updated /etc/hosts. This appears to work but doesn't feel "like the google way".
Can I configure the FQDN (specifically, a domain name, as the instance name is always the hostname) of an instance, during instance creation, using the metaserver functionality?
try this:
Go to your GCE >> VM instances panel.
stop your gce instance.
clic on the instance name.
Edit your instance, adding this values on Custom metadata fields:
Key field: hostname / Value field: your.server.hostname
Key field: startup-script / Value field: sudo -s hostnamectl set-hostname your.server.hostname
setup-example-image.png
Finally, start your instance and test with a hostnamectl command.
regards!
According to this article 'hostname' is part of the default metadata entries that provide information about your instance and it is NOT possible to manually edit any of the default metadata pairs. You can also take a look at this video from the Google Team. Within the first few minutes it is mentioned that you cannot modify default metadata pairs. As such, it does not seem like you can specify the hostname upon instance creation other than through the use of a start-up script like you've done already. It is also worth mentioning that the hostname you've specified will get deleted and auto-synced by the metadata server upon reboot unless you're using a start-up script or something that would modify it every time.
If what you're currently doing works for what you're trying to accomplish, it might be the only workaround to your scenario.
Here is a patch for /usr/share/google/set-hostname to set FQDN to GCE instance.
https://gist.github.com/yuki-takeichi/3080521322f0f1d159ea6a343e2323e6
Before you use this patch, you must set your desired FQDN in your instance's metadata by specifying hostname key.
Hostname is set each time instance's IP address is renewed by dhclient. set-hostname is just a hook script which dhclient executes and serves new IP address and internal hostame to, and modifies /etc/hosts. This patch changes the source of hostname by querying instance's metadata from metadata server.
The original set-hostname script is here:
https://github.com/GoogleCloudPlatform/compute-image-packages/blob/master/google_config/bin/set_hostname.
Use this patch at your own risk.
When creating a VM, you can specify a custom FQDN hostname as an optional parameter. This feature is currently in Beta.
$ gcloud beta compute instances create INSTANCE_NAME --hostname example.hostname
This should work across OSes, and eliminate the need for workaround scripts.
More info in the docs.
-- Sirui (Product Manager, Google Compute Engine)
I've looked throughout this site to find answered questions and found a few things that work but with a couple solutions combined. This thread seems the place to answer.
1) echo example.com > /etc/hostname
2) add -- 127.0.1.1 example.com in /etc/hosts
3) add -- hostnamectl set-hostname
example.com -- command to /etc/rc.local script
4) uncomment /etc/dhcp/dhclient.conf line:
supersede domain-name "example.com";
5) profit.... Seems to stick after each reboot
(Note example.com is your domain name: fqdndomain.com - yourfqdndomain.org)
Also note this is for Ubuntu or Debian. Other Unix May slightly vary. I've tested this on Ubuntu 16.04
Always on the wording NOT possible to manually edit any of the default metadata pairs, how about the instant level default metadata "/scheduling"? we could set them manually as mentioned in this article

haproxy - which configuration files

I have an HAProxy install which was configured by someone who left the company. It runs on Ubuntu 10.04 and it seems to use 3 configuration files in the directory /etc/haproxy
haproxy.cfg
haproxy.http.cfg
haproxy.https.cfg
I don't see the point in using the haproxy.https.cfg file as I believe (in our configuration) it can all be configured from a single haproxy.http.cfg file but when I remove that httpS file it complains bitterly and refuses to run. My question
Is this the standard configuration haproxy uses or if not, I can't find a reference to the "S" file anywhere. Can anyone suggest how HAProxy concludes it should use it?
Thanks
The very answer to your question: your haproxy is simply launched with those three config files ( -f haproxy.cfg -f haproxy.http.cfg -f haproxy.https.cfg, maybe from /etc/init.d/haproxy but mileage varies depending on your distribution ).
If you remove the file, of course it will complain.
This is not particularly standard, but ain't bad either, it helps structuring the conf rather than having a very long file.
The task of the .https version will certainly be to redirect the https traffic towards a service that can handle HTTPS (stunnel or nginx usually), since haproxy cannot terminate ssl connections. (stunnel has to be patched, see on the haproxy page)
If you want you can merge those files into one or two, just find out how haproxy is launched (check for init.d or let us know which distribution) and fix it appropriately.
I believe that it is only /etc/haproxy/haproxy.cfg that is used by default.
This may be of use to you (1.4 configuration reference):
http://haproxy.1wt.eu/download/1.4/doc/configuration.txt