Yes, I should parse the tagNode and insert them into the default data.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 30 2020
Okay, I will revise that: ... Consequently it returns None for nonsensical input and {} for non-existent paths ...
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
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.
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
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 ...
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] }
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.
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.
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
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
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):
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.
@jack9603301 can you explain snort perspectives and describe the difference between? Do you have experience with both IDS?
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.
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
@cpo, you can change the defaults from True to False in the patch if this is what you want to do.
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.
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.
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.
No, the string concatenation is done by Python (these are not multiple arguments but one argument) so there's nothing ConfigError can do. It's simply a mistake (typo) on my part.
Yeah, only the first line will be used, the subsequent lines for an already existing IP or hostname will be ignored. pdns-recursor also behaves the same, it logs "not replacing entry" (or something similar, I can't recall) when encountering a entry with a different IP for a hostname already defined, so it behaves the same as getent. You can't add multiple entries for round-robin resolution, hosts has no support for that, if we want that we need to use zone files instead (but those only work for pdns-recursor and not the system, so are not a suitable replacement here, they could be added under the dns forwarding node)
To add, maybe it's just the content of the error message that's misleading here if there other ways to do it. Or maybe the problem is that there are multiple ways to accomplish this
I guess there's two ways to approach it. This is the correct way:
Have you tested that this actually works as intended? The reason I added that check is that each static-host-mapping "inet" address translates to a line in /etc/hosts. The hosts manpage says there should be only one line for each host:
This PR should correct.
Jun 26 2020
Sorry - used the wrong task