<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Security on Jaymin Patel</title><link>https://jayminpatel.elemprin.com/tags/security/</link><description>Recent content in Security on Jaymin Patel</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 22 Aug 2022 00:00:00 +0530</lastBuildDate><atom:link href="https://jayminpatel.elemprin.com/tags/security/index.xml" rel="self" type="application/rss+xml"/><item><title>IPSec VPN on OpenWrt: From Config Files to UCI</title><link>https://jayminpatel.elemprin.com/posts/2022-08-22-libreswan-ipsec-uci/</link><pubDate>Mon, 22 Aug 2022 00:00:00 +0530</pubDate><guid>https://jayminpatel.elemprin.com/posts/2022-08-22-libreswan-ipsec-uci/</guid><description>&lt;p>Setting up an IPSec VPN on OpenWrt used to mean editing &lt;code>/etc/ipsec.conf&lt;/code> by hand -- tracking down the right parameters for your topology, debugging misconfigured secrets, and restarting the service after every change. For site-to-site tunnels between branch offices, or road-warrior access for remote employees, the manual approach worked but didn't scale.&lt;/p>
&lt;p>Libreswan, the IPSec implementation used in OpenWrt, is a battle-tested VPN stack. But until now, it lacked the configuration layer that makes OpenWrt's ecosystem so powerful: UCI (Unified Configuration Interface). With UCI support, Libreswan joins the rest of OpenWrt's services -- configurable through a consistent interface, scriptable for automation, and manageable at scale.&lt;/p></description></item><item><title>Persistent SSH Tunnels with Autossh and UCI on OpenWrt</title><link>https://jayminpatel.elemprin.com/posts/2022-07-04-autossh-uci-procd/</link><pubDate>Mon, 04 Jul 2022 00:00:00 +0530</pubDate><guid>https://jayminpatel.elemprin.com/posts/2022-07-04-autossh-uci-procd/</guid><description>&lt;p>SSH tunnels are the Swiss Army knife of network connectivity. Need to access a device behind NAT? Reverse tunnel. Want to secure traffic over an untrusted network? Local forward. Managing remote routers from a central jump host? Multiple tunnels, multiple ports.&lt;/p>
&lt;p>The problem with SSH tunnels is that they die. Network blips, ISP maintenance, DHCP lease renewals -- any interruption kills the connection and the tunnel goes down. Manually SSH-ing back into a remote router to re-establish tunnels doesn't scale past a handful of devices.&lt;/p></description></item><item><title>Allow Normal User to su Without Password</title><link>https://jayminpatel.elemprin.com/posts/2010-05-16-su-without-password/</link><pubDate>Sun, 16 May 2010 11:45:00 +0530</pubDate><guid>https://jayminpatel.elemprin.com/posts/2010-05-16-su-without-password/</guid><description>&lt;p>All Unix and Linux system will ship with different default policies. Usually these policies don't match the local policies, such as which users are allowed what kind of access to which resources and when. In addition security policies may require non-default authentication and/or logging.&lt;/p>
&lt;p>A system administrator must examine the system's configuration files and update them if necessary to enforce local policies. On modern systems PAM (Pluggable Authentication Modules) can be used to configure a wide range of security policies, including which databases to use to authenticate users, minimum password length, max login attempts, special permissions for console users (to various commands and devices), and many other policies.&lt;/p></description></item><item><title>Sulogin for Single User Mode</title><link>https://jayminpatel.elemprin.com/posts/2010-05-16-sulogin-single-user/</link><pubDate>Sun, 16 May 2010 11:36:00 +0530</pubDate><guid>https://jayminpatel.elemprin.com/posts/2010-05-16-sulogin-single-user/</guid><description>&lt;p>By default on Red Hat Linux, user can enter single user mode simply by typing &amp;quot;linux single&amp;quot; at the GRUB boot-editing menu. Some believe that this is left in to ease support of users with lost root passwords.&lt;/p>
&lt;p>In any case, it represents a clear security risk - authentication should always be required for root level access. It should be noted that it is extremely difficult to prevent compromise by any attacker who has knowledge, tools, and full physical access to a system. This kind of measure simply increases the difficulty of compromise by requiring more of each of these factors. These last two items have attempted to address concerns of physical/boot security.&lt;/p></description></item></channel></rss>