Azure Devops - OWASP Dependency Check

https://marketplace.visualstudio.com/items?itemName=dependency-check.dependencycheck

OWASP Dependency Check

Dependency-Check is a software composition analysis utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently, Java and .NET are supported; additional experimental support has been added for Ruby, Node.js, Python, and limited support for C/C++ build systems (autoconf and cmake)

The OWASP Dependency Check Azure DevOps Extension enables the following features in an Azure Build Pipeline:

• Software composition analysis runs against package references during build on both Windows and Linux build agents.

• Export vulnerability data to HTML, JSON, XML, CSV, JUnit formatted reports

• Download vulnerability reports from the build's artifacts

CNAME, A-Record, DNS Mapping, AWS Route 53

• https://www.web24.com.au/tutorials/cname-records-used
• https://support.dnsimple.com/articles/differences-a-cname-records/
• https://www.pickaweb.co.uk/kb/cname-can-use-domain/

A CNAME, or Canonical Name record, is a record that points to another domain address rather than an IP address.

For example, say you have several subdomains, like www.mydomain.com, ftp.mydomain.com, mail.mydomain.com etc and you want these sub domains to point to your main domain name mydomain.com. Instead of creating A records for each sub-domain and binding it to the IP address of your domain you can create CNAME records.

As you can see in the table below, in the case where the IP address of your server changes, you only need to update one A record and all the subdomains follow automatically because all the CNAMES point to the main domain with the A record:

(sub)Domain / Hostname	Record Type	Target / Destination
mydomain.com	A	111.222.333.444
www.mydomain.com	CNAME	mydomain.com
ftp.mydomain.com	CNAME	mydomain.com
mail.mydomain.com	CNAME	mydomain.com

Maven 3.8.1 Blocks HTTP repositories

The decision was made to block such external HTTP repositories by default

https://stackoverflow.com/questions/66980047/maven-build-failure-dependencyresolutionexception/67018302#67018302

How to fix when I get a HTTP repository blocked?

If the repository is defined in your pom.xml, please fix it in your source code.

If the repository is defined in one of your dependencies POM, you’ll get a message like:

[ERROR] Failed to execute goal on project test: Could not resolve dependencies for project xxx: Failed to collect dependencies at my.test:dependency:version -> my.test.transitive:transitive:version: Failed to read artifact descriptor for my.test.transitive:transitive:jar:version: Could not transfer artifact my.test.transitive:transitive:pom:version from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories: [blocked-repository-id (http://blocked.repository.org, default, releases+snapshots)]

They go on to offer some ways to avoid the problem:

Options to fix are:

• upgrade the dependency version to a newer version that replaced the obsolete HTTP repository URL with a HTTPS one,

• keep the dependency version but define a mirror in your settings.

Plus, I suppose, the simpler, shorter-term option would be to roll back your version of Maven to anything prior to 3.8.1.

IPTables - Firewall -Linux - Redhat

https://www.redhat.com/sysadmin/iptables

/usr/local/bin vs /usr/bin

https://unix.stackexchange.com/questions/8656/usr-bin-vs-usr-local-bin-on-linux

1. /bin (and /sbin) were intended for programs that needed to be on a small / partition before the larger /usr, etc. partitions were mounted. These days, it mostly serves as a standard location for key programs like /bin/sh, although the original intent may still be relevant for e.g. installations on small embedded devices.

2. /sbin, as distinct from /bin, is for system management programs (not normally used by ordinary users) needed before /usr is mounted.

3. /usr/bin is for distribution-managed normal user programs.

4. There is a /usr/sbin with the same relationship to /usr/bin as /sbin has to /bin.

5. /usr/local/bin is for normal user programs not managed by the distribution package manager, e.g. locally compiled packages. You should not install them into /usr/bin because future distribution upgrades may modify or delete them without warning.

6. /usr/local/sbin, as you can probably guess at this point, is to /usr/local/bin as /usr/sbin to /usr/bin.

In addition, there is also /opt which is for monolithic non-distribution packages, although before they were properly integrated various distributions put Gnome and KDE there. Generally you should reserve it for large, poorly behaved third party packages such as Oracle.

Mongodb /etc/mongod.conf

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

processManagement: fork: true net: bindIp: localhost port: 27017 storage: dbPath: /var/lib/mongo systemLog: destination: file path: "/var/log/mongodb/mongod.log" logAppend: true storage: journal: enabled: true

https://docs.mongodb.com/manual/reference/configuration-options/

https://docs.mongodb.com/manual/administration/configuration/#std-label-base-config

NACL vs Route Table vs SecurityGroup