• 1 Post
  • 35 Comments
Joined 1 year ago
cake
Cake day: December 27th, 2023

help-circle
  • Router is my own and up to date.

    that does not say its dns settings are as you set them. if you use a default or weak password for your routers config page, an attacker could change its setting from the outside via dns rebinding, then scanning your net, finding your router, trying passwords and when succesfull changing firewall rules or change dns settings to make your programs check the attackers repository proxies instead of their vendor ones.

    dns rebind: https://www.packetlabs.net/posts/what-are-dns-rebinding-attacks/

    so better check its dns settings, that it likely is pushing to dhcp clients, too.

    Thanks to flatpak it also doesn’t have the ability to see anything else from my system. it at least seems to asks for seeing way more…

    jdownloader could theoretically also got hacked by a site you were downloading from. maybe having a complete list of what you downloaded and check those again but using source provided (and signed?) hashes could reveal something fishy.

    maybe (if thats possible there) make a memory/debug dump from the process in that condition and ask the vendor to look at it.

    maybe check your downloaders binary hashes and compare it to the vendors signed ones.


  • the jackass addition was a joke from my side as it fits the j in front and the situation presented perfectly, no matter if the original app did so or if it was hijacked somehow.

    however i used to use a separate downloader a very long time ago, when downloading i.e. an iso image for a new foss os took just too long, could be interrupted by time-togo-to-bed or anything else.

    one day i learned about another downloader to be spying. at that time the downloaders in good browsers did what i needed and i turned completely away from separate downloaders as using more products always increase the attack surface and i didnt need such any longer.

    for crawling i guess there are better tools than a downloader that needs to be fed by clipboard.

    for downloading a lot of files in parallel from a list, i would personally use a quickly coded script (download link from parameters using wget or on failure append the link to a failed-list) and then use something like:

    cat list | xargs --some-parameters ./dl-script.sh

    so that i could set limits of parallel downloads using the xargs parameters while not needing any extra software and beeing able to redownload the failed ones by just renaming the lists filename and run the command again.

    wget seems to support resume too, so i’ld try it that way but i never needed to.

    if you need the resume feature or download a lot on a daily basis, want adjustable speed limits by few clicks etc. a specialized downloader application is probably a better way to go and usually has a gui if you need that, but i have no need for downloaders and thus cannot recommend any except for quick use of wget and xargs maybe ;-)

    in general however i have ‘learned’ to try to prevent the use of products of specific programming languages which i had often more problems with than with others. its perl, ruby and java programs i try to prevent to use whenever possible. but that is based on personal experience like with ruby programs often basics (like turn on logging to find the problem didnt even log a single line not even in its debug mode) that are needed to at least administrate such programs were missing, bad or unhandy like java’s log4js default log rotation was horrible to use when forwarding logs and log4j was another thing by itself. However thats personal preferece to not use programs coded in these languages. same as with not using that one os vendors programs that are always in the news since decades with every week or so yet another 100% preventable security issue ;-) i just don’t like such.








  • smb@lemmy.mltoLinux@lemmy.mlA word about systemd
    link
    fedilink
    English
    arrow-up
    1
    ·
    5 months ago

    one example of a program that did multiple things is sfdisk, it used to make the kernel reload the new partition table but that was not its main job, only changing them. the extra functionality moved to blockdev which is nearer to doing such as it also triggers flushing buffers and i think setting read/write status. i am fully ok with that change as it removes code from a program that doesn’t need it to another that already does similar things so that other partitioning programs like gdisk fdisk or parted could go the same way so that maintainers of the reread-partition-table things can concentrate on one solution at one place (in userspace) instead of opening issues at an unknown number of projects that also alter partitioning. the “do one thing” paradigma is good for developers who maintain the code and i pretty much appreciate their work. if you are up to only want one-day-flies that either die or take huge amounts of resources only for keeping them alive (image of a mayfly in an emergency room and a heart-lung machine attached while chirurgs rushing around trying to enlenghten its life a few seconds more) then you are good with monolithic tools that could hardly be maintained and suck allday as no one wants to fix any bugs or cannot without creating new ones due to the tightened dependency hell it has internally.

    the point is not a lack of examples doing wrong but where one wants to be heading towards.


  • smb@lemmy.mltoLinux@lemmy.mlA word about systemd
    link
    fedilink
    English
    arrow-up
    4
    ·
    5 months ago

    Lol what???

    wouldn’t that be the definition of stable?

    the computer on voyager 2 is running for 47 years now, they might have rebooted some parts meanwhile but overall its a long time now, and if the program is free of bugs the time that program can run only depends on the durability of the hardware, protection from cosmic rays (which were afaik the problems the voyager probes faced mostly, not bugs) which could be quite long if protected from hazardous environments and maybe using optoelectronics but the point is that a bug free software can run forever only depending on hardware durability and energy supply, in any other way no humans are needed for a veery long time ;-)


  • smb@lemmy.mltoLinux@lemmy.mlA word about systemd
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    2
    ·
    5 months ago

    However, systemd makes the system much more secure and reliable as it is

    less secure and less reliable day-by-day you meant? systemd introduces needless dependencies ever since as if that was it sole intention ever from its very beginning, which already were used for wide attacks, and exactly those attacks that the people working hard to remove unneeded dependencies for security reasons meant to prevent by things like “do one thing only” (but security was not the number 1 reason for this one i think), systemd instead: ‘lets add another level of that exponential dependency tree from the insecurity hell’ felt like they did this stupid thing intentionally every month for a decade or more.

    and stability… if you don’t monitor what systemd does, you’ll never know how bad it actually is. i’ve made custom scripts to monitor systemd’s failures (failing in doing a very primitive of its job) and there are hundreds (actually varying around 200 to 300 sometimes more) of such per day on all our systems for one particular(!) measurement only that was breaking service stability and i wrote a measure-and-fix+monitor workaround. other fixes were not monitored however, only silently fixed by workarounds, thus just unnumbered systemd bugs/instabilities in the dark that stole a lot of work capacity…

    if you run distros with systemd, unreliability is your daily experience unless you don’t really care or have never experienced stability before - like running a service (a single process) for 8 years without any interruption then it suddenly stops and you go like “was it maybe an attack? the process died, how could that be? were there any connects from outside at that moment?” not talking about not updating something that long, but “stability” itself CAN be like if you dont stop it, it’ll still run in 10000+ years maybe millions, more likely that humans extincted themselves way earlier than of a process “just dying” by a bug… while systemd even randomly stops things that were running well for no reason (varying) once a month more or less (also varying in what it actually randomly stops, sometimes (2 times) it even stopped ssh on my servers, me asking myself if i should create yet another workaround for systemds buggyness to not locking me out again from network or ratjer go for the real solution for most* of all systemd problems - *see below) on the few standard installs i personally have as i didn’t have the way to automatically replace provider installed distro on VMs in the DC. i want this replacing automatically for the same reason why i don’t like systemd, it causes manual work for a thing that should go automated. however due to systemd’s perpetuated instability i now managed to have this way, and every second working on getting rid of systemd is worth it 100k times. this however does not solve all systemd-introduced problems as the xz attack showed (a systemd-dependency on xz made the infected xz library beeing useful-for-the-atracker during compiletime of sshd binary with which then the attacker could infect the newly built sshd binary),one could still be attacked through systemd’s dependency hell even if one does not use systemd by oneself, but the build machines used for your distro could be affected/infected by systemd’s needless dependencies when “also” compiling for systemd-affected distributions thus there is the risk of becoming a victim of needless-systemd-dependencies while not using systemd at all. however the attack through systemd dependency (and that the public solution was not the removal of needless dependencies only included as source for superflous third party “needs”) made clear that systemd is an overall problem for security that will not be solved quickly but stay just like all windows insecurities will stay as long as they whish to push them to their “users”.

    systemd reducing overall security and its unreliability combined with some builtin impediments (i.e. when debugging its defects) is what drove me away from systemd. there are solutions way more stable and way more secure (and way better documented btw) that do not call in for needless dependencies, reducing risks, attack vectors and increases overall debuggability i.e. by deterministic behaviour as an easy example. and none of its important (to me) promises have been fulfilled yet by systemd, drop-in-replacement? have heared that lie thousands of times, but in the last decade i have not experienced it a single time in a distro and it does not seem to be included/finished any more.

    for windows users or windows admins a linux with systemd on it IS an improvement in stability, security and of course for updating, yes. but all of that does not come from systemd, rather the opposite is the case, systemd reduces it month by month, thats my experience and thats the most important experience for me, idc what lies whitdepapers tell or what broken promises are believed by anyone or the masses, i want secure and stable servers and services and systemd does not fit in for any of these goals and the time it was still “young” and early problems could be accepted in the hope they get fixed soon are gone, but without those fixes having ever appeared.






  • smb@lemmy.mlto196@lemmy.blahaj.zoneLegitimately ugly rule
    link
    fedilink
    English
    arrow-up
    6
    ·
    7 months ago

    i think its also a very good symbol of how the US just forgets about even their very own laws at a snap of a finger and that no nation in the world (not even the us itself) can ever trust them with anything. like for example the so called freedom of religion when we’re at the Sioux Blackbhills anyway.


  • you should definitely know what type of authentication you use (my opinion) !! the agent can hold the key forever, so if you are just not asked again when connecting once more, thats what the agent is for. however its only in ram, so stopping the process or rebooting ends that of course. if you didn’t reboot meanwhile maybe try unload all keys from it (ssh-add -D, ssh-add -L) and see what the next login is like.

    btw: i use ControlMaster /ControlPath (with timeouts) to even reduce the number of passwordless logins and speed things up when running scripts or things like ansible, monitoring via ssh etc. then everything goes through the already open channel and no authentication is needed for the second thing any more, it gets really fast then.



  • The whole point of ssh-agent is to remember your passphrase.

    replace passphrase with private key and you’re very correct.

    passphrases used to login to servers using PasswordAuthentication are not stored in the agent. i might be wrong with technical details on how the private key is actually stored in RAM by the agent, but in the context of ssh passphrases that could be directly used for login to servers, saying the agent stores passphrases is at least a bit misleading.

    what you want is:

    • use Key authentication, not passwords
    • disable passwordauthentication on the server when you have setup and secured (some sort of backup) ssh access with keys instead of passwords.
    • if you always want to provide a short password for login, then don’t use an agent, i.e. unset that environment variable and check ssh_config
    • give your private key a password that fits your needs (average time it shoulf take attackers to guess that password vs your time you need overall to exchange the pubkey on all your servers)
    • change the privatekey every time immediately after someone might have had access to the password protected privkey file
    • do not give others access to your account on your pc to not have to change your private key too often.

    also an idea:

    • use a token that stores the private key AND is PIN protected as in it would lock itself upon a few tries with a wrong pin. this way the “password” needed to enter for logins can be minimal while at the same time protecting the private key from beeing copied. but even then one should not let others have access to the same machine (of course not as root) or account (as user, but better not at all) as an unlocked token could also possibly be used to place a second attacker provided key on the server you wanted to protect.

    all depends on the level of security you want to achieve. additional TOTP could improve security too (but beware that some authenticator providers might have “sharing” features which could compromise the TOTP token even before its first use.


  • My theory is that you already have something providing ssh agent service

    in the past some xserver environments started an ssh-agent for you just in case of, and for some reason i don’t remember that was annoying and i disabled it to start my agent in my shell environment as i wanted it.

    also a possibility is tharlt there are other agents like the gpg-agent that afaik also handles ssh keys.

    but i would also look into $HOME/.ssh/config if there was something configured that matches the hostname, ip, or with wildcards* parts of it, that could interfere with key selection as the .ssh/id_rsa key should IMHO always be tried if key auth is possible and no (matching) key is known to the ssh process, that is unless there already is something configured…

    not sure if a system-wide /etc/ssh/ssh_config would interfere there too, maybe have a look there too. as this behaviour seems a bit unexpected if not configured specially to do so.


  • smb@lemmy.mltoAsklemmy@lemmy.mlWhat's your favourite country and why?
    link
    fedilink
    English
    arrow-up
    48
    arrow-down
    2
    ·
    7 months ago

    antarctica:

    • no bad politics
    • no wars so far
    • people there are mainly interested in science
    • no economic abuse or exploitation
    • pinguins!
    • no air conditioning needed to survive the summer.
    • winter is offline time, visitors won’t arrive or leave then.
    • last place to stay cool during boomers heritage “heat death of our planet”

    well sure, it has downsides too. Next Rollercoaster park is -tbh- unreachable, internet connection is sloo.oo…oow (or did they already finish the submarine fibre cable?) and sunbathing basically only brings you frost bites (if you’re lucky).

    However i am not planning to migrate there.