Https www.file-upload.com v0c87e5n38wu ภาษาไทย ม.1_ภาคเร ยนท 1.zip

The TAC customer support engineers can assist you with resolving an issue in a timely manner when they have relevant files attached to the issue. You have several options to upload the files related to your issue. Some of these options are less secure, and can lead to certain inherent risks, and each option has limitations that you need to consider before deciding on an appropriate upload option. Table 1 summarizes the available upload options with details on file encryption capabilities, recommended files size limits, and other relevant information.

Table 1. Available Upload Options

Available Option (In Order of Preference) Files are Encrypted in Transit Files are Encrypted at Rest Recommended File Size Limit Support Case Manager (SCM)

Yes

Yes

No limit

Customer eXperience Drive

Yes*

Yes

No limit

Email to [email protected]

No**

Yes

20 MB or less based on customer mail server limits

*Applies to all protocols except FTP. When using FTP, it is highly recommended that the data is encrypted before being uploaded.

**You must encrypt prior to transit. Secure transit is guaranteed only from the point where the email/attachment reaches the Cisco network, not on the customer network or email provider side.

Support Case Manager File Upload

The Support Case Manager (SCM) file upload method is a secure option for uploading files to cases. The communication channel between your computing device and Cisco is encrypted. Files uploaded through SCM are immediately linked to the associated case and stored in an encrypted format.

Uploading a File to a Case

After you submit the case, you can upload files.

Step 1. Log in to SCM.

Step 2. In order to view and edit the case, click the case number or case title in the list. The Case Summary page opens.

Step 3. Click Add Files in order to choose a file and upload it as an attachment to the case. The system displays the SCM File Uploader tool.

Step 4. In the Choose Files to Upload dialog box, drag the files that you want to upload or click inside to browse your local machine for files to upload.

Step 5. Add a description and specify a category for all files, or individually.

Note: In order to optimize the upload settings for your network condition, click Optimize Upload Settings.

Step 6. Click Upload in order to start the upload process.

Step 7. Once all uploads are complete, you can close the window or click Add More Files in order to upload more files.

Step 8. Uploaded files can be managed in the Attachments tab.

Customer eXperience Drive

Service Summary

The Customer eXperience Drive (CXD) is a multi-protocol file upload service with no limitation on the uploaded file size. It helps Cisco customers with active Service Requests (SRs) to upload data directly to a case using a unique set of credentials created per SR. The protocols supported by CXD are natively supported by Cisco products which allows for uploading directly from Cisco devices to SRs.

Supported Protocols

Table 2 summarizes the protocols supported by CXD. It is worth noting that regardless of the protocol used, there is no limit set on the uploaded file size.

Table 2. CXD Supported Protocols

Name Protocol/Port Encrypted Data Channel Ports Notes Secure File Transfer Protocol (SFTP)

TCP/22

Yes

N/A

Secure Copy Protocol (SCP)

TCP/22

Yes

N/A

Hyper Text Transfer Protocol over SSL (HTTPS)

TCP/443

Yes

N/A

Only API-based uploads are supported. File Transfer Protocol of SSL (FTPS) Implicit

TCP/990

Yes

30000-40000

Firewalls cannot inspect FTPS, as the control channel is encrypted. Hence, the firewall needs to allow outbound connectivity to the entire data channel port range. File Transfer Protocol of SSL (FTPS) Explicit

TCP/21

Yes

30000-40000

File Transfer Protocol (FTP)

TCP/21

Yes

30000-40000

Cisco does not recommend using FTP at all, since the protocol does not support encryption. If it must be used, data needs to be encrypted before transfer.

Firewalls must inspect FTP traffic to allow data channels to be properly established. If FTP is not inspected throughout the network, firewalls need to allow outbound connectivity to the entire data channel port range.

CXD Upload Token

CXD creates unique upload tokens per SR. The SR number and the token are used as the username and password to authenticate to the service and subsequently upload files to the SR.

Note: The token is for upload only and does not allow the user to access case files, or even files currently being uploaded. If the user would like to view case files, that can only be done in SCM.

Retrieving the Upload Token for an SR

Using SCM

When an SR is opened, users must create the upload token to upload the attachment.

In order to retrieve/generate the upload token, complete these steps:

Step 1. Log in to SCM.

Step 2. In order to view and edit a case, click the case number or case title in the list. The Case Summary page opens.

Step 3. Click the Attachments tab.

Step 4. Click Generate Token. Once the token is generated it is displayed next to the Generate Token button.

Note: The username is always the SR number. The terms password and token refer to the upload token, which is used as a password when prompted by CXD.

Using the API

Customers utilizing the API can retrieve the token programmatically using the

user@linux ~]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz

0 API.

Note: An Okta Auth Token is required to call Cisco Get Token API. For details on obtaining an Auth Token, consult the Cisco ServiceGrid documentation.

HTTP Method: POST

URL: https://cxd-token.cxapps.cisco.com/cxd/token/<SR_Number>

Header:

Table 3. Get Token API Header

Key Type Value

Content-Type

String

application/json

Authorization

String

Bearer <Auth Token>

Body:

Table 4. ServiceGrid GetUploadCredentials API Body

Key Type Value

username

String

Cisco.com username authorized to perform a file upload to the SR

email

String (Email Format)

Email address of the cisco.com username

Uploading Files to CXD

Using Desktop Clients

In general, all the user needs to do is use a client, depending on the protocol, to connect to cxd.cisco.com, authenticate using the SR number as the username and the upload token as the password, and eventually upload a file. Depending on the protocol and the client, the user steps can be different. It is always recommended to refer to the client documentation for more details.

Directly from a Cisco Device

All Cisco devices have built-in file transfer clients, usually utilized using a

user@linux ~]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz

1 or

user@linux ~]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz

2 command. Cisco equipment running on a Linux distribution usually supports one or more of scp, sftp, and curl for SCP, SFTP, and HTTPS integrations.

File Upload API

The file upload API utilizes the HTTP PUT verb to upload files to CXD. For maximum compatibility and simplicity of integration, the API is kept simple.

HTTP Method: PUT

URL: https://cxd.cisco.com/home/<destination file name>

Headers:

Table 5. CXD File Upload API Headers

Key Type Value

Authorization

String

Basic HTTP Auth String

The body is the file data itself. There are no fields or forms here, which makes the request very simple.

Sample Python Code to use the PUT API

Note that the code assumes that the file is stored in the same path you are running it from.

import requests from requests.auth import HTTPBasicAuth username = 'SR Number' password = 'Upload Token' auth = HTTPBasicAuth(username, password) filename = 'showtech.txt' # Destination filename url = f'https://cxd.cisco.com/home/{filename}' headers = {"Expect": "100-continue"} file_path = 'Local Path to the File' with open(file_path, 'rb') as f:

r = requests.put(url + filename, f, auth=auth, headers=headers)
if r.status_code == 201:
    print("File Uploaded Successfully")

Email File Attachment Uploads

If SCM and CXD do not work for you, another alternate file upload method is email file attachment upload. Note that this method is fundamentally insecure and does not encrypt the file or the communication session used to transport the file between the customer and Cisco. It is incumbent upon the customer to explicitly encrypt files before the files are uploaded through email file attachments. As an additional security best practice, any sensitive information such as passwords need to be obfuscated or removed from any configuration file or log that is sent over an insecure channel. For more information, see .

After the files are encrypted, upload additional information and files to the case by sending the information via an email message to [email protected] with the case number in the subject line of the message, for example, subject = Case xxxxxxxxx.

Attachments are limited to 20 MB per email update. Attachments submitted by using email messages are not encrypted in transit, but are immediately linked to the specified case and stored in an encrypted format.

Attach the file to an email message and send the message to [email protected] as shown in this screenshot.

The previous screenshot displays a Microsoft Outlook email that has an encrypted ZIP file attachment, the correct To address, and a properly formatted Subject. Other email clients need to provide the same functionality and perform just as well as Microsoft Outlook.

Encrypting Files

The following examples show how to encrypt files by using three of the many available options such as WinZip, Linux tar and openssl commands, and Linux Gzip and GnuPG. A strong encryption cipher such as AES-128 needs to be used in order to properly protect the data. If you are using ZIP, an application that supports AES encryption must be used. Older versions of ZIP applications support a symmetric encryption system that is not secure and is not to be used.

Encrypting Files Using WinZip

This section demonstrates how to encrypt files by using the WinZip application. Other applications provide the same functionality and perform as well as WinZip.

Step 1. Create a ZIP archive file. In the WinZip GUI, click

user@linux ~]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz

3 and follow the menu prompts in order to create an appropriately named, new ZIP archive file. The system displays the newly created ZIP archive file.

Step 2. Add the file(s) to be uploaded to the ZIP archive file and check the

user@linux ~]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz

4 check box. From the main WinZip window, click

user@linux ~]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz

5 and then choose the file(s) to upload. The

user@linux ~]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz

4 check box must be checked.

Step 3. Encrypt the file by using the AES encryption cipher and a strong password:

1. Click user@linux _{]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz 5 in the file selection window in order to open the user@linux} ]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz 8 window.
2. In the user@linux ~]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz 8 window, create an appropriately strong password. The password is shared with the case Customer Support Engineer owner, as discussed in .
3. Choose one of the AES Encryption methods.
4. Click `Add Files`0 in order to encrypt the file(s) and display the main WinZip window.

Step 4. Verify that the file is encrypted. Encrypted files are marked with an asterisk following the file name or a lock icon in the Encryption column.

Encrypting Files Using Tar and OpenSSL

This section shows how to encrypt files by using the Linux command-line Add Files`1 and *Add Files*`2 commands. Other archive and encryption commands provide the same functionality and perform just as well under Linux or Unix.

Step 1. Create a tar archive of the file and encrypt it through OpenSSL using the AES cipher and a strong password as demonstrated in the following example. The command output shows the combined Add Files`1 and *Add Files*`2 command syntax to encrypt the file(s) using the AES cipher.

[user@linux ~]$ tar cvzf - Data_for_TAC.dat | openssl aes-128-cbc -k Str0ng_passWo5D | dd of=Data_for_TAC.aes128 Data_for_TAC.dat 60+1 records in 60+1 records out

Encrypting Files Using Gzip and GnuPG

This section demonstrates how to encrypt files by using the Linux command-line Gzip and GnuPG commands. Other archive and encryption commands provide the same functionality and perform just as well under Linux or Unix. The command output shows how to use the gzip and gpg command syntax to encrypt the file(s) using the AES cipher.

Step 1. Compress the file by using Gzip:

[user@linux ~]$ gzip -9 Data_for_TAC.dat

Step 2. Encrypt the file through GnuPG using the AES cipher and a strong password:

user@linux ~]$ gpg –cipher-algo AES –armor –output Data_for_TAC.dat.gz.asc –symmetric Data_for_TAC.dat.gz

Step 3. Enter and confirm the strong password at the passphrase prompt:

Enter passphrase: Repeat passphrase:

Communicating the Password to the TAC Customer Support Engineer

When encrypting attachments, share the encrypting password with the case Customer Support Engineer owner. As a best practice, use a method other than the one used to upload the file. If you used an email message or FTPS to upload the file, communicate the password out-of-band such as by telephone or SCM case update.

Customer File Retention

For the duration that a case is open and for a period up to 18 months following final closure of a case, all files are instantly accessible from within the case tracking system to authorized Cisco personnel. After a period of 18 months from final closure, the files can be moved to an archival storage instance to conserve space, but they are not purged (deleted) from the case history.

At any time, an authorized customer contact can expressly request that a specific file be purged from a case. Cisco can then delete that file and add a case note to document the party who deleted the file, the time and date stamp, and the name of the deleted file. After a file is purged in this manner, it cannot be recovered.

Files uploaded to the TAC FTP folder are retained for four days. The case Customer Support Engineer owner needs to be informed when a file is uploaded to this folder. The Customer Support Engineer needs to back up the files within four days by attaching them to the case.

Summary

Multiple options exist for uploading information to TAC to help them resolve cases. SCM and Cisco’s HTML5 Upload tool both offer secure uploads through a browser, while the CXD offers uploads through a browser, Web API, and multiple protocols that are supported by different types of clients and Cisco devices.

If you cannot use SCM, Cisco HTML 5 File Upload Tool, or a protocol supported by CXD that is not FTP as your file upload method, the least preferred file upload options are FTP, using CXD, or an email message sent to [email protected]. If you use either of these options, it is strongly advised that you encrypt your files before transit. For more information, see . You need to employ a strong password and communicate the password to the case Customer Support Engineer out-of-band such as by telephone or SCM case update.

For the duration that a case is open and for a period up to 18 months following final closure of a case, all files are instantly accessible from within the case tracking system to authorized Cisco personnel.

• After 18 months the files can be moved to archival storage.
• At any time, an authorized customer contact can expressly request that a specific file be purged from a case.
• Files in the FTP folder are retained for only four days.

Additional Information

• Accessing Cisco Technical Services
• Cisco Worldwide Support Contacts
• Cisco Technical Services Resource Guide
• Cisco Conferencing Products
• The GNU Privacy Guard
• The OpenSSL Project
• WinZip

This document is part of the Cisco Security Research & Operations.

This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.