Soa Technology

Good news! Amazon India announces 20,000 seasonal jobs in customer service

Amazon India on Sunday said that it has opened close to 20,000 seasonal employment opportunities in its customer service organisation. Most of the positions are part of the firm’s virtual customer service programme that provides work from home options.

The new positions are open across 11 locations including Kolkata, Pune and Hyderabad.

The announcement comes a little over a month after Amazon created nearly 50,000 temporary job opportunities in the country across its fulfilment and delivery networks.

As coronavirus cases are surging in the country, consumers are increasingly resorting to online shopping to meet their consumption needs. After e-commerce firms resumed full operations in the country, companies registered a spike in consumer search for products like electronic items, home appliances, casual wear and other work-from-home enablers.

Launch of sale events by online firms may be an indicator of significant consumer demand. Amazon recently concluded a seven-day sale.

The creation of the fresh job roles come amidst expectations of a continued rise in demand going forward.

“We estimate that customer traffic will further scale up over the next six months with the onset of Indian and global holiday seasons,” said Akshay Prabhu, director at customer service, Amazon India.

Based on the candidates’ performance as well as business needs, a percentage of the present temporary positions are likely to be converted into permanent positions towards the end of the year, the company said.

Earlier this year, Jeff Bezos-led Amazon had announced that it plans to create 1 million new jobs in India by 2025 through continued investments in technology, infrastructure and its logistics network. Amazon’s investments have enabled nearly 700,000 jobs over the past seven years in India.

DNSSEC – What Is It and Why Is It Important?

A brief description of how DNS works

To understand Domain Name System Security Extensions (DNSSEC), it helps to have a basic understanding of the Domain Name System (DNS).

The proper functioning of the Internet is critically dependent on the DNS . Every web page visited, every email sent, every picture retrieved from a social media: all those interactions use the DNS to translate human-friendly domain names (such as icann.org) to the IP addresses (such as 192.0.43.7 and 2001:500:88:200::7) needed by servers, routers, and other network devices to route traffic across the Internet to the proper destination.

Using the Internet on any device starts with the DNS. For example, consider when a user enters a web site name in a browser on their phone. The browser uses the stub resolver, which is part of the device’s operating system, to begin the process of translating the web site’s domain name into an Internet Protocol (IP) address. A stub resolver is a very simple DNS client that relays an application’s request for DNS data to a more complicated DNS client called a recursive resolver. Many network operators run recursive resolvers to handle DNS requests, or queries, sent by devices on their network. (Smaller operators and organizations sometimes use recursive resolvers on other networks, including recursive resolvers operated as a service for the public, such as Google Public DNS, OpenDNS, and Quad9.)

The recursive resolver tracks down, or resolves, the answer to the DNS query sent by the stub resolver. This resolution process requires the recursive resolver to send its own DNS queries, usually to multiple different authoritative name servers. The DNS data for every domain name is stored on an authoritative name server somewhere on the Internet. DNS data for a domain is called a zone. Some organizations operate their own name servers to publish their zones, but usually organizations outsource this function to third parties. There are different types of organizations that host DNS zones on behalf of others, including registrars, registries, web hosting companies, network server providers, just to name a few.

DNS by itself is not secure

DNS was designed in the 1980s when the Internet was much smaller, and security was not a primary consideration in its design. As a result, when a recursive resolver sends a query to an authoritative name server, the resolver has no way to verify the authenticity of the response. The resolver can only check that a response appears to come from the same IP address where the resolver sent the original query. But relying on the source IP address of a response is not a strong authentication mechanism, since the source IP address of a DNS response packet can be easily forged, or spoofed. As DNS was originally designed, a resolver cannot easily detect a forged response to one of its queries. An attacker can easily masquerade as the authoritative server that a resolver originally queried by spoofing a response that appears to come from that authoritative server. In other words an attacker can redirect a user to a potentially malicious site without the user realizing it.

Recursive resolvers cache the DNS data they receive from authoritative name servers to speed up the resolution process. If a stub resolver asks for DNS data that the recursive resolver has in its cache, the recursive resolver can answer immediately without the delay introduced by first querying one or more authoritative servers. This reliance on caching has a downside, however: if an attacker sends a forged DNS response that is accepted by a recursive resolver, the attacker has poisoned the cache of the recursive resolver. The resolver will then proceed to return the fraudulent DNS data to other devices that query for it.

As an example of the threat posed by a cache-poisoning attack, consider what happens when a user visits their bank’s website. The user’s device queries its configured recursive name server for the bank web site’s IP address. But an attacker could have poisoned the resolver with an IP address that points not to the legitimate site but to a web site created by the attacker. This fraudulent website impersonates the bank website and looks just the same. The unknowing user would enter their name and password, as usual. Unfortunately, the user has inadvertently provided its banking credentials to the attacker, who could then log in as that user at the legitimate bank web site to transfer funds or take other unauthorized actions.

The DNS Security Extensions (DNSSEC)

Engineers in the Internet Engineering Task Force (IETF), the organization responsible for the DNS protocol standards, long realized the lack of stronger authentication in DNS was a problem. Work on a solution began in the 1990s and the result was the DNSSEC Security Extensions (DNSSEC).

DNSSEC strengthens authentication in DNS using digital signatures based on public key cryptography. With DNSSEC, it’s not DNS queries and responses themselves that are cryptographically signed, but rather DNS data itself is signed by the owner of the data.

Every DNS zone has a public/private key pair. The zone owner uses the zone’s private key to sign DNS data in the zone and generate digital signatures over that data. As the name “private key” implies, this key material is kept secret by the zone owner. The zone’s public key, however, is published in the zone itself for anyone to retrieve. Any recursive resolver that looks up data in the zone also retrieves the zone’s public key, which it uses to validate the authenticity of the DNS data. The resolver confirms that the digital signature over the DNS data it retrieved is valid. If so, the DNS data is legitimate and is returned to the user. If the signature does not validate, the resolver assumes an attack, discards the data, and returns an error to the user.

DNSSEC adds two important features to the DNS protocol:

  • Data origin authentication allows a resolver to cryptographically verify that the data it received actually came from the zone where it believes the data originated.
  • Data integrity protection allows the resolver to know that the data hasn’t been modified in transit since it was originally signed by the zone owner with the zone’s private key.

Trusting DNSSEC keys

Every zone publishes its public key, which a recursive resolver retrieves to validate data in the zone. But how can a resolver ensure that a zone’s public key itself is authentic? A zone’s public key is signed, just like the other data in the zone. However, the public key is not signed by the zone’s private key, but by the parent zone’s private key. For example, the icann.org zone’s public key is signed by the org zone. Just as a DNS zone’s parent is responsible for publishing a child zone’s list of authoritative name servers, a zone’s parent is also responsible for vouching for the authenticity of its child zone’s public key. Every zone’s public key is signed by its parent zone, except for the root zone: it has no parent to sign its key.

The root zone’s public key is therefore an important starting point for validating DNS data. If a resolver trusts the root zone’s public key, it can trust the public keys of top-level zones signed by the root’s private key, such as the public key for the org zone. And because the resolver can trust the public key for the org zone, it can trust public keys that have been signed by their respective private key, such as the public key for icann.org. (In actual practice, the parent zone doesn’t sign the child zone’s key directly–the actual mechanism is more complicated–but the effect is the same as if the parent had signed the child’s key.)

The sequence of cryptographic keys signing other cryptographic keys is called a chain of trust. The public key at the beginning of a chain of trust is a called a trust anchor. A resolver has a list of trust anchors, which are public keys for different zones that the resolver trusts implicitly. Most resolvers are configured with just one trust anchor: the public key for the root zone. By trusting this key at the top of the DNS hierarchy, a resolve can build a chain of trust to any location in the DNS name space, as long as every zone in the path is signed.

Validating and Signing with DNSSEC

In order for the Internet to have widespread security, DNSSEC needs to be widely deployed. DNSSEC is not automatic: right now it needs to be specifically enabled by network operators at their recursive resolvers and also by domain name owners at their zone’s authoritative servers. The operators of resolvers and of authoritative servers have different incentives to turn on DNSSEC for their systems, but when they do, more users are assured of getting authenticated answers to their DNS queries. Quite simply, a user can have assurance that they are going to end up at their desired online destination.

Enabling DNSSEC validation in recursive resolvers is easy. In fact, it has been supported by nearly all common resolvers for many years. Turning it on involves changing just a few lines in the resolver’s configuration file. From that point forward, when a user asks the resolver for DNS information that comes from zones that are signed, and that data has been tampered with, the user will (purposely) get no data back. DNSSEC protects the user from getting bad data from a signed zone by detecting the attack and preventing the user from receiving the tampered data.

Signing zones with DNSSEC takes a few steps, but there are millions of zones that sign their DNS information so that users of validating resolvers can be assured of getting good data. Almost all common authoritative name server software supports signing zones, and many third-party DNS hosting providers also support DNSSEC. Usually, enabling DNSSEC for a zone with a hosting provider is quite easy: often it entails little more than clicking a check box.

For a zone owner to deploy DNSSEC by signing their zone’s data, that zone’s parent, and its parent, all the way to the root zone, also need to be signed for DNSSEC to be as effective as possible. A continuous chain of signed zones starting at the root zone allows a resolver to build a chain of trust from the root zone to validate data. For example, to effectively deploy DNSSEC in the icann.org zone, the org zone needs to be signed as well as the root zone. Fortunately, the DNS root zone has been signed since 2010, and all gTLDs and many ccTLDs are also signed.

There is one more step to complete DNSSEC deployment in a zone: the newly signed zone’s public key material needs to be sent to the zone’s parent. As described earlier, the parent zone signs the child zone’s public key, and allows a chain of trust to be built from parent to child.

Today the zone owner usually needs to communicate the zone’s public key material to the parent manually. In most cases, that communication happens through the zone owner’s registrar. Just as a zone owner interacts with its registrar to make other changes to a zone, such as the list of the zone’s authoritative name servers, the zone owner also interacts with the registrar to update the zone’s public key material. While this process is currently manual, recently developed protocols are expected to allow this process to be automated in the future.

The next steps for DNSSEC

As DNSSEC deployment grows, the DNS can become a foundation for other protocols that require a way to store data securely. New protocols have been developed that rely on DNSSEC and thus only work in zones that are signed. For example, DNS-based Authentication of Named Entities (DANE) allows the publication of Transport Layer Security (TLS) keys in zones for applications such as mail transport. DANE provides a way to verify the authenticity of public keys that does not rely on certificate authorities. New ways of adding privacy to DNS queries will be able to use DANE in the future, as well.

In 2018, ICANN changed the trust anchor for the DNS root for the first time. Many lessons were learned about DNSSEC during that process. Furthermore, many resolver operators became more aware of DNSSEC and turned on validation, and the world got to more clearly see how the entire DNSSEC system worked. In the coming years, ICANN hopes to see greater adoption of DNSSEC, both by resolver operators and zone owners. This would mean that more users everywhere could benefit from DNSSEC’s strong cryptographic assurance that they are getting authentic DNS answers to their queries.

How to Use Wget in Ubuntu

The wget command allows you to download files from the Internet using a Linux operating system such as Ubuntu. Use this command to download either a single Web page or a complete copy of your company’s website. It also includes an option for downloading any external links included on the site. The command recreates the complete directory structure of the site downloaded on your computer’s hard drive, and you can store the local copy as a backup or use it for testing purposes.

1

Click on the “Search” button in the Ubuntu launcher bar, type “terminal,” then double-click “Terminal” to open the application.

2

Type the following command to install the package, if it is not currently installed:

sudo apt-get install wget

Type your password when prompted.

3

Type the following command to download a single page from the website:

wget http://www.example.com/filename

Replace “www.example.com” with the name of the site you want to download, and replace “filename” with the name of the file you want to download.

4

Type the following command to download an entire website:

wget -r http://www.example.com

5

Type the following command to download the entire website and any external links:

wget -r -H http://www.example.com

How to create sitemap in WordPress without plugin

HTML sitemap designed for Users, where user can easily view all links, pages category of the site. to create HTML sitemap for your WordPress website. follow below steps.

Step 1: Open functons.php file from theme

In First step you have to do is open your currently active theme from wp-content/theme folder. In that folder you will see many php pages. like header.php, footer.php, functions.php etc. So open functions.php file in your text editior.

step 2: Download below code and paste into functions.php

You can download source code from Github and paste into functions.php add_shortcode(‘sitemap’, ‘html_sitemap’); add_shortcode() is WordPress built-in function for shortcode tag. This function requires two parameter first your shortcode and second name of your php function during execution. you can use your shortcode on page or post like [your_shortcode_name].

Step 3: Add new page from wp-admin

Now in the last step we have to do is create new page form your wp-admin panel and Give appropriate name. In this tutorial am giving page name sitemap and paste shortcode [sitemaps] and save.

Now your site is ready with Dynamic HTML Sitemap. Whenever there is new page or post published, the link of that post/page will automatically listed in sitemap.

How to create XML Sitemap

XML Sitemap generally designed for search engines to crawling and indexing our web pages and to do that first we have to create XML sitemap and we have to submit our XML sitemap to Webmaster Tool. Follow below steps to create XML sitemap.

Step 1: Open functons.php file from theme

In first step again we have to open functions.php file in your text editor from your theme folder (wp-content/themes/your_theme_folder/functions.php).

Step 2: Download below code and paste into functions.php file

Just download and copy-paste code into your functions.php file.

add_action(“publish_post”, “XML_sitemap”); add_action(“publish_page”, “XML_sitemap”);

In downloaded file, you will see above 2 lines in that file. Here, add_action() hooks or call on a specific action. This function takes two parameter, first is the name of the action and second parameter is the name of function you wish to be hook.

For e.g : In above code we pass first parameter publish_post. So whenever you will publish your new post at that time WordPress will call a custom php function XML_sitemap which we passed as second parameter to hook.

Now new page or post published on your site, this code will clear older content and write new content in existing file. Check your sitemap by www.mydomain.com/sitemap.xml, you will see updated XML sitemap of your site.

WRITTEN BY

Rohit Gilbile

google analytics showing real time user 79 but actually not in real why

The “cid” in your http call is the client id, where client refers to the device or program that makes the request. It is usually stored in a cookie (on the web) or generated by an SDK (in an app) and is used to unify subsequent requests from the same device into sessions. Since it is set by the client it differs from device to device (and browser to browser), so it can not be used to identify a person across multiple devices.

After it became the rule that any given person might have two or more devices Google came up with the uid, the user id (which by their own TOS might not identify the user, so this is a bit of a misnomer; think “cross device tracking id” and the concept becomes clearer). The uid is set by serverside code, i.e. after the user logs in. Not only this allows to unify visits from multiple devices into distinct users, it also alleviates privacy concerns (since it is supposed to be only created after a users action; there are separate TOS which you have to accept if you create a user id view in the GA interface, and they stipulate that you have to secure the users agreement to use to user id feature).

So if you set the same user id in your code the sessions will be attributed to the same user, even when the cid differs; this is by design and is indeed the point of the uid.

how to copy data from godaddy to aws instance

How to migrate Files from Godaddy to AWS

Pretend Domain is laughingadda.com on Godaddy.

  • Login to your GoDaddy account and access cpanel, go to File Manager.
  • Compress your website files (all your files in public_html folder). Now, your filename is example.com.zip
  • Connect to your AWS SSH via Putty or any command terminal. Go to the folder of your website using the following command cd /var/www/
  • wget http://example.com/laughingadda.com.zip command is to get that zip file to your AWS /var/www/ folder.
  • unzip laughingadda.com.zip to unzip all your website files into /var/www/ folder.

To transfer your hosting, you have to do it manually:
1) Set up the EC2 instance with the same environment that is on GoDaddy
2) If you have databases in Godaddy, you need to install the same database type on an RDS instance
and make sure that your VPC is properly setup to allow the EC2 instance to securely talk to the RDS instance.
3) Make sure that you have an elastic IP mapped to your EC2 so that you can access your webpage from internet
3) Export your website files and databases (if any)
4) Import the website files to EC2 using an FTP client
5) Import your database tables using a client like MySQL workbench
6) Test your website from a browser (using the elastic IP)
7) Use Route 53 to transfer your domain and map it to the elastic IP in the DNS settings
8) Test your website from a browser (using your domain)

Upgrade PHP version 7.2 to 7.3 on Ubuntu

As a part of increasing the security, it is advised to keep your PHP version up to date. Here we have provided the steps to upgrade the current PHP 7.2 version to 7.3 on Ubuntu 14/16/18 versions without removing the old one. So that we can revert to the older versions if something incompatible with the new one after switching.

Login to the server via SSH as root.

Check your current PHP version. 

# php -v
PHP 7.2.36

In order to install PHP 7.3, we need to add the repository first:

# add-apt-repository ppa:ondrej/php

Then run an update:

# apt-get update

After completing the update, we need to install the PHP 7.3.

 Then install the required PHP packages based on your current installation:

# apt install php7.3-common php7.3-cli php7.3-bz2 php7.3-curl php7.3-gd php7.3-intl php7.3-json php7.3-readline php7.3-xml php7.3-zip php7.3-fpm php7.3-bcmath php7.3-mbstring

After a successful installation, we can disable the old 7.2 and then enable 7.3:

# a2dismod php7.2
# a2enmod php7.3

Then restart Apache:

# service apache2 restart

The new PHP version should be active now. You can verify it from the command line:

# php -v
PHP 7.3.28

NOTE: for ordinary user use sudo command.

How To List and Delete Iptables Firewall Rules

Introduction

Iptables is a firewall that plays an essential role in network security for most Linux systems. While many iptables tutorials will teach you how to create firewall rules to secure your server, this one will focus on a different aspect of firewall management: listing and deleting rules.

In this tutorial, we will cover how to do the following iptables tasks:

  • List rules
  • Clear Packet and Byte Counters
  • Delete rules
  • Flush chains (delete all rules in a chain)
  • Flush all chains and tables, delete all chains, and accept all traffic

List Rules by Specification

To list out all of the active iptables rules by specification, run the iptables command with the -S option:

sudo iptables -S
Example: Rule Specification Listing-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N ICMP
-N TCP
-N UDP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A TCP -p tcp -m tcp --dport 22 -j ACCEPT

As you can see, the output looks just like the commands that were used to create them, without the preceding iptables command. This will also look similar to the iptables rules configuration files, if you’ve ever used iptables-persistent or iptables save.

List Specific Chain

If you want to limit the output to a specific chain (INPUTOUTPUTTCP, etc.), you can specify the chain name directly after the -S option. For example, to show all of the rule specifications in the TCP chain, you would run this command:

sudo iptables -S TCP
Example: TCP Chain Rule Specification Listing-N TCP
-A TCP -p tcp -m tcp --dport 22 -j ACCEPT

Let’s take a look at the alternative way to view the active iptables rules, as a table of rules.

List Rules as Tables

Listing the iptables rules in the table view can be useful for comparing different rules against each other,

To output all of the active iptables rules in a table, run the iptables command with the -L option:

sudo iptables -L

This will output all of current rules sorted by chain.

If you want to limit the output to a specific chain (INPUTOUTPUTTCP, etc.), you can specify the chain name directly after the -L option.

Let’s take a look at an example INPUT chain:

sudo iptables -L INPUT
Example: Input Chain Rule Table ListingChain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere             ctstate INVALID
UDP        udp  --  anywhere             anywhere             ctstate NEW
TCP        tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN ctstate NEW
ICMP       icmp --  anywhere             anywhere             ctstate NEW
REJECT     udp  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     tcp  --  anywhere             anywhere             reject-with tcp-reset
REJECT     all  --  anywhere             anywhere             reject-with icmp-proto-unreachable

The first line of output indicates the chain name (INPUT, in this case), followed by its default policy (DROP). The next line consists of the headers of each column in the table, and is followed by the chain’s rules. Let’s go over what each header indicates:

  • target: If a packet matches the rule, the target specifies what should be done with it. For example, a packet can be accepted, dropped, logged, or sent to another chain to be compared against more rules
  • prot: The protocol, such as tcpudpicmp, or all
  • opt: Rarely used, this column indicates IP options
  • source: The source IP address or subnet of the traffic, or anywhere
  • destination: The destination IP address or subnet of the traffic, or anywhere

The last column, which is not labeled, indicates the options of a rule. That is, any part of the rule that isn’t indicated by the previous columns. This could be anything from source and destination ports, to the connection state of the packet.

Show Packet Counts and Aggregate Size

When listing iptables rules, it is also possible to show the number of packets, and the aggregate size of the packets in bytes, that matched each particular rule. This is often useful when trying to get a rough idea of which rules are matching against packets. To do so, simply use the -L and -v option together.

For example, let’s look at the INPUT chain again, with the -v option:

sudo iptables -L INPUT -v
Example: Verbose ListingChain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 284K   42M ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
    0     0 DROP       all  --  any    any     anywhere             anywhere             ctstate INVALID
  396 63275 UDP        udp  --  any    any     anywhere             anywhere             ctstate NEW
17067 1005K TCP        tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN ctstate NEW
 2410  154K ICMP       icmp --  any    any     anywhere             anywhere             ctstate NEW
  396 63275 REJECT     udp  --  any    any     anywhere             anywhere             reject-with icmp-port-unreachable
 2916  179K REJECT     all  --  any    any     anywhere             anywhere             reject-with icmp-proto-unreachable
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:ssh ctstate NEW,ESTABLISHED

Note that the listing now has two additional columns, pkts and bytes.

Now that you know how to list the active firewall rules in a variety of ways, let’s look at how you can reset the packet and byte counters.

Reset Packet Counts and Aggregate Size

If you want to clear, or zero, the packet and byte counters for your rules, use the -Z option. They also reset if a reboot occurs. This is useful if you want to see if your server is receiving new traffic that matches your existing rules.

To clear the counters for all chains and rules, use the -Z option by itself:

sudo iptables -Z

To clear the counters for all rules in a specific chain, use the -Z option and specify the chain. For example, to clear the INPUT chain counters run this command:

sudo iptables -Z INPUT

If you want to clear the counters for a specific rule, specify the chain name and the rule number. For example, to zero the counters for the 1st rule in the INPUT chain, run this:

sudo iptables -Z INPUT 1

Now that you know how to reset the iptables packet and byte counters, let’s look at the two methods that can be used to delete them.

Delete Rule by Specification

One of the ways to delete iptables rules is by rule specification. To do so, you can run the iptables command with the -D option followed by the rule specification. If you want to delete rules using this method, you can use the output of the rules list, iptables -S, for some help.

For example, if you want to delete the rule that drops invalid incoming packets (-A INPUT -m conntrack --ctstate INVALID -j DROP), you could run this command:

sudo iptables -D INPUT -m conntrack --ctstate INVALID -j DROP

Note that the -A option, which is used to indicate the rule position at creation time, should be excluded here.

Delete Rule by Chain and Number

The other way to delete iptables rules is by its chain and line number. To determine a rule’s line number, list the rules in the table format and add the --line-numbers option:

sudo iptables -L --line-numbers
[secondary_output Example Output: Rules with Line Numbers]
Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
2    ACCEPT     all  --  anywhere             anywhere
3    DROP       all  --  anywhere             anywhere             ctstate INVALID
4    UDP        udp  --  anywhere             anywhere             ctstate NEW
5    TCP        tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN ctstate NEW
6    ICMP       icmp --  anywhere             anywhere             ctstate NEW
7    REJECT     udp  --  anywhere             anywhere             reject-with icmp-port-unreachable
8    REJECT     tcp  --  anywhere             anywhere             reject-with tcp-reset
9    REJECT     all  --  anywhere             anywhere             reject-with icmp-proto-unreachable
10   ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh ctstate NEW,ESTABLISHED
...

This adds the line number to each rule row, indicated by the num header.

Once you know which rule you want to delete, note the chain and line number of the rule. Then run the iptables -D command followed by the chain and rule number.

For example, if we want to delete the input rule that drops invalid packets, we can see that it’s rule 3 of the INPUT chain. So we should run this command:

sudo iptables -D INPUT 3

Now that you know how to delete individual firewall rules, let’s go over how you can flush chains of rules.

Flush Chains

Iptables offers a way to delete all rules in a chain, or flush a chain. This section will cover the variety of ways to do this.

Note: Be careful to not lock yourself out of your server, via SSH, by flushing a chain with a default policy of drop or deny. If you do, you may need to connect to it via the console to fix your access.

Flush a Single Chain

To flush a specific chain, which will delete all of the rules in the chain, you may use the -F, or the equivalent --flush, option and the name of the chain to flush.

For example, to delete all of the rules in the INPUT chain, run this command:

sudo iptables -F INPUT

Flush All Chains

To flush all chains, which will delete all of the firewall rules, you may use the -F, or the equivalent --flush, option by itself:

sudo iptables -F

Flush All Rules, Delete All Chains, and Accept All

This section will show you how to flush all of your firewall rules, tables, and chains, and allow all network traffic.

Note: This will effectively disable your firewall. You should only follow this section if you want to start over the configuration of your firewall.

First, set the default policies for each of the built-in chains to ACCEPT. The main reason to do this is to ensure that you won’t be locked out from your server via SSH:

sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

Then flush the nat and mangle tables, flush all chains (-F), and delete all non-default chains (-X):

sudo iptables -t nat -F
sudo iptables -t mangle -F
sudo iptables -F
sudo iptables -X

Your firewall will now allow all network traffic. If you list your rules now, you will will see there are none, and only the three default chains (INPUT, FORWARD, and OUTPUT) remain.

source:digitalocean

Soa Technology

Next OnePlus flagship could switch to superfast 65W charging

Recent OnePlus phones have been all about speed — from snappy performance to speedy charging tech. The company is so absorbed by this notion that it waited a long while before introducing wireless charging to make sure its implementation lived up to its high standards. The company’s Warp Charge, previously Dash Charge, has been among the industry’s fastest charging solutions, but OnePlus doesn’t want to settle there and seems to be kicking things a notch higher with an even faster charging speed.

According to MySmartPrice, TÜV Rheinland’s Japanese arm has issued a certificate for a OnePlus charging brick that can push up to 65 watts of power (6.5A at 10V). By comparison, the company’s current Warp Charge 30T spec is rated for 30 watts of maximum output, which OnePlus has further optimized with software tweaks for shorter charging time. A 65W charger isn’t particularly far-fetched since OnePlus sister company Oppo showcased a similar charger a few months back, and the recent Realme X50 Pro ships with an adapter based on that tech.

If OnePlus’s solution ends up being anything like Realme’s, you can expect a 4,000mAh battery to top up completely in 30 minutes flat. When or if OnePlus will bundle its phones with a 65W charger is still a bit of a mystery; it’s entirely possible that the 8T (or whatever OnePlus decides to call it) could include the wild new charger, or the company may choose to wait for another generation to iron out any remaining issues. A 60W charger could also be offered as a separate purchase at a later date.

Source: MySmartPrice

Soa Technology

Microsoft Teams Adds Custom Background Effects During Video Call, Other New Features

Microsoft Teams, the video conferencing service by Microsoft, is getting a host of new updates, including the ability to use custom photos as background images during video calls. The feature is available to users of the platform’s free version and Indian customers of Teams can use it as well. Users of Microsoft Teams free version can also now schedule meetings and share links via Outlook or Google calendar. The Redmond company in a blog post has stated that Teams customers in the US can turn on live captions during their calls and meetings as well.

With the latest upgrades added to the platform, Microsoft is hoping to give tough competition to competitors such as Zoom and Google Meet. In a blog post, corporate vice president for Microsoft 365, Jared Spataro announced that the recent updates are a result of Teams’ growing userbase amid the global pandemic.

Custom background on Microsoft Teams

Starting with the new custom background effects on Microsoft Teams, the company notes that users can customise the background by uploading own images or choosing one of the collections of backgrounds available online. The platform already allows users to choose special backgrounds during a video call, in addition to the option to blur background.

Microsoft is also adding event-specific background collections for its users. Starting June 16, users can download special LGBTQI+ background photos to celebrate pride month. To upload a custom photo during a Team video call, users need to select More actions (represented by three horizontal dots) on the screen > Show background effects > Click on Add new.

Other new features on Microsoft Teams

Microsoft is also adding new features to the free version of its video conferencing platform. The company says with the new updates, Teams free version customers can work and connect from home “effectively.”

Free version users are now able to schedule meetings and send out invitations in advance. This capability builds upon the existing ability to “Meet Now.” Meeting schedulers have the option of either copying the meeting link to send directly to other participants or sending an invite via Outlook or Google calendar.

Microsoft in the post says that the much-requested schedule feature is being rolled out to current users, while users who are just signing up now will be able to “experience it soon.” Additionally, Teams customers in the US will soon be able to use live captions during a Teams call.

Meanwhile, the company last month announced that the Teams platform is looking to increase its group call participants limit to 250. The current limit on the video conferencing platform is 100.

source:ndtv