Addressed by T2667.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Jul 2 2020
Jul 2 2020
Jul 1 2020
Jul 1 2020
jestabro closed T2662: get_config_dict includes node name as key only for tag and leaf nodes as Resolved.
jestabro closed T2667: get_config_dict: Use utility function for non-empty path argument as Resolved.
jestabro moved T2667: get_config_dict: Use utility function for non-empty path argument from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
jestabro updated the task description for T2667: get_config_dict: Use utility function for non-empty path argument.
jestabro added a comment to T2667: get_config_dict: Use utility function for non-empty path argument.
jestabro changed the status of T2667: get_config_dict: Use utility function for non-empty path argument from Open to Needs testing.
jestabro renamed T2662: get_config_dict includes node name as key only for tag and leaf nodes from get_config_dict includes node as key only for tag and leaf nodes to get_config_dict includes node name as key only for tag and leaf nodes.
c-po added a comment to T1928: Is the 'Welcome to VyOS' message when using SSH an information leak?.
The login banner was always user configurable, see https://docs.vyos.io/en/latest/system/user-management.html?highlight=banner#login-banner
zsdc changed the status of T2556: "show interfaces vrrp" does not return any interface from Confirmed to Open.
This command doing not what you are expecting. It shows virtual VRRP interfaces running in RFC3768 compatibility mode. Add the rfc3768-compatibility option to a VRRP group and a new virtual interface should be listed in the output.
If you want to change this behavior, please describe how exactly.
ocosa added a comment to T1928: Is the 'Welcome to VyOS' message when using SSH an information leak?.
A banner would be a good thing. At least you would be able to have some sort of legal message on your device. I would recommend no banner by default so users can add one.
Jun 30 2020
Jun 30 2020
Re-reading the entry, I am now unsure what you believe should be different.
Possible by backporting https://github.com/vyos/vyos-1x/pull/452 and https://github.com/vyos/vyatta-cfg-system/pull/125 though I think some code using Config would need to be modified - add .exists calls before each .return_value(s) - 1.3's vyos.config doesn't require them, 1.2's I think does.
elianora added a comment to T2653: "set interfaces" Python handler code improvements - next iteration.
Ok, nice. And how about 1.2? Is it possible to fix this with the 1.2.6 release?
Yes, I should parse the tagNode and insert them into the default data.
jestabro added a comment to T2662: get_config_dict includes node name as key only for tag and leaf nodes.
Okay, I will revise that: ... Consequently it returns None for nonsensical input and {} for non-existent paths ...
jestabro added a comment to T2662: get_config_dict includes node name as key only for tag and leaf nodes.
The reason to return the data indexed by a node name: leaf nodes; the data is not a dict. If one wants consistency, then data of a node is returned indexed. This function does one specific thing: return a sub-dictionary from a dictionary, so
This is already fixed in 1.3
thomas-mangin added a comment to T2662: get_config_dict includes node name as key only for tag and leaf nodes.
Thank you for this explaining what is happening. I would indeed rather tag were used as keys.
Sorry, I may have made a mistake. I've confused the order. If there's a problem, I'll reopen it.
jestabro updated the task description for T2662: get_config_dict includes node name as key only for tag and leaf nodes.
jestabro added a comment to T2662: get_config_dict includes node name as key only for tag and leaf nodes.
One compelling idea is to move the implementation of the path argument in get_config_dict out of show_config, and replace it with a function to get a sub dictionary from the full get_config_dict. An example implementation is below. This would not only normalize the result, independent of idiosyncrasies of the current backend, but also future proof the form for the switch to vyconf. Secondly, it would allow us to remove the dependency on show_config itself, since that call is already made at Config initialization. Thirdly, it would allow direct use for off-line config instances, namely those for testing and offload to daemon.
Jun 29 2020
Jun 29 2020
jestabro updated the task description for T2662: get_config_dict includes node name as key only for tag and leaf nodes.
jestabro updated the task description for T2662: get_config_dict includes node name as key only for tag and leaf nodes.
jestabro triaged T2662: get_config_dict includes node name as key only for tag and leaf nodes as High priority.
But you make an excellent point, @thomas-mangin ; it may be best to normalize that within config_dict itself, now that we have the xml processing available ...
thomas-mangin added a comment to T2636: get_config_dict() shall always return a list on <multi/> nodes.
Yes, so there is no way to know at parsing time (unless you have two elements or check the XML) that this is a multi-element. Something "computer-friendly" would generate:
test {
something [one]
}Unknown Object (User) updated the task description for T2661: SSTP wrong certificates check.
Unknown Object (User) created T2661: SSTP wrong certificates check.
showConfig produces the following for multi-nodes:
The value vs list is not produced by showConfig, but rather due to matching in configtree. We'll let @dmbaturin consider if this is an issue or not, but I imagine a jinja macro could address the problem where it occurs in template generation.
thomas-mangin added a comment to T2636: get_config_dict() shall always return a list on <multi/> nodes.
The data returned by get_config_dict should always have the same format to prevent any function using it to have to check if one element is a list or a string.
thomas-mangin added a comment to T2653: "set interfaces" Python handler code improvements - next iteration.
Agreeing and defining the name of the keys to be used in the dict passed to verify/generate/apply, would be very beneficial for the project.
The current code does this by calling a number of helper function (so that all interface have the same keys) but this is not defined or/and enforced.
Yes I'm using 1.2 series.
Jun 28 2020
Jun 28 2020
PR for FRR code in vyos-1x : https://github.com/vyos/vyos-1x/pull/483/files
I suppose "service ids ddos-protection" makes sense indeed.
@Viacheslav If so, the following commands are recommended at least:
@jack9603301
The task of IDS (Intrusion Detection System) is to detect and register attacks, and also to alert when a certain rule is triggered.
If we will use snort and suricata in the future (not a fact), it helps to group logical paths for certain commands.
Should we provide the script which perform the change and define what action can be performed in the xml?
Jun 27 2020
Jun 27 2020
PR for fixing frr-reload: https://github.com/vyos/vyos-build/pull/111
I agree with @jack9603301 on this, as fastnetmon is not a ids solution, and only focuses on ddos protection it is best to avoid ids in the command syntax alltogether...
If you don't consider the complete IDS/IPS support for the time being and only consider DDOS/DOS detection, then the command line may be changed to the following form:
OK, I think IDS detection may not only be the scope of DOS/DDOS detection and action linkage. Snort can monitor and scan data packets, and according to some set rule base to detect the existence of attack behavior, but open snort The detection and defense functions have requirements on the system hardware and software equipment configuration indicators. The specific addresses can be found at the following addresses (as far as I know, opnsense and pfsense support this detection):
Unknown Object (User) added a comment to T2659: Add fastnetmon (DDoS detection) support.
Yes, it is possible not only to detect DoS/DDoS and also to make some reactions and run alert script.
Alert script receives next params:
# $1 client_ip_as_string # $2 data_direction # $3 pps_as_string # $4 action (ban or unban)
The router operating system supports intrusion detection and automatic defense, which may increase the memory and hardware requirements as well as performance load of the router, but for the optional, I feel it is OK.
No, I mean, depending on your console option, it's better to provide complete IDs and IPS functions based on Snort. At present, we use snort to provide IDs or IPS protection functions to pfsense or opnsense open source firewalls, but full startup of this function requires system memory and CPU performance. Maybe it can work with DDoS detection instead of just providing DDoS attack detection. If not, I think the best way is to change the options of the console in order to avoid induction.
Unknown Object (User) added a comment to T2659: Add fastnetmon (DDoS detection) support.
@jack9603301 can you explain snort perspectives and describe the difference between? Do you have experience with both IDS?
kroy reassigned T2654: Multiple names unable to be assigned to the same static mapping from kroy to jjakob.
Go for it. Just to confirm, this did work on the rolling from the 8th of this month, so it was something that got gobbled up in the rewrite.
In this case, it is better to consider snort as the defense and detection backend of IDS/IPS.
Unknown Object (User) updated the task description for T2659: Add fastnetmon (DDoS detection) support.
Unknown Object (User) created T2659: Add fastnetmon (DDoS detection) support.
jestabro lowered the priority of T2612: HTTPS API, changing API key fails but goes through from High to Normal.
Changing the api settings (for example: keys, port) will cause a disruptive reload of the http-api service; it will of course succeed, but the response for that set command will reflect the reloading. This is known, if misleading behaviour. I will lower this to normal priority, and consider if we can improve the error/success message.
firewall {
all-ping enable
broadcast-ping enable
config-trap disable
ipv6-receive-redirects enable
ipv6-src-route enable
ip-src-route enable
log-martians enable
name wan {
default-action drop
rule 1 {
action accept
state {
established enable
related enable
}
}
}
name wan-local {
default-action drop
rule 1 {
action accept
state {
established enable
related enable
}
}
rule 2 {
action accept
icmp {
type-name echo-request
}
protocol icmp
state {
new enable
}
}
rule 3 {
action drop
destination {
port 22
}
protocol tcp
recent {
count 4
time 60
}
state {
new enable
}
}
rule 4 {
action accept
protocol tcp
state {
new enable
}
}
}
options {
interface pppoe0 {
adjust-mss 1452
adjust-mss6 1452
}
}
receive-redirects disable
send-redirects enable
source-validation disable
state-policy {
established {
action accept
log {
enable
}
}
invalid {
action accept
log {
enable
}
}
related {
action accept
log {
enable
}
}
}
syn-cookies enable
twa-hazards-protection disable
}
interfaces {
bridge br1 {
address 192.168.0.1/24
address fc00:470:f1cd::1/64
description Services
member {
interface eth1.1 {
}
interface eth2 {
}
}
stp
}
bridge br2 {
address 192.168.101.1/24
address fc00:470:f1cd:101::1/64
description Terminal
member {
interface eth0 {
}
interface eth1.2 {
}
interface eth3 {
}
interface eth4 {
}
}
stp
}
ethernet eth0 {
description "netgear R6260 AP"
hw-id 00:98:2b:f8:3f:11
ipv6 {
address {
}
dup-addr-detect-transmits 1
}
mtu 1492
offload-options {
generic-receive on
generic-segmentation on
scatter-gather on
tcp-segmentation on
udp-fragmentation on
}
}
ethernet eth1 {
description "DELL R410(Trunk)"
hw-id 00:98:2b:f8:3f:12
mtu 1500
offload-options {
generic-receive on
generic-segmentation on
scatter-gather on
tcp-segmentation on
udp-fragmentation on
}
vif 1 {
description "vlan 1 of eth1"
mtu 1492
}
vif 2 {
description "vlan 2 of eth1"
mtu 1492
}
}
ethernet eth2 {
description LAN
hw-id 00:98:2b:f8:3f:13
mtu 1492
offload-options {
generic-receive on
generic-segmentation on
scatter-gather on
tcp-segmentation on
udp-fragmentation on
}
}
ethernet eth3 {
description LAN
hw-id 00:98:2b:f8:3f:14
mtu 1492
offload-options {
generic-receive on
generic-segmentation on
scatter-gather on
tcp-segmentation on
udp-fragmentation on
}
}
ethernet eth4 {
description "Huawei is secondary home router (Telecom special edition, switching and AP mode)"
hw-id 00:98:2b:f8:3f:15
mtu 1492
offload-options {
generic-receive on
generic-segmentation on
scatter-gather on
tcp-segmentation on
udp-fragmentation on
}
}
ethernet eth5 {
description "ISP WAN"
disable-flow-control
firewall {
in {
name wan
}
local {
name wan-local
}
}
hw-id 00:98:2b:f8:3f:16
mtu 1500
offload-options {
generic-receive on
generic-segmentation on
scatter-gather on
tcp-segmentation on
udp-fragmentation on
}
}
loopback lo {
address 127.0.0.1/8
address ::1/128
description loopback
}
pppoe pppoe0 {
authentication {
password pass
user user
}
default-route force
description ISP
dhcpv6-options {
prefix-delegation {
interface br1 {
address 101
sla-id 2
sla-len 8
}
interface br2 {
address 101
sla-id 1
sla-len 8
}
}
}
idle-timeout 30
ipv6 {
address {
autoconf
}
enable
}
mtu 1492
source-interface eth5
}
}
nat {
nptv6 {
rule 2 {
outbound-interface pppoe0
source {
prefix fc00:470:f1cd::/64
}
translation {
prefix 240e:fc:7d:b79b::/64
}
}
}
source {
rule 1 {
description PUBLIC
log
outbound-interface pppoe0
protocol all
source {
address 0.0.0.0/0
}
translation {
address masquerade
}
}
}
}
protocols {
static {
interface-route 0.0.0.0/0 {
next-hop-interface pppoe0 {
}
}
interface-route6 ::/0 {
next-hop-interface pppoe0 {
}
}
table 150 {
interface-route 0.0.0.0/0 {
next-hop-interface pppoe0 {
}
}
interface-route6 ::/0 {
next-hop-interface pppoe0 {
}
}
}
}
}
service {
dhcp-server {
shared-network-name pri101 {
description "DHCP 101"
subnet 192.168.101.0/24 {
default-router 192.168.101.1
dns-server 192.168.0.254
dns-server 192.168.101.1
dns-server 192.168.0.1
lease 86400
ntp-server 192.168.101.1
range 0 {
start 192.168.101.9
stop 192.168.101.254
}
}
}
}
dns {
forwarding {
allow-from 192.168.0.0/16
allow-from 2001:470:f1cd::/48
cache-size 1024
domain pve. {
addnta
recursion-desired
server 192.168.0.47
server 2001:470:f1cd::47
}
listen-address 0.0.0.0
listen-address ::
name-server 2001:470:f1cd::ff00
name-server 192.168.0.254
name-server 202.96.134.33
name-server 202.96.128.86
name-server 114.114.114.114
name-server 1.1.1.1
name-server 1.0.0.1
system
}
}
https {
api {
debug
keys {
id admin {
key jack960330
}
}
port 8000
}
api-restrict {
virtual-host vhost0
}
certificates {
system-generated-certificate {
lifetime 365
}
}
virtual-host vhost0 {
listen-address "*"
server-name 192.168.0.1
}
}
mdns {
repeater {
interface br1
interface br2
}
}
router-advert {
interface br1 {
default-preference high
interval {
max 600
min 10
}
name-server fc00:470:f1cd::ff00
prefix ::/64 {
}
reachable-time 0
retrans-timer 0
}
interface br2 {
default-preference high
hop-limit 60
interval {
max 600
min 10
}
name-server fc00:470:f1cd::ff00
prefix ::/64 {
}
reachable-time 0
retrans-timer 0
}
}
ssh {
listen-address 0.0.0.0
listen-address ::
}
}
system {
config-management {
commit-revisions 100
}
console {
device ttyS0 {
speed 115200
}
}
domain-name router
host-name vyos
ip {
arp {
table-size 2048
}
multipath {
layer4-hashing
}
}
ipv6 {
multipath {
layer4-hashing
}
neighbor {
table-size 2048
}
strict-dad
}
login {
user vyos {
authentication {
encrypted-password $6$UaXQViDvJ.Hr$85U/9Q5d/tc9hdtrnntMVgrztOCext..OJCHaJYZUo82GAdD95lchvSjI3vCZJTNte7cIAs87YctYlXODGXAz1
plaintext-password ""
}
}
}
ntp {
allow-clients {
address 192.168.0.0/16
address fc00:470:f1cd::/48
}
listen-address ::
listen-address 0.0.0.0
server 0.debian.pool.ntp.org {
}
server 1.debian.pool.ntp.org {
}
server 2.debian.pool.ntp.org {
}
server 3.debian.pool.ntp.org {
}
}
options {
reboot-on-panic
}
sysctl {
custom net.ipv4.conf.all.rp_filter {
value 0
}
custom net.ipv4.conf.default.rp_filter {
value 0
}
custom net.ipv4.conf.eth0.rp_filter {
value 0
}
custom net.ipv6.conf.all.accept_ra {
value 2
}
custom net.ipv6.conf.all.forwarding {
value 1
}
}
syslog {
global {
facility all {
level info
}
facility protocols {
level debug
}
}
}
time-zone Asia/Shanghai
}@elbandi could you please submit a PR?
We should make this a default option, not much functions using it and also it makes no sense to be to use the "flattened" dict as it can't be merged with a dict from `get_config_dict()
The work to perform the get_config/verify/generate/apply in python is already available in this tree:
https://github.com/thomas-mangin/vyos-1x/tree/T2522
thomas-mangin added a comment to T2656: XML: Python default dictionary returns wrong dictionary level(s).
@cpo, you can change the defaults from True to False in the patch if this is what you want to do.
thomas-mangin added a comment to T2656: XML: Python default dictionary returns wrong dictionary level(s).
i think, the squid access log doesnt go to the log/messages.
And sorry, i wasnt accurate. this is the issue: access log is in var/log/squid3/ directory not in var/log/squid/.
two file is affected: https://github.com/vyos/vyatta-webproxy/blob/current/templates-op/show/webproxy/log/node.def and https://github.com/vyos/vyatta-webproxy/blob/current/templates-op/monitor/webproxy/access-log/node.def
Maybe you mind sharing your configuration so it can be reproduced.
Will you be doing this change or can I claim it? I'm ready to work on it right now if you prefer.
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.
To clarify, I'm not actually sure the formatting is the reason for the bug - I just observed that it happened. It may have no impact on functionality. The real problem is that something is messing with the hw-id entries, and I don't think it's the migrator scripts, as those weren't executed when it happened. Maybe some legacy Vyatta code.
Looking at the code, there is a missing error check for when an alias is the same as a static-host-mapping or already existing alias (either of this mapping or any other one). It will require some additional iteration.
Or maybe these should be converted to warnings and not errors, as they don't cause anything to break, just not work as expected?
I agree, we can make the error message point the user towards using an alias instead. But I don't think doing so is common practice, such things are usually written in docs.
jjakob added a comment to T2508: Enable user to configure a LUA script that modifies resolving in PowerDNS.
Maybe the problem was that it exposed a configuration only understood by pdns-recursor, so replacing it with something else would be impossible if we ever considered so? That was the reason for not allowing certain patches in the past.
Then I believe the best course of action is to restore that error condition, but have it reference the “alias” config then.
The reason I do it this way is to comply with the 80-column limit. Any strings separated by whitespace will be transparently concatenated by Python to one string, it requires adding extra braces around the multi-line string.