Not sure I understand you correctly, but the study I linked shows that mother's earnings drop significantly after the First child. That has nothing to do with the significant monetary cost of children, which are added on top of that.
On page 43, it shows very clearly, that women who do not have children have almost no earnings gap.
Society can "fix" this in two ways:
- introduce the same penalty for fathers, so that both earn less - which would IMHO lead to even less children
- lift up families/mothers and help women not experience this gap, by having full time high quality child Care, have laws that allow mothers to take their children to Work, etc etc.
Second one is much harder to accomplish, because it costs money and time and effort.
The first one is Just forcing fathers to stay at home while mothers go back to Work.
As a father, I really can't understand how every article about this topic talks about as if fathers and mothers are just interchangeable. We are not.
Mothers carry their child for ~9 months, they give birth to that child. The bond between a mother and her freshly born child is bigger than that of the father.
Of course fathers are very important too, and yes fathers should spend more Time with their children in general.
But it's Just crazy to ask mothers to get back to work as soon as possible. Many mothers want to Work part Time, because they want to spend more time with their children. The issue is, that care work is not paid or valued nearly the same as work for money.
Also if you're feeding your young child like you are supposed to, the father simply can't feed the child, because we don't give milk.
Nearly all articles about this topic care only for how to get women back to Work instead of what's best for society and for families.
If that would be the Focus, we would talk way more about how to integrate children into the work Life and less on how to grow GDP.
ruroco DOES prevent replay attacks, by saving the deadline (which is in ns) in a blocklist. It does not matter if the deadline has "passed", the deadline is added to the blocklist as soon as the packet reaches the server and is deemed "valid". So each packet is only valid exacly ONCE
a replay attack won't work, because every UDP packet data has deadline in nanoseconds.
Once this UDP packet reaches the server the deadline will be added to the blocklist.
If an attacker sends the same packet again, the server will check its blocklist for the deadline. It does not matter if the deadline has been reached or not. once the packet reaches the server, the deadline of that packet will be added to the blocklist.
the deadline that is sent from the client is being added to the blocklist after the command was executed, so sending the same packet again will not work, because the deadline (which is in nanoseconds) is already on the blocklist and therefore the command will not be executed again.
This effectively means that replaying a packet is not possible, because the server will deny it.
the client COULD use something like https://www.ipify.org/ to get the IP, which can then be used as an additional client argument.
But if an adversary uses the SAME network, then the IP address that the server sees will be the same for the client and the adversary, so it only matters if the adversary takes the packet and sends it from a different network, which the adversary won't have to do, because they still control the network where the packet was originally sent from.
I think what rmholt means is that ruroco does not improve security in the sense, that it has stronger and safer encryption/algorithms/... but that it merely "hides" existing services.
I would argue that it does improve security in the way that it reduces the attack surface of potential vulnerable services, because they are simply not accessible for adversaries.
On the other hand, having another tool running increases the attack surface, but imho that's very small.
Thanks for the feedback and pointing out ostiary. Fixing replay attacks is on my todo list, maybe I can learn some things from how ostiary does it.
Kind advice from my PoV:
Your comment could be read as "your project is shit, there is ostiary which has replay protection and yours doesn't".
I'm sure you didn't intend for you comment to not come across that way, and I also did not read it that way, but others could have.
Also keep in mind that ruroco is a very young project and is by no means finished. I was thinking about using one-time-pads or other encryption algorithms as well. I also posted this here to get feedback to improve my project.
So hopefully when I release version 1.0.0 all the issues that this project has atpit are resolved ;)
that is correct. The configuration is not even ufw specific, you could run any command that you like. This means you could also, for example, disable or enable certain nginx configurations.
You are right, but if you are in a network that blocks every packet that is sent to any port which is not 80 or 443 your port knocking capabilities are very limited.
Ultimately reading firewall logs to do port knocking is most secure way, because - as you said - there is virtually no attack surface.
I would argue that port knocking is extremely inconvenient and does not work in every scenario. So for me it's a tradeoff between "ultimate" security and convenience.
"Maybe the OP simply hasn't yet heard about or used Wireguard."
I have, but I do not want to run a VPN solution on my private sever, for which I barely have any need. Also Wireguard, although VERY secure is still not "simple" software.
In addition there are usecases where Wireguard would not help, for example when I want to open up an http service for the current network that Im in.
I used port knocking in the description, because anyone here probably knows what port knocking is and ruroco is kind of similar to that.
Ruroco can be used for more than just keeping sshd logs clean, for example I could also enable a service other than ssh, for example a private file server that I want to get access to when I'm on my phone (although I haven't implemented an android version yet, it should be doable).
One of the reason why I wrote ruroco is, that I can run this from probably anywhere in the world, if I put the service on port 53, because thats DNS and that does not get blocked by any wifi whatsoever.
I used to use port knocking, but at some point found myself in a hotel where they blocked ALL ports, except TCP 80 and 443 (did not check UDP at the time).
My ssh port is on 80, so I can use all of my tools, even if the network I'm in blocks everything else.