Yes I'm using 1.2 series.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed Search
Jun 29 2020
Jun 29 2020
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.
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:
jjakob reopened T2654: Multiple names unable to be assigned to the same static mapping as "Needs testing".
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:
kroy updated the task description for T2654: Multiple names unable to be assigned to the same static mapping.
kroy changed the status of T2654: Multiple names unable to be assigned to the same static mapping from Open to In progress.
This PR should correct.
Jun 26 2020
Jun 26 2020
c-po added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.
Sorry - used the wrong task
c-po moved T2625: Provide generic Library for package builds from Backport Candidates to Finished on the VyOS 1.3 Equuleus board.
c-po moved T2062: Wrong dhcp-server static route subnet bytes from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.6) board.
c-po moved T1938: syslog doesn't start automatically from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.6) board.
c-po moved T2625: Provide generic Library for package builds from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.6) board.
c-po added a project to T2625: Provide generic Library for package builds: VyOS 1.2 Crux (VyOS 1.2.6).
c-po removed a project from T2625: Provide generic Library for package builds: Ready for Crux (1.2.x).
c-po changed the status of T2625: Provide generic Library for package builds from Unknown Status to Resolved.
c-po changed the status of T2653: "set interfaces" Python handler code improvements - next iteration from Open to In progress.
c-po renamed T2588: Add support for default values to the interface-definition format from Add support for default values to the interface definition format to Add support for default values to the interface-definition format.
c-po updated the task description for T2636: get_config_dict() shall always return a list on <multi/> nodes.
c-po updated the task description for T2636: get_config_dict() shall always return a list on <multi/> nodes.
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.
Migration scripts use vyos.configtree which uses libvyosconfig so it's probably a bug there.
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.
Attached are config.boot post-upgrade(migration) and config.boot pre-migration.
Notice:
- doubled hw-id lines
- missing opening and closing curly braces on lines 45, 75-77 (tag nodes)
- lines 8, 33, 35 are leaf nodes, those shouldn't have opening/closing curly braces after them
- some things are quoted, some are not
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.
Not doing anything regarding the failed load and just rebooting has now hard-baked the eth0-eth2 names into config.boot without me doing anything. So something effectively decided to rename eth1-eth3 to eth0-eth2 and save it to config.boot.
The problem was in to loop iterator when more then one address was added. This was introduced in T2635. The smoketest will be adjusted to cover this case so the issue won't reappear.
c-po changed the status of T2642: sshd fails to start due to configuration error from Open to In progress.
I checked the usage of netmap, but unfortunately I only found the equivalent configuration method of IPv4 on Wiki
Documentation commit here: GitHub fmertz/vyos-documentation/commits/system-display
Jun 25 2020
Jun 25 2020
This appears to be caused by the setting of service ssh listen-address; it appears the script generating the config is omitting the actual address. Removing a specific listening address is a temporary workaround.
Updated versions:
- libnetfilter-conntrack 1.0.8-1
- conntrack 1.4.6
nftables updated to 0.9.6 so the new nftables netmap feature can be used